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

Byron Campen <[email protected]>
Newsgroups gmane.ietf.sip
Message-ID <[email protected]>
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

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip
smime.p7s (application/pkcs7-signature, 2.4 KB) - not displayed
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.