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

From: Dean Willis <[email-masked]>
Date: Tue, 26 May 2009 19:35:21 -0500

I have submitted a revised version of the XCAP Event draft based on  
feedback from Lisa Dusseault and that incorporates a vast amount of  
editing by Jean Mahoney, a technical writer who volunteered to help  
clean things up after Lisa pushed the draft back from IESG review.

See:
http://www.ietf.org/internet-drafts/draft-ietf-sip-xcapevent-05.txt

and since tehre are a lot of changes, the side-by-side diff is really  
helpful:

http://tools.ietf.org/rfcdiff?url2=draft-ietf-sip-xcapevent-05

There are a number of questions open in the existing document.

1)  What's the default notification mode supposed to be? "xml- 
patching" is listed as the default and fail-safe in some text, but "no- 
patching" is also described as the singular "must implement" mode. It  
seems to me that if a mode is the default if no mode is specified,  
then that mode had better be the default.
This question is a primary source of confusion in Section 4.3, and I'd  
appreciate some feedback. This whole section got a lot of edits, you  
may want to usea difftool.

2) Aggregating definition

Our current text has this definition; is it right?

    Aggregating:  An XCAP client can update only a single XCAP Component
       at a time using HTTP.  However, a notifier may be able to
       aggregate a series of these modifications into a single
       notification using XML-Patch- Ops semantics encoded in the XCAP-
       Diff format.

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.

4) Error recovery

Section 4.7 says:

    While the "aggregate" mode uses bandwidth most efficiently, it
    introduces other challenges.  The initial synchronization might fail
    with rapidly changing resources, because the "aggregate" mode
    messages might not include the full version-history of a document  
and
    the base XCAP protocol does not support version-history retrievals  
of
    documents.  When new documents are created in subscribed collections
    and the notifier is aggregating patches, the same issue can occur.
    In a corner case, the notifier may not be able to provide patches
    with the XML-Patch-Ops [RFC5261] semantics.  Therefore, if the
    notifier has to temporarily disable diff generation and send only  
the
    URI references of some changed documents to the subscriber, it MUST
    continue with the "xcap-patching" mode afterwards for these
    resources, if the initial subscription also started with the "xcap-
    patching" mode.  Recovery from this error condition therefore means
    that the subscriber must refresh to a "known good" state by
    downloading the current document if it has lost track of the  
patching
    operations as indicated by mismatching ETags.,

(note the accidental extra comma here at the end, I just noticed it,  
and it is my fault).

Anyhow, does the "recovery" text make sense?

---

From: Jari Urpalainen <[email-masked]>
Date: Wed, 27 May 2009 13:07:06 +0300

> clean things up after Lisa pushed the draft back from IESG review.
Thanks Dean, Sean and Lisa.
> may want to usea difftool.
for implementers this is no big deal, although you MUST know which is
the default if the parameter is missing, anyways it can be anyone of
those, so i'm fine with this technical change.

>        notification using XML-Patch- Ops semantics encoded in the XCAP-
looks fine ;-)

> This doesn't sound right to me.
the part was stolen from rfc3856, section 6.5. If you refer to default
behavior, i personally agree that it's a bit weird, but there are much
better sip experts here...

> Anyhow, does the "recovery" text make sense?
I must admit that it's a bit difficult to follow the sentence starting
with "Recovery ..." but it shouldn't still be _wrong_...

Section 5 example has a missing angle bracket, and there's bug in
whitespace usage, take the example from the previous version.

Similar bugs also in example on page 21.

thanks Dean,
Jari

---

From: Byron Campen <[email-masked]>
Date: Wed, 27 May 2009 10:43:55 -0500

> 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

---

From: Jari Urpalainen <[email-masked]>
Date: Thu, 28 May 2009 10:11:13 +0300

> subscriber supports this format) to help indicate what went wrong in  

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

---

From: "Anders Lindgren C" <[email-masked]>
Date: Thu, 28 May 2009 15:26:54 +0200

Hi Byron
Some comments inline
Best Regards
Anders Lindgren 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Byron Campen
> Sent: den 27 maj 2009 17:44
> To: [email-masked]; Dean Willis
> Cc: [email-masked] List; Robert Sparks
> Subject: Re: [Sip] Draft ietf-sip-xcapevent revised, many 
> open questions
> 
> 
> 	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.

> Byron

---

From: Byron Campen <[email-masked]>
Date: Thu, 28 May 2009 10:48:37 -0500

stuff inline

> section 12 prior to the subscription in case an implemtation needs to

	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.

> 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.

> errors related to the XML body in an XCAP PUT and not errors related  

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

Best regards,
Byron Campen