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

[Miguel Garcia <[e-mail]>]

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.

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.

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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




Thanks,

        Miguel

DRAGE, Keith (Keith) wrote:
> (As SIP WG cochair)
> 
> In parallel with the WGLC on xcap-diff in the message below (as these
> are related drafts), this is to initiate a WGLC on:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-sip-xcapevent-01.txt 
> 
> Comments should be sent to the SIP list and to the editor by 31st March
> 2008, ie. This is a 3 week WGLC to take into account the overlap with
> the current IETF meeting.
> 
> Please take some steps to indicate the severity of the comment (from NIT
> through to major technical).
> 
> Obviously please follow the requirements below for comments on the
> related draft.
> 
> Regards
> 
> Keith
> 
> 
> 
> -----Original Message-----
> From: Robert Sparks [mailto:[e-mail]] 
> Sent: Monday, March 10, 2008 10:23 PM
> To: simple mailing list
> Cc: Jari Urpalainen; [e-mail]
> Subject: WGLC: draft-ietf-simple-xcap-diff-08
> 
> Folks -
> 
> This is a Working Group Last Call for comments on
> http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-diff-08.txt
> 
> The editor for draft-ietf-simple-xcap-diff and draft-ietf-sip- xcapevent
> has indicated these drafts are ready for WGLC.
> We're coordinating the LC time between the two working groups.
> 
> Please have your comments to the editor/list by three weeks from today
> (March 31,2008).
> 
> Thanks,
> 
> RjS
> 
> _______________________________________________
> 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
> 

-- 
Miguel A. Garcia           tel:[phone]
Nokia Siemens Networks     Espoo, Finland

_______________________________________________
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