stuff inline
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.
Oh yeah, absolutely. I am coming at this from the server's perspective though; why should I be forced to maintain a subscription to stuff that I don't even support, and never will support for the lifetime of the subscription? I guess what I am arguing is that this may be a good thing to leave up to policy.
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?
When I was talking about malformed URIs, I was mainly thinking about malformed XPATH, which will remain malformed. But, if a document selector is malformed now, and the server does not expose configuration that will make it well-formed in the lifetime of the subscription (across a recompile/upgrade/reboot/etc), would it then make sense to reject as a matter of local policy? In principle the implementor will know what can be reconfigured to work on-the-fly, and what can't (whether this is true in practice, who knows, but I think that's safely in the realm of "implementor's problem"). I agree that _requiring_ servers to reject when they don't _currently_ understand a doc-selector or a collection selector is a bad idea (which is the point you're trying to make here, I think). They should be _allowed_ to do so when it makes sense for the particular implementation, however.
Could we use <xcap-error> documents in some way (provided thesubscribersupports 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 handlingerrors related to the XML body in an XCAP PUT and not errors related tothe Document selector.
Yeah, you're right (I was erroneously remembering that you could use <xcap-error> in some cases for GETs).
Best regards, Byron Campen
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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
