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

[Byron Campen <[e-mail]>]

	stuff inline

> Hi Byron
> Some comments inline
> Best Regards
> Anders Lindgren
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Byron Campen
>> Sent: den 27 maj 2009 17:44
>> To: [e-mail]; Dean Willis
>> Cc: [e-mail] 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: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?
>
> 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 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.
>

	Yeah, you're right (I was erroneously remembering that you could use  
<xcap-error> in some cases for GETs).

Best regards,
Byron Campen