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:[EMAIL PROTECTED]
> Sent: Monday, March 10, 2008 10:23 PM
> To: simple mailing list
> Cc: Jari Urpalainen; [EMAIL PROTECTED]
> 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 [EMAIL PROTECTED] for questions on current sip
> Use [EMAIL PROTECTED] for new developments on the application of sip
>
--
Miguel A. Garcia tel:+358-50-4804586
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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
