Re: [Sip] WGLC for draft-ietf-sip-xcapevent-01

[Jari Urpalainen <[e-mail]>]

responses inline

Miguel Garcia wrote:
> Hi:
>
> Here are some comments to the XCAP event package, in sequential order.
>
>
> - Introduction, 2nd paragraph. Indicate that the subscription can be 
> applied to "several documents". There is a reference to RFC 4918 that 
> I don't get it. I don't understand what is this reference, so better 
> remove it.
well the document uses the collection as defined by rfc4918 (and with 
similar semantics as well).
>
> OLD:
>    This memo defines an
>    "xcap-diff" event package that, together with the SIP event
>    notification framework [RFC3265] and the XCAP-diff format
>    [I-D.ietf-simple-xcap-diff], allows a user to subscribe to changes in
>    an XML document, and to receive notifications whenever a change in an
>    XML document takes place. It is also possible to subscribe to
>    documents within some collection [RFC4918], the notifier provides
>    then the documents where the user has read privilege.
>
> NEW:
>
>     This memo defines an
>    "xcap-diff" event package that, together with the SIP event
>    notification framework [RFC3265] and the XCAP-diff format
>    [I-D.ietf-simple-xcap-diff], allows a user to subscribe to changes in
>    one or more XML documents, and to receive notifications whenever a
>    change in any of those XML document takes place.
>
> - Introduction... More than an Introduction, the third paragraph is an 
> Overview of Operation. Perhaps this paragraph should be promoted to 
> its own section (titled Overview of operation), and should have an 
> overview of what the draft does: The SUBSCRIBE contains a list, the 
> first NOTIFY contains references, further NOTIFYs contain changes 
> according to the selected diff-processing model, which can be this and 
> that... ETags management, etc.
>
developer question, how does it influence the _running_ code ;-) ? 
Seriously, one could really improve the text...
> - Definitions. I think the 'Aggregating' definition is not clear. I 
> got confused thinking that Aggregating is about "several documents". 
> However, it is about aggregating intermediate states of the same 
> component. I would suggest as a definition something around:
>
>    Aggregating:  A given XCAP component might have passed through 
> several changes in a period of time. Aggregating considers only the 
> initial state and the final one, bypassing all the intermediate 
> changes. Therefore, when changes for a given XCAP component are 
> aggregated, it is not possible to recreate the full history of changes 
> of that XCAP component.
ok, thanks.
>
> - Definitions: I am missing the definition of "collection". RFC 4918 
> refers to "sets of documents". I think collections, in the context of 
> this draft, refers to "set of XCAP resources (including documents, 
> elements, or attributes).
collection is just like defined in rfc4918 (and a collection may contain 
(sub)collections and documents)
>
> - Section 4.1, 1st paragraph. I think the text starts describing what 
> is NOT the common operation of the event package. Given that the 
> document haven't explained at this time the relevant concepts of the 
> package, I find hard to follow how especial cases will work. I would 
> suggest that the document starts describing the simples easiest cases 
> and then it moves to complicated cases (such as when the client is not 
> aware of all the individual XCAP documents it is subscribing to).
why would you use this package if you know already what's on the server 
? This is what a typical developer (at least i) would do: you send an 
initial request to see if there are any changes available if you cache 
locally. If you don't cache over a longer period you definitely want to 
see the list of docs available.
>
> - Section 4.1, 2nd paragraph. Same as before. The document explains 
> how to subscribe to an XCAP element "without the need of a separate 
> HTTP GET request" when the document hasn't explained how to do a 
> regular subscription to one or more documents.
imho, 4.1 1. paragraph speaks about document subscriptions (no?) which 
is imo the simplest use-case of this event package. the 2. paragraph is 
about the  element & attribute content subscriptions and the last 
chapter about the most complex stuff, i.e. patching of docs. So imo the 
order of complexity definitely increases ;-) but i agree that the text 
can be improved...

>
> - After reading Section 4.1, I concluded that I don't understand 
> anything about the title: XCAP-Diff Processing Model. I think this 
> section has to be re-written (I can help Jari with the text). I 
> believe it should give an overview of the 3 XCAP-Diff processing 
> models so that the reader understands something.
yes please do ;-)
>
> - The draft should say which of the 3 XCAP-Diff processing models is 
> mandatory to implement. I suspect the draft assumes that all 3 are 
> mandatory to implement in both the server and the clients. So, it 
> should say it. But isn't that in contradiction with the following 
> sentence in Section 4.7?
>
>    It is RECOMMENDED to implement the XML-Patch-Ops processing on a
>    server.
>
> How can one implement the xcap-patch diff-processing model without the 
> XML-Patch-Ops?
clearly this needs some clarification. Yes you don't need to support 
_any_ patching at all (in the server) as the notifier may decide to send 
only references to docs and only indicate element/attribute 
subscriptions. The diff-processing parameter is thus a hint to the 
notifier. This is to allow naive implementations or where transmission 
optimizations  are not important. But the parameter value "no-patching" 
is not a hint, the notifier MUST NOT provide patches then.

>
> - Section 4.3. This section answers better the title of Section 4.1: 
> XCAP-Diff processing. However, in the first paragraph, the document 
> should clarify: a) what are the differences between the 3 models; b) 
> what is NOT included in notifications for each of the models.
>
see above, so patches may not ever be included.
> - Section 4.4, 1st paragraph, the text reads:
>
>    When generating a subscribe request, the subscriber needs to define
>    the resources it is interested in getting information.  This can be
>    done simply by sending a URI list to the SIP notifier.
>
> This can be done???? I am missing some stronger language, in 
> particular, some language that clearly defines that there could be 
> other potential mechanisms (SUBSCRIBE URI-list servers), but these 
> aren't considered in this document. I propose:
>
>    When generating a SUBSCRIBE request, the subscriber needs to define
> the resources it is interested in getting information.  This document 
> provides a mechanism to include lists of URIs in the SUBSCRIBE 
> request: An XCAP resource list according to the format specified in 
> RFC 4826 [RFC2836] is included as a body of the SUBSCRIBE request that 
> creates the subscription. Each of these URIs in the XCAP resource list 
> represents an XCAP resource for which notification of changes are 
> requested.
looks better though collections are not xcap resources.

>
>
> Question: if a SUBSCRIBE request is sent to refresh a subscription, 
> MUST it contain a URI list? Can the URI list change in a subsequent 
> SUBSCRIBE? The draft should say something, whatever it is.
>
it says in 4.4: "When re-subscribing within a current dialog, the 
subscribed body MAY also change." and some text also in the last chapter 4.8
> - Section 4.4. Missing text about the Request-URI. Although the title 
> of Section 4.4 has nothing to do with Request-URIs, I think somehow 
> somewhere the document should say what is the assumption about the 
> Request-URI of the SUBSCRIBE request. I guess the document tries to say:
>
> A subscribers need to appropriately populate the Request-URI of the 
> SUBSCRIBE request. This document does not provide any constraints to 
> it.   It is assumed that the subscriber is provisioned or has learned 
> the Request-URI of the notifier of this event package. Initial 
> SUBSCRIBE requests are assumed to be addressed to the URI of that 
> notifier.
except the last sentence which i don't follow looks good.

>
> - Section 4.4, 4th paragraph says:
>
>    Figure 2 shows an example to a subscription of several XCAP
>    resources:
>
> That is not correct. Figure 2 shows "the body of a subscription", but 
> not the subscription. And this is a big problem. I highly recommend to 
> include a full SUBSCRIBE request that contains the body as well, I am 
> not sure if it fits in this section or in some other section, but I 
> desperately need it.
this is where i'm really uncertain what's the best practice / verbosity 
/ work-effort etc. As an implementer i appreciate examples, but once 
you'll have them they MUST be 100 % correct which is not necessarily 
easy to achieve (and generally you'd better to have some running code). 
So lazy implementers will look only the examples and when they are buggy 
they end up being also in implementations unfortunately. In this 
particular case IMO there are enough examples about full subscriptions 
(headers, success responses etc). What would be useful to show the 
important things i.e. subscription bodies with or without the event 
parameter and consequent notification bodies in different cases. Perhaps 
something similar to xml-patch-ops examples in an appendix. But it needs 
_some_ effort and some thinking what is a _useful_ set of examples.
>
> - Also: Somewhere the text should explain that each <entry> in the 
> 'resource-list' can point to a single XCAP resource (document, 
> element, or attribute), or a collection of them. I believe 
> "collections" are only indicated as examples, but not really described.
ok.

>
> - Section 4.6 says:
>
>    Also the removals of documents, elements and
>    attributes can be shown.
>
> I would expect this to be a normative "MUST be shown".
if we think about format spec it is a can directive, but in this i-d 
context it is a MUST.
>
> - I think the first paragraph in Section 4.7 should be slit into 
> different paragraphs, each one devoted to a different concept. I can 
> identify: Resolving resources (including those who don't exist); 
> generating a first NOTIFY versus generating subsequent ones; 
> applicability of draft-ietf-sip-subnot-etags (does this draft really 
> need to say something new?); treatment of the different XCAP-Diff values.
yep, it's a bit long and combines too many things together.
>
> - Section 4.7, 4th paragraph says:
>
>    However, the notifier MUST support XCAP component
>    subscriptions.
>
> So, is there another alternative? I mean, this gives me the impression 
> like if XCAP components were an option in XCAP, and therefore, 
> subscriptions to those XCAP components were also optional. Is this the 
> case?
>
the format spec support component subscriptions but you _could_ define 
an event package based on the format spec which needs not to support 
xcap component subscriptions, so the statement is better to stay there.
> - Section 4.7 says:
>
>    The existence of elements is then indicated with an empty
>    <element> element and the content is not shown for those resources.
>    In other words, the <element> element does not not have a child
>    element then which would show the subscribed "full" element content.
>
> I understand what the text says, but I think an example showing the 
> two possibilities will really clarify the text.
right, examples are useful when they are correct. That being said, i 
think if an implementer doesn't get this right, there must be other 
bigger bugs as well ;-)
>
> - Section 4.7, last paragraph says:
>
>     Partial-PIDF-Notify
>    [I-D.ietf-simple-partial-notify] requires that notifiers will not
>    send a new request to the same dialog unless a successful response
>    (200 OK) has been received for the last request.  The latter applies
>    also to this "xcap-diff" event package.
>
> I am missing a normative statement here. Perhaps replacing the last 
> sentence with:
>
>   A notifier of this "xcap-diff" event package MUST NOT send a 
> subsequent NOTIFY request until the notifier has received a 200-class 
> response for a previous one.
>
right, better.
> - Section 5. I would like to see more examples, in particular, I would 
> like to see one example of the same subscription with different 
> processing models, to better understand the differences among them.
>
this is what i've been afraid of... but i'll try to do assemble an appendix.
> - Section 6, IANA considerations section fails to mention
> that this registration is about "SIP".  So,
> first, I would remove the first two sentences, and the headline 6.1,
> and just would leave:
>
>
> This specification instructs IANA to add a new event package to the
> SIP Event Types Namespace registry. The new data to be added is:
>
> Package Name    Type            Contact                    Reference
> -------------   --------        -------                    ---------
> xcap-diff       package         IETF SIPPING Working Group [RFCXXXX]
>                                 <sipping&ietf.org>
>
>
template better yes, though this is sip wg ;-)

>
>
> Thanks,
>
>        Miguel
>
Thank you,
Jari


_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip