Re: [Sip] Draft ietf-sip-xcapevent revised, many open questions

[Jari Urpalainen <[e-mail]>]

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:bob@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