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

From: Cyrus Daboo <[email-masked]>
Date: Tue, 06 May 2008 21:42:25 -0400

Hi Tim,

--On March 11, 2008 10:10:40 AM -0400 Tim Hare <[email-masked]> wrote:

>  "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.
>

The alternative is to create a registry of status codes. I am not thrilled 
by that prospect but it is the best thing for interoperability. I also 
think that there are likely to be iTIP based protocols that will need their 
own specific codes (e.g. there is some useful status in CalDAV scheduling 
that could be conveyed in new codes).

Anyone else think the status codes should be in a registry.

-- 
Cyrus Daboo

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

---

From: "Tim Hare" <[email-masked]>
Date: Tue, 6 May 2008 22:55:26 -0400

I don't have a strong opinon about a registry, not having a lot of
experience with them; my point is that only those codes which are defined in
the document should be used in a non X- component.  That could be done by
enumerating those interoperable codes in the RFC document, I suppose
although the registry has the advantage of allow us to include new codes 'by
reference' rather than having to revise the RFC again. 

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: Cyrus Daboo [mailto:[email-masked]] 
Sent: Tuesday, May 06, 2008 9:42 PM
To: Tim Hare; [email-masked]
Subject: RE: [Ietf-calsify] Issue 95: text on REQUEST-STATUS

Hi Tim,

--On March 11, 2008 10:10:40 AM -0400 Tim Hare <[email-masked]> wrote:

>  "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.
>

The alternative is to create a registry of status codes. I am not thrilled
by that prospect but it is the best thing for interoperability. I also think
that there are likely to be iTIP based protocols that will need their own
specific codes (e.g. there is some useful status in CalDAV scheduling that
could be conveyed in new codes).

--
Cyrus Daboo