Inline too, only points that require further discussion.
Jari Urpalainen wrote:
> 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).
So, RFC 4918 defines collection as:
Collections: The ability to create sets of documents and to retrieve
a hierarchical membership listing (like a directory listing in a file
system).
If the definition is correct for this document, I recommend to add a
note in Section 3 saying: This document reuses the following term from
RFC 4918: Collections.
>> - 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...
If the developer does not get the full picture he will write shit buggy
code, so, I believe this is of utmost importance. Remember that not
every developer will be an authority in XCAP, WebDav, and SIP.
>>
>> - 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.
You said that the server dos not need to support patching. So, what
happens if the subscriber selects diff-processing=xcap-patching and the
server does not support it? How will the developer be ready in its code
to react to it?
>
>>
>> - 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.
That is not my point. My point is that the text should describe how the
3 models work by saying what they share in common and the differences
among them. I think this is not clearly indicated now.
>> - 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.
s/XCAP resource/XCAP resource or collection
>> - 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.
The point with the last sentence is that in an initial SUBSCRIBE
request, the Request-URI is populated with the SIP URI of the notifier,
which is learned somehow (outside the scope of the document). Once the
dialog is created, if there is a subsequent SUBSCRIBE request (e.g., to
refresh the subscription), then the Request-URI will obey the SIP rules:
it will be set to the URI that was received in the Contact header of the
200 OK response for that initial SUBSCRIBE. Conclusion: the
Request-URI of the initial SUBSCRIBE request and the following ones (in
the same dialog) need not be the same.
>> - 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.
Perhaps the text that you just wrote could be added as a note, so it
will help the reader to better understand the concept.
>> - 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 ;-)
Ouch... right... SIP, not SIPPING.
/Miguel
>
>>
>>
>> Thanks,
>>
>> Miguel
>>
> Thank you,
> Jari
>
>
--
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
