Hi Byron Some comments inline Best Regards Anders Lindgren > -----Original Message----- > From: sip-boun...@ietf.org [mailto:sip-boun...@ietf.org] On > Behalf Of Byron Campen > Sent: den 27 maj 2009 17:44 > To: jari.urpalai...@nokia.com; Dean Willis > Cc: sip@ietf.org List; Robert Sparks > Subject: Re: [Sip] Draft ietf-sip-xcapevent revised, many > open questions > > > 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 > > such > > header 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?
A Subscriber can find out which AUID the XCAP Server support by retrieving the "xcap-cap" document document as defined in RFC4825 section 12 prior to the subscription in case an implemtation needs to know this. > What about uris that are formatted in an unsupported way (for > example, using "users/bob" when what the server really needs > is "users/sip:b...@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? It is very difficult for an XCAP server to know that a valid document selector will be in the future. It shall be possible to monitor when a document is created and how will the Notifier know what in the future will be a valid Document selector? Shall the Notifier use its present configuration to find out what will be valid in the future or shall the Notifier trust that the Subscriber knows something that the Notifier yet does not know. My view is that it is better to trust the Subscribe and assume that the document selector if not valid now will be valid in the future. If a Notifier really have a need to fail the subscription to a certain XCAP resource, my suggestion is to fail the whole subscription in order to not to make things more complex than necessary. One issue if it may exist a need to provide a body with detailed information to support that the Subscriber can resubscribe with a body that the Notifier will accept or if an empty 400 is enough. In most case the Subscriber has got the Document Selector for an other type of client ( e.g. An XCAP client) and it is not provided by a human user. This means that the it very likely that the Document Selector is not malformed in the case . If the URI is only an AUID and that AUID is wrong it is likely caused by a bug in the Subscriber client program and I find it hard to see that a detailed error message will help to correct such a fault ( Maybe an error message will help to find the bug). The case that is left is when the XUI in an unsupported format and the XUI is inserted by a human user wrongly. Again how will the Notifier know what formats it may have to support in the future and that it is OK to fail the subscription on existing knowledge. My view is that the normal behavior for a Notifier is to keep the subscription and report back information about existing resources and regard all other resources as resource that may exist in the future and therefore not fail the subscription. This means that the draft is good enough as it is as I see it and that detailed error procedures for a case that is hard to detect is not really needed. >Could we use <xcap-error> documents in some way (provided the subscriber > supports this format) to help indicate what went wrong in these cases? If it exist a need to provide this detailed information I do not think the <xcap-error> is a suitable choice as this document is handling errors related to the XML body in an XCAP PUT and not errors related to the Document selector. > > Best regards, > Byron > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implement...@cs.columbia.edu for questions on current sip Use sipp...@ietf.org for new developments on the application of sip
