On May 26, 2009, at 7:35 PM, Dean Willis wrote:
3) SUBSCRIBE bodies Section 4.4 currently says;The SUBSCRIBE request MAY contain an Accept header field. If no suchheader field is present, it has a default value of "application/ xcap-diff+xml". If the header field is present, it MUST include "application/xcap-diff+xml", and MAY include any other types. This doesn't sound right to me.
Yeah, this is what 3265 makes us do (define a default Accept header field value for the event package).
Also, it looks like we lost a right-angle-bracket on the <element> open tag in the xcap-diff document in section 5.
Lastly, I have been meaning to ask; in what cases (if any) would sending a SUBSCRIBE 404 be appropriate in this event package? Do we establish a subscription even if every uri in the SUBSCRIBE body refers to an AUID we don't support? What about uris that are formatted in an unsupported way (for example, using "users/bob" when what the server really needs is "users/sip:bob at foo"), or that use a document name that doesn't exist in the AUID being used (say, "rls- services.xml" instead of "index" or "index.xml")? How about uris that are outright malformed; it seems that our best choice is a SUBSCRIBE 400, but what if only one of the uris in the SUBSCRIBE body is in such a state? Could we use <xcap-error> documents in some way (provided the subscriber supports this format) to help indicate what went wrong in these cases?
Best regards, Byron Campen
Attachment:
smime.p7s
Description: S/MIME cryptographic signature