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

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Tue, 11 Mar 2008 00:19:16 +0100

(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-masked]] 
Sent: Monday, March 10, 2008 10:23 PM
To: simple mailing list
Cc: Jari Urpalainen; [email-masked]
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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 31 Mar 2008 14:47:03 +0300

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

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland

---

From: Jari Urpalainen <[email-masked]>
Date: Tue, 01 Apr 2008 10:03:22 +0300

responses inline

Miguel Garcia wrote:
> 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).
> 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". 
> 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.
> 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...

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

> what is NOT included in notifications for each of the models.
see above, so patches may not ever be included.
> 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:
>
> 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 
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 
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 
> 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.

> not sure if it fits in this section or in some other section, but I 
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.
> '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.

> 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.
> need to say something new?); treatment of the different XCAP-Diff values.
yep, it's a bit long and combines too many things together.
> subscriptions to those XCAP components were also optional. Is this the 
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.
> 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 ;-)
> response for a previous one.
right, better.
> 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.
> Package Name    Type            Contact                    Reference
template better yes, though this is sip wg ;-)

>        Miguel
Thank you,
Jari

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 01 Apr 2008 10:27:26 +0300

Inline too, only points that require further discussion.

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

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

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

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

> looks better though collections are not xcap resources.

s/XCAP resource/XCAP resource or collection

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

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

> template better yes, though this is sip wg ;-)

Ouch... right... SIP, not SIPPING.

/Miguel

---

From: Jari Urpalainen <[email-masked]>
Date: Tue, 01 Apr 2008 11:10:45 +0300

Miguel Garcia wrote:
>>> 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.
ok.
>>> - 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.
>>>
unfortunately implementing this _requires_ basic understanding of these, 
it is far from being an easy task, and if you have to start from scratch...
>>> How can one implement the xcap-patch diff-processing model without 
>>> the XML-Patch-Ops?
>> _any_ patching at all (in the server) as the notifier may decide to 
>> send only references to docs and only indicate element/attribute 
>> 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.
>
>
well, it is almost no-brainer stuff, since the thing you MUST understand 
is http-retrievals of documents, i.e. it is the fall-back resolution you 
must understand (well, if you request in a corner-case reasonable xcap 
component contents you could avoid having implementing http). Patching 
is truly an optional thing and an optimization technique which you don't 
necessarily always need. So in principle, the client side patchings are 
fairly easy, but what is not mandated by the spec that the servers 
(notifiers) MUST implement the inevitably complex thing: the 
diff-processing in the notifier. Even if you support only the simple ;-) 
xcap-patching mode, e.g. combining with throttling MAY be challenging 
enough... So what is important in this package that you can have an 
almost immediate notification once a change happens, but requiring 
_always_ the most complex thing would be an unnecessary burden. Hey, 
_good_ implementations would certainly implement decent diffing ;-)
> among them. I think this is not clearly indicated now
point taken
> .
>>> 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.
>>> - 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:
>>>
>>> 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.
huh, does this explain the last sentence, i mean are they really 
equivalent ?. If so, i can include it (though i still don't get it (the 
single line), sorry ...)
>>> 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.
>
note would be fine
> Ouch... right... SIP, not SIPPING.
thanks, jari

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 01 Apr 2008 13:56:37 +0300

inline

> _good_ implementations would certainly implement decent diffing ;-)

I still didn't get a question to my answer. A subscriber sends a 
SUBSCRIBE request. The Event header is set to 
xcap-diff;diff-processing=xcap-patch. The server does not support it. 
So, now what? Is the SUBSCRIBE request rejected (with which response 
code?) or is it accepted and a fall back to some of the other processing 
models (to which one)? Where is that written?

> equivalent ?. If so, i can include it (though i still don't get it (the 

Let me try by rephrasing the last sentence: Instead of:

what about this one?

This specification assumes that subscriber populates initial SUBSCRIBE 
requests with the URI of that notifier.

/Miguel

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Tue, 1 Apr 2008 13:13:06 +0200

(As SIP WG chair)

This WGLC ended yesterday, and as far as I can see, we have only
received one set of comments, implying that only one member of the WG
has reviewed the document.

Two requests:

-	If you have reviewed the document, and consider it so perfect
that you have no comments, please indicate this to the list. 

-	If you can find time to review the document, please send the sip
chairs a mail indicating that you are willing to do so, and when you
expect to do this by.

Finally, if you have reviewed the document, but have not yet got around
to sending your comments, please post them as soon as possible.

Regards

Keith

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of DRAGE, Keith (Keith)
> Sent: Monday, March 10, 2008 11:19 PM
> To: IETF SIP List
> Subject: [Sip] WGLC for draft-ietf-sip-xcapevent-01
> 
> (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:
> 
> 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
> 
> 
> 
> The editor for draft-ietf-simple-xcap-diff and 
> draft-ietf-sip- xcapevent has indicated these drafts are 
> ready for WGLC.
> Please have your comments to the editor/list by three weeks 
> from today (March 31,2008).
> 
> Thanks,
> 
> RjS
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Jari Urpalainen <[email-masked]>
Date: Tue, 01 Apr 2008 17:42:10 +0300

Miguel Garcia wrote:
> inline
>
> Jari Urpalainen wrote:
>
>>>>> - 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?
>>>>>
>>>> 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.
>>>
>>>
>> well, it is almost no-brainer stuff, since the thing you MUST 
>> understand is http-retrievals of documents, i.e. it is the fall-back 
>> resolution you must understand (well, if you request in a corner-case 
>> reasonable xcap component contents you could avoid having 
>> implementing http). Patching is truly an optional thing and an 
>> optimization technique which you don't necessarily always need. So in 
>> principle, the client side patchings are fairly easy, but what is not 
>> mandated by the spec that the servers (notifiers) MUST implement the 
>> inevitably complex thing: the diff-processing in the notifier. Even 
>> if you support only the simple ;-) xcap-patching mode, e.g. combining 
>> with throttling MAY be challenging enough... So what is important in 
>> this package that you can have an almost immediate notification once 
>> a change happens, but requiring _always_ the most complex thing would 
>> be an unnecessary burden. Hey, _good_ implementations would certainly 
>> implement decent diffing ;-)
>
> code?) or is it accepted and a fall back to some of the other 
> processing models (to which one)? Where is that written?
it seems not to be clearly written anywhere ;-) (which i thought was 
already clear) except that there's at least this one sentence "It is 
RECOMMENDED to implement the XML-Patch-Ops processing on a server". If 
diff-processing is an optional feature on the server what's left from 
the format spec ? The <document> element doesn't indicate then patching, 
i.e. <add>, <remove> or <replace> doesn't exist in notification bodies 
(see the figure 1 of the format spec). So the only available fall-back 
is that clients MUST then understand http retrievals of documents when 
document creations or modifications will happen. And no other harm will 
happen except you'll lose some optimizations. And still a reasonable 
aggregate mode is more complex than xcap-patching mode which should be 
explicitly stated though it is self-evident. So when notifier decides to 
simplify the implementation burden, support for aggregation is dropped 
first and then xcap-patching.

Having a really useful rejection handling is a nightmare of its own... 
e.g. how to signal event parameter errors or what to do with conflicts, 
409 non-existing for sip ? So the status quo is to do what has been done 
before, be pragmatic, which means: subscriber sends a request and 
notifier fills in what it can provide. The client is then responsible 
for doing requests with http, and determining what might be wrong when 
it doesn't get what it is expecting. This is usually a programming 
error, i assume, and clients must be clever enough to make the right 
decisions or have some fall-backs. That being said, i hardly think you 
could fix things without changing the code when these kind of errors happen.

But anyways, some clarification must be added to remove this implicit 
interpretation.

>>>>> 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.
>> equivalent ?. If so, i can include it (though i still don't get it 
>> (the single line), sorry ...)
>
great.

thanks, jari