Subject: [Ietf-calsify] Issue 95: text on REQUEST-STATUS

From: Cyrus Daboo <[email-masked]>
Date: Tue, 11 Mar 2008 00:00:36 -0400

Hi,
Here is some proposed text to address issue 95 in the tracker. 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue95>.

This text would replace the one line of text currently above the table in 
section 3.1.6 in 2446bis:

3.6 Status Replies

The "REQUEST-STATUS" property is used to convey status information about
a REPLY, COUNTER or DECLINE-COUNTER iTIP message. The codes listed in
the table below SHOULD be used. Additional codes MAY be used provided it
is known that the recipient's CUA has appropriate knowledge of such
codes.

This specification allows for multiple "REQUEST-STATUS" properties to be
returned in iCalendar components in the appropriate iTIP messages. When
multiple "REQUEST-STATUS" properties are present, the following
restrictions apply:

1) Within any one component, the "top-level" numeric value of the "short
return status code" MUST be the same for all REQUEST-STATUS properties.
i.e. there cannot be a mixture of e.g., 2.xx and 5.xx codes within a
single component.

2) Across all components in the iTIP message, the following applies:

	a) If any one component would have a 3.xx code, then all components
	MUST have a code in that range or "REQUEST-STATUS" MUST NOT be
	present in the other components if a 3.xx code is not appropriate
	for those components.
	
	b) If any one component would have a 5.xx code, then all components
	MUST have a code in that range or "REQUEST-STATUS" MUST NOT be
	present in the other components if a 3.xx code is not appropriate
	for those components. This rule overrides (a) above.
	
	c) 2.xx and 4.xx codes can be used in different components provided
	that each component follows the restriction in (1) above.

-- 
Cyrus Daboo

_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: "Tim Hare" <[email-masked]>
Date: Tue, 11 Mar 2008 10:10:40 -0400

"Additional codes MAY be used provided it is known that the recipient's CUA
has appropriate knowledge of such codes."

This is not a good thing for interoperability. CUA-specific status codes
need to be an X- component (ex: X-MYCAL-REQUEST-STATUS). The only way one
end can know for certain the other end "has appropriate knowledge of such
codes" is if both are from the same vendor.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Cyrus Daboo
Sent: Tuesday, March 11, 2008 12:01 AM
To: [email-masked]
Subject: [Ietf-calsify] Issue 95: text on REQUEST-STATUS

Hi,

3.6 Status Replies

The "REQUEST-STATUS" property is used to convey status information about a
REPLY, COUNTER or DECLINE-COUNTER iTIP message. The codes listed in the
table below SHOULD be used. Additional codes MAY be used provided it is
known that the recipient's CUA has appropriate knowledge of such codes.

This specification allows for multiple "REQUEST-STATUS" properties to be
returned in iCalendar components in the appropriate iTIP messages. When
multiple "REQUEST-STATUS" properties are present, the following restrictions
apply:

1) Within any one component, the "top-level" numeric value of the "short
return status code" MUST be the same for all REQUEST-STATUS properties.
i.e. there cannot be a mixture of e.g., 2.xx and 5.xx codes within a single
component.

	

--
Cyrus Daboo