On Wed, 2009-05-27 at 17:43 +0200, ext Byron Campen wrote: > 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? 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? 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
imo fwiw, 404 is a no go here, so if the client makes mistakes, it just doesn't get anything within subscription. The rule is: use http and xcap specific errors if you have doubts, but i'm almost 100% certain that no-one is going to implement that kind of state-machine in their clients (is there anyone doing even the simplest implementation? which is btw. indeed really _challenging_ both on the server and the client). In practice, it is mib to make a bullet-proof logic for the server side error behavior, and given that clients could not _ever_ rely that the servers really obey some given rules, it becomes way too complex and error prone to the clients. This was sometimes on the table (looong ago) but was given up for many reasons. br, Jari _______________________________________________ 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
