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

["Anders Lindgren C" <[e-mail]>]

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. 
 
> 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? Shall the Notifier use its present
configuration to find out what will be valid in the future or shall the
Notifier trust that the Subscriber knows something that the Notifier yet
does not know. My view is that it is better to trust the Subscribe and
assume that the document selector if not valid now will be valid in the
future. If a Notifier really have a need to fail the subscription to a
certain XCAP resource, my suggestion is to fail the whole subscription
in order to not to make things more complex than necessary. One issue if
it may exist a need to provide a body with detailed information to
support that the Subscriber can resubscribe with a body that the
Notifier will accept or if an empty 400 is enough. In most case the
Subscriber has got the Document Selector for an other type of client (
e.g. An XCAP client) and it is not provided by a human user. This means
that the it very likely that the Document Selector is not malformed in
the case . If the URI is only an AUID and that AUID is wrong it is
likely caused by a bug in the Subscriber client program and I find it
hard to see that a detailed error message will help to correct such a
fault ( Maybe an error message will help to find the bug). The case that
is left is when the XUI in an unsupported format and the XUI is inserted
by a human user wrongly. Again how will the Notifier know what formats
it may have to support in the future and that it is OK to fail the
subscription on existing knowledge. My view is that the normal behavior
for a Notifier is to keep the subscription and report back information
about existing resources and regard all other resources as resource that
may exist in the future and therefore not fail the subscription. This
means that the draft is good enough as it is as I see it and that
detailed error procedures for a case that is hard to detect is not
really needed.  
 
  
>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.

> 
> Best regards,
> Byron 
>