Subject: [Simple] WGLC Comments on draft-ietf-sip-xcapevent-01

From: Ben Campbell <[email-masked]>
Date: Tue, 1 Apr 2008 20:53:25 -0500

Hi,

I have reviewed draft-ietf-sip-xcapevent-01 for WGLC, and have some  
comments. Apologies in advance for getting this in late.

General:

While I do not have many major technical concerns, I think the  
presentation could use some work. I share Miguel's concern that the  
organization of section 4.1 needs work.  More specifics below:

Specific Comments:

Section 4.1 Paragraph 2 (editorial):

"Once these nodes will be
    created, the notification bodies will indicate their content."

I find this sentence confusing. I suggest something like "If this node  
is later created, the notification body will indicate its content."

Section 4.4, paragraph 1(clarity):
"The usage of hierarchical lists and <entry>
    references, etc. can thus be omitted."

You say that the usage of hierarchical lists and <entry> references  
can be omitted. Are they actually being forbidden in this context, or  
do you just mean to say that they are optional? If features of the  
resource list format are forbidden, then this draft needs normative  
language saying explicitly what is not to be used. If you just mean to  
say that they are optional, what are the interoperability issues if  
one device chooses to use them but the peer does not understand them?

"As it is
    anticipated that the XCAP server will be collocated with the SIP
    notifier, the subscriber MAY use relative XCAP URIs."

Is it the authors' intention to require this collocation? That seems  
to be an architectural consequence of allowing relative URIs, unless  
we assert that if an implementation is architected differently, it is  
up to the implementation to be able to dereference relative URIs.

Paragraph 2(editorial):

"If no Accept header is specified to a SUBSCRIBE request, the NOTIFY
    messages will also contain bodies in this MIME type."

I am confused by the word "also" in this context--does this imply that  
the body in this MIME type is in addition to some other body? I think  
you just mean to say that the default is xcap-diff+xml if the Accept  
header is ommitted, but the wording is confusing.

Section 4.7, first paragraph(clarity):

"Once there are superfluous resource
    selections in the requested URI list, the notifier SHOULD NOT  
provide
    overlapping similar responses for these resources."

The sentence is confusing. "Once there are..." implies that there  
_will_ eventually be superfuous resource selections. I think you mean  
to say "If there are..."

"Only the
    resources where the authenticated user has read privilege, will be
    included in the XCAP-Diff format."

That seems like a normative statement that needs normative language.

The  last half of the paragraph is hard to follow, as it intermingles  
three distinct ideas each worthy of its own paragraph. That is, 1)  
Subscriber must have read permissions to see things, 2) Subscriptions  
to elements that don't exist yet are still kept in case the element is  
created in the future, and 3) What happens if the subscriber switches  
event parameters in a re-subscribe.

Also, have we thought about the performance and DoS implications of  
requiring the notifier to keep subscription state for elements that  
may or may not exist at some point in the future? I'm not saying there  
is a problem, but it raises a warning flag to me. I'm willing to  
believe it is okay, but it might be worth some text explaining that.

Paragraph 3 (clarity):

I'm not sure what the MUST applies to here--are you saying that the  
server MUST check for the condition you list as an example, or simply  
that, if the notifier chooses not to send XML-Patch-Ops patches for  
reasons of local policy, it MUST fall back to xcap-patching mode?

Also, I suggest reversing the order of paragraphs 3 and 4, as 4  
introduces the general principle, and 3 is more about corner cases.

Paragraph 5 (clarity):

"RFC 3265 [RFC3265]
    proposes utilization of a "version" attribute information to state
    deltas in chapter 4.4.  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."

This is confusing--you mention the version attribute but don't seem to  
indicate its use here. Why mention it at all, except maybe in a  
paragraph explaining why it wasn't chosen? OTOH, you do require the  
partial-pidf-notify approach--this needs some normative language,  
unless it is elsewhere and I missed it.

section 4.8, paragraph 1 (editorial/clarity):

"  However,
    once all atomic XCAP modifications are indicated with both previous
    and new ETags of each resource, it is easy to chain the modification
    list for a document and possibly omit some of the patches based on
    the received ETag (with HTTP) of a document."

s/"once all"/"since all"

"After that the
    subscriber MAY send a re-subscription to start the diff  
"aggregation"
    on the server."

Does this mean to imply the subscriber cannot start out with  
aggregation turned on? (I think this may be another case of presenting  
the edge case without presenting the primary use case first.)

Paragraph 2: (substantive)

You cannot safely use non-sequential CSeq to detect missing NOTIFY  
requests. For example, if the NOTIFY request is challenged by an  
intervening proxy, the subscriber will see non-sequential CSeq values.  
It may be unusual for NOTIFY to get challenged, but unless we forbid  
it, then we cannot depend on CSeq for this purpose.

Paragraph 3 (editorial/clarity):

"...look Section 5.1 of
    [I-D.ietf-simple-xml-patch-ops]..."

s/look/see

"It is
    hardly reasonable to signal this error to the notifier even if the
    error exists in the notifier process."

I think there is an implication here that should be stated explicitly,  
that is, the subscriber does not send a non-2XX response to a NOTIFY  
because of an inability to apply the patch.

Section 4.10 (substantive)

It's not clear to me how this interacts with the "aggregation"  
mechanism. In particular, if the notifier has more than one change in  
the 5 second window, but the subscriber did not allow aggregation, how  
is it handled?

Section 5, figure 3 (clarity):

It would be nice to see this in context of an actual NOTIFY.

Section 6, 2nd paragraph (nit):

There is no need for a bullet list if it contains only one bullet.

Section 7, Security Considerations (substantive)

I think we need more here. What sort of authentication is adequate  
(particularly for authenticating the notifier.) Does the potential  
sensitive content create any need for privacy and integrity protection  
beyond that generically needed for SIP-Events?

_______________________________________________
Simple mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/simple

---

From: Jari Urpalainen <[email-masked]>
Date: Wed, 02 Apr 2008 13:04:14 +0300

> organization of section 4.1 needs work.  More specifics below:
right, it will be rephrased

> is later created, the notification body will indicate its content."
much better phrased.

> up to the implementation to be able to dereference relative URIs.
in practice, the sip notifier must be aware of changes made by another 
protocol, i.e. http in this case. If these servers (notifier & http 
(xcap) daemon) are separated they need some sort of immediate mechanism 
to signal these events. It can be done with some unspecified ways, but 
the most simple one is when they are running on the very same host. 
However, even that simplest case is pretty hard (or complex enough) to 
implement properly (implementation description can be a long story 
although you are using OSS tools, like e.g. linux with Apache + 
xcap_module and some decent Sip stack with all the source code), and the 
intention is to define only the very simplest use-case here. It is not 
ruled out that they were separated but that would be much, much more 
difficult to implement, and there are many obstacles and open issues 
there. So there's magic (outside the scope of this i-d) here how to map 
the sip-uri to the xcap-root-uri, but this, the most simple use-case is 
what i'd expect to be implemented (and maybe, even some minor deployment 
as well ;-)).

Also we agreed with Miguel to be more explicit about this magic, does it 
sound sufficient to you ?
> header is ommitted, but the wording is confusing.
right, by bad finglish.
>    selections in the requested URI list, the notifier SHOULD NOT provide
right again.
> That seems like a normative statement that needs normative language.
again.
> event parameters in a re-subscribe.
I'll try to clarify it by a separation.
> believe it is okay, but it might be worth some text explaining that.
good point. there are other ways to introduce DoS as well since 
diff-processing of many resources MAY be way too process-intensive.  
I'll add that in the security section.
> reasons of local policy, it MUST fall back to xcap-patching mode?
the reason to drop the aggregation mode for that particular resource is 
that once the client have to use http, it might get out-of-sync (with 
"rapidly" changing resources), the rule is to be certain that it will 
not happen. I'll try to clarify.
> introduces the general principle, and 3 is more about corner cases.
ok.
> unless it is elsewhere and I missed it.
yep, this was notified by Miguel also

>    the received ETag (with HTTP) of a document."
ok.
>
> "After that the
>    subscriber MAY send a re-subscription to start the diff "aggregation"
>    on the server."
>
it can try to start in the aggregate mode straight away, but it may 
fail. So the safe way is to disable aggregation first before sync is 
achieved and enable it afterwards. I think I'll add something about this 
into those dreaded examples (in an appendix)
> it, then we cannot depend on CSeq for this purpose.
ok, didn't think about that at all.
>    [I-D.ietf-simple-xml-patch-ops]..."
ok.
> because of an inability to apply the patch.
right.
> the 5 second window, but the subscriber did not allow aggregation, how 
yep this is indeed _difficult_. Easy to write (one sentence only), but 
really, really hard to implement properly ;-). First off there's a 
SHOULD directive fortunately... I'm not 100 % sure if you mean that 
xcap-patching is also disabled. So there's not a big difference in this 
context whether you have aggregation or xcap-patching modes, since in 
the xcap-patching mode you will see changes e.g. from "a" to "b" to "c" 
with all corresponding Etags while in the aggregate mode you'll see e.g. 
only changes from "a" to "c" in the notification body without the 
intermediate state. Certainly aggregation body is smaller but it fails 
to show the versioning history and the diff formats differ, but the end 
result will be the same certainly, i.e. "c". So _if_ you obey the timer, 
you wait for it to expire and then send the result in both cases (and of 
course during this timer interval you wait for any changes in these 
resources, and do something relevant, e.g. store internal object 
states).  If there's not any patching modes applied, then you should 
wait for the timer to expire and send appropriate actions, i.e. 
document(s) has either been created, modified or deleted. IIRC, in 
partial PIDF where we use the exact same patchings there's not a single 
line about this since this timer is inherited from the base PIDF 
package. In summary, you just don't have to do anything mysterious with 
timers except wait for a certain period of time. In practice, it happens 
to be quite a challenging task (but these specs usually _ignore_ the 
implementation PITA ;-))
> It would be nice to see this in context of an actual NOTIFY.
I'll try to digest something into an appendix. That being said, the 
important things are bodies...

> There is no need for a bullet list if it contains only one bullet.
right.
> beyond that generically needed for SIP-Events?
yep, besides DoS TLS & S/MIME recommendations some text about identity 
"mapping" between http & sip would be reasonable. Anything else ?

THANKS Ben,

Jari

---

From: Ben Campbell <[email-masked]>
Date: Wed, 2 Apr 2008 11:16:43 -0500

Thanks for the quick response. My comments for anything that still  
seems like an open issue are inline:

> ext Ben Campbell wrote:

[...]

>> can be omitted. Are they actually being forbidden in this context,  
>> or do you just mean to say that they are optional? If features of  
>> the resource list format are forbidden, then this draft needs  
>> normative language saying explicitly what is not to be used. If you  
>> just mean to say that they are optional, what are the  
>> interoperability issues if one device chooses to use them but the  
>> peer does not understand them?

Do you have any thoughts concerning the above comment?

>> Is it the authors' intention to require this collocation? That  
>> seems to be an architectural consequence of allowing relative URIs,  
>> unless we assert that if an implementation is architected  
>> differently, it is up to the implementation to be able to  
>> dereference relative URIs.
>>
> in practice, the sip notifier must be aware of changes made by  
> another protocol, i.e. http in this case. If these servers (notifier  
> & http (xcap) daemon) are separated they need some sort of immediate  
> mechanism to signal these events. It can be done with some  
> unspecified ways, but the most simple one is when they are running  
> on the very same host. However, even that simplest case is pretty  
> hard (or complex enough) to implement properly (implementation  
> description can be a long story although you are using OSS tools,  
> like e.g. linux with Apache + xcap_module and some decent Sip stack  
> with all the source code), and the intention is to define only the  
> very simplest use-case here. It is not ruled out that they were  
> separated but that would be much, much more difficult to implement,  
> and there are many obstacles and open issues there. So there's magic  
> (outside the scope of this i-d) here how to map the sip-uri to the  
> xcap-root-uri, but this, the most simple use-case is what i'd expect  
> to be implemented (and maybe, even some minor deployment as well ;-)).
>
> Also we agreed with Miguel to be more explicit about this magic,  
> does it sound sufficient to you ?

Likely. As long as we mention the need for the notifier to learn about  
changes at the XCAP server, and that such mechanisms are out of scope  
for this document. It makes sense to mention collocation as an example  
way to solve this, but it's only an example.

[...]

>> server MUST check for the condition you list as an example, or  
>> simply that, if the notifier chooses not to send XML-Patch-Ops  
>> patches for reasons of local policy, it MUST fall back to xcap- 
>> patching mode?
> the reason to drop the aggregation mode for that particular resource  
> is that once the client have to use http, it might get out-of-sync  
> (with "rapidly" changing resources), the rule is to be certain that  
> it will not happen. I'll try to clarify.

Thanks. I think it would be helpful to have a section dedicated  
describing the issue, and mention the ways to work around it.

[...]

>> aggregation turned on? (I think this may be another case of  
>> presenting the edge case without presenting the primary use case  
>> first.)
> achieved and enable it afterwards. I think I'll add something about  
> this into those dreaded examples (in an appendix)

See my previous comment about having a separate section to describe  
the issue and possible solutions. It's also important that we are  
clear on whether the delayed activation of "aggregation" mode is  
simply an optional solution to a potential issue, or is a normative  
requirement.

>> intervening proxy, the subscriber will see non-sequential CSeq  
>> values. It may be unusual for NOTIFY to get challenged, but unless  
>> we forbid it, then we cannot depend on CSeq for this purpose.

This one needs some thought, then. There are actually a lot more  
causes than just digest challenges that may cause the client to see  
non-sequential CSeqs. If detection of lost notifies is critical, we  
need another solution (either to detect lost notifies or to remove the  
need to do so.)

>> mechanism. In particular, if the notifier has more than one change  
>> in the 5 second window, but the subscriber did not allow  
>> aggregation, how is it handled?
> yep this is indeed _difficult_. Easy to write (one sentence only),  
> but really, really hard to implement properly ;-). First off there's  
> a SHOULD directive fortunately... I'm not 100 % sure if you mean  
> that xcap-patching is also disabled. So there's not a big difference  
> in this context whether you have aggregation or xcap-patching modes,  
> since in the xcap-patching mode you will see changes e.g. from "a"  
> to "b" to "c" with all corresponding Etags while in the aggregate  
> mode you'll see e.g. only changes from "a" to "c" in the  
> notification body without the intermediate state. Certainly  
> aggregation body is smaller but it fails to show the versioning  
> history and the diff formats differ, but the end result will be the  
> same certainly, i.e. "c". So _if_ you obey the timer, you wait for  
> it to expire and then send the result in both cases (and of course  
> during this timer interval you wait for any changes in these  
> document(s) has either been created, modified or deleted.

I'm not sure I understand what you mean on the last two sentences--can  
you give an example?

> IIRC, in partial PIDF where we use the exact same patchings there's  
> not a single line about this since this timer is inherited from the  
> base PIDF package. In summary, you just don't have to do anything  
> mysterious with timers except wait for a certain period of time. In  
> practice, it happens to be quite a challenging task (but these specs  
> usually _ignore_ the implementation PITA ;-))

It's still not clear to me if this is just a "hard implementation"  
problem or if it is really a conflict in normative requirements.  
Coding aside, what do you expect the most commen behavior to be if  
multiple changes occur inside the 5 second window, but the client has  
not allowed aggregation? (The example requested above might help me  
understand this.)

> important things are bodies...

To some degree, it is up to the companion draft to define the body in  
detail--this draft really talks about the SIP-event package, so I do  
think it is appropriate to show real message flows including the SIP  
parts.

[...]

>> sensitive content create any need for privacy and integrity  
>> protection beyond that generically needed for SIP-Events?
>>
> yep, besides DoS TLS & S/MIME recommendations some text about  
> identity "mapping" between http & sip would be reasonable. Anything  
> else ?

I had not thought of the identity mapping issue--that discussion  
always seems to get more "interesting" than you might expect :-)  It  
might be worth adding SIPS thoughts to any TLS discussion.

Thanks!

Ben.

---

From: Jari Urpalainen <[email-masked]>
Date: Thu, 03 Apr 2008 15:28:53 +0300

> Do you have any thoughts concerning the above comment?
Sorry, i already made an actual fix, but forgot to reply.  Yep, these 
are "sophisticated" features which don't bring in any value here --> 
"...MUST NOT be used"

>>> we assert that if an implementation is architected differently, it 
>>> is up to the implementation to be able to dereference relative URIs.
>>>
>> unspecified ways, but the most simple one is when they are running on 
>> the very same host. However, even that simplest case is pretty hard 
>> (or complex enough) to implement properly (implementation description 
>> can be a long story although you are using OSS tools, like e.g. linux 
>> with Apache + xcap_module and some decent Sip stack with all the 
>> source code), and the intention is to define only the very simplest 
>> use-case here. It is not ruled out that they were separated but that 
>> would be much, much more difficult to implement, and there are many 
>> obstacles and open issues there. So there's magic (outside the scope 
>> of this i-d) here how to map the sip-uri to the xcap-root-uri, but 
>> this, the most simple use-case is what i'd expect to be implemented 
>> (and maybe, even some minor deployment as well ;-)).
>>
>> Also we agreed with Miguel to be more explicit about this magic, does 
>> it sound sufficient to you ?
>
fine.
>>> patches for reasons of local policy, it MUST fall back to 
>>> xcap-patching mode?
i 've added a whole new chapter about this into the "notifier 
generation" and re-arranged things so that it SHOULD be now much more 
unambiquous.

> simply an optional solution to a potential issue, or is a normative 
As the aggregate mode has its drawbacks when versioning is not supported 
in http, I think I've managed to fix the text...
> need another solution (either to detect lost notifies or to remove the 
now I've managed to put this "utter crap" myself :-), sorry, i.e. 
unordering doesn't happen when the notifier acts _properly_, so it's 
better to move that text altogether.
>> a SHOULD directive fortunately... I'm not 100 % sure if you mean that 
>> xcap-patching is also disabled. So there's not a big difference in 
>> this context whether you have aggregation or xcap-patching modes, 
>> since in the xcap-patching mode you will see changes e.g. from "a" to 
>> "b" to "c" with all corresponding Etags while in the aggregate mode 
>> you'll see e.g. only changes from "a" to "c" in the notification body 
>> without the intermediate state. Certainly aggregation body is smaller 
>> but it fails to show the versioning history and the diff formats 
>> differ, but the end result will be the same certainly, i.e. "c". So 
>> _if_ you obey the timer, you wait for it to expire and then send the 
>> result in both cases (and of course during this timer interval you 
>> wait for any changes in these resources, and do something relevant, 
>> e.g. store internal object states).  If there's not any patching 
>> modes applied, then you should wait for the timer to expire and send 
>> appropriate actions, i.e. document(s) has either been created, 
>> modified or deleted.
>
btw. just noted that a rate limit was per a _user_ what would that mean 
? so should be per _subscription_.

let's say you'll notify a initial document at some time x. then comes 
two changes 1 & 2 for the same document within 2 seconds (ETags are 
those timestamps):
 
NOTIFY  1  --  x 
change 1    --  x+1s.
change 2    --  x+2s.
NOTIFY 2  -- x+5s.

so if those two changes are reported (NOTIFY 2) _without any patching_ 
you'll report the document uri reference with Etags at time x+5s due to 
this 5s rate limitation:
<xcap-diff  xcap-root="http://xcap.example.com/root/">
   <document new-etag="x+2s"
             sel="resource-lists/users/sip:[email-masked]/coworkers"
             previous-etag="x"/>
</xcap-diff>

with xcap-patching you could have:

<xcap-diff  xcap-root="http://xcap.example.com/root/">
   <document new-etag="x+1s"
             sel="resource-lists/users/sip:[email-masked]/coworkers"
             previous-etag="x">
       <add sel="*"><foo/></add>
  </document>
  <document new-etag="x+2s"
             sel="resource-lists/users/sip:[email-masked]/coworkers"
             previous-etag="x+1s">
       <add sel="*"><bar/></add>
  </document>
</xcap-diff>

while with the "aggregate" mode:

<xcap-diff  xcap-root="http://xcap.example.com/root/">
   <document new-etag="x+2s"
             sel="resource-lists/users/sip:[email-masked]/coworkers"
             previous-etag="x">
       <add sel="*"><foo/><bar/></add>
  </document>
</xcap-diff>

So the first one shows the simplest case, and then the more complex 
xcap-patching and lastly aggregate, does this help ? I've the intention 
to add something similar to an appendix regardless of the pain...

So as can be seen from the example "aggregate" and "xcap-patching" both 
aggregate patches, but the "real" aggregate can do much clever decisions 
with the added complexity.

And i've made it now explicit that the notifier MAY respond with all of 
these 3 ways if aggregate is requested. If notifier requests 
xcap-patching "aggregate" MUST NOT be used, and with "no-patching" 
naturally only the simplest mode is allowed.

> not allowed aggregation? (The example requested above might help me 
imo it is not a conflict, just a PITA in implementations, though 
sometimes a very nice optimization.
> think it is appropriate to show real message flows including the SIP 
yep, though from sip event pov. only the event-paramer and conditional 
headers are really relevant, and indeed the body examples are not shown 
in other specs, which allow virtually everything. In this case, this 
package _requires_ those limitations to those formats with/without 
patching, so it is definitely good to have good examples.

> might be worth adding SIPS thoughts to any TLS discussion.
yep.
> Ben.

Thanks again,
Jari

---

From: Ben Campbell <[email-masked]>
Date: Thu, 3 Apr 2008 08:28:49 -0500

On Apr 3, 2008, at 7:28 AM, Jari Urpalainen wrote:

[...]

>>>> You cannot safely use non-sequential CSeq to detect missing  
>>>> NOTIFY requests. For example, if the NOTIFY request is challenged  
>>>> by an intervening proxy, the subscriber will see non-sequential  
>>>> CSeq values. It may be unusual for NOTIFY to get challenged, but  
>>>> unless we forbid it, then we cannot depend on CSeq for this  
>>>> purpose.
>> need another solution (either to detect lost notifies or to remove  
>> the need to do so.)

The text was more about missing NOTIFY requests than it was out-of- 
order NOTIFYs (CSeq will actually catch the out-of-order case). Are  
you saying that it is okay to not be able to detect missing NOTIFYs,  
even in patch mode? Note that missing and out-of-order notifies can  
(rarely, we hope)  happen due to intervening devices even if the  
notifier is perfectly well behaved.

>>>> mechanism. In particular, if the notifier has more than one  
>>>> change in the 5 second window, but the subscriber did not allow  
>>> but really, really hard to implement properly ;-). First off  
>>> there's a SHOULD directive fortunately... I'm not 100 % sure if  
>>> you mean that xcap-patching is also disabled. So there's not a big  
>>> difference in this context whether you have aggregation or xcap- 
>>> patching modes, since in the xcap-patching mode you will see  
>>> changes e.g. from "a" to "b" to "c" with all corresponding Etags  
>>> while in the aggregate mode you'll see e.g. only changes from "a"  
>>> to "c" in the notification body without the intermediate state.  
>>> Certainly aggregation body is smaller but it fails to show the  
>>> versioning history and the diff formats differ, but the end result  
>>> will be the same certainly, i.e. "c". So _if_ you obey the timer,  
>>> you wait for it to expire and then send the result in both cases  
>>> (and of course during this timer interval you wait for any changes  
>>> in these resources, and do something relevant, e.g. store internal  
>>> object states).  If there's not any patching modes applied, then  
>>> you should wait for the timer to expire and send appropriate  
>>> actions, i.e. document(s) has either been created, modified or  
>>> deleted.
>>
>> I'm not sure I understand what you mean on the last two sentences-- 
>> can you give an example?
> btw. just noted that a rate limit was per a _user_ what would that  
> mean ? so should be per _subscription_.
>
> let's say you'll notify a initial document at some time x. then  
> comes two changes 1 & 2 for the same document within 2 seconds  
> (ETags are those timestamps):
> NOTIFY  1  --  x change 1    --  x+1s.
> change 2    --  x+2s.
> NOTIFY 2  -- x+5s.
>
> so if those two changes are reported (NOTIFY 2) _without any  
> patching_ you'll report the document uri reference with Etags at  
> time x+5s due to this 5s rate limitation:
> </xcap-diff>'

Ah, I see you are effectively listing both change events in a single  
xcap-diff document, but still as separate events. That makes sense,  
but it was not obvious to me from the text that you could do this. I  
don't recall if the data format doc addressed it or not. It would  
definitely help to include examples for each mode of operation.

> xcap-patching and lastly aggregate, does this help ? I've the  
> intention to add something similar to an appendix regardless of the  
> pain...
>
> So as can be seen from the example "aggregate" and "xcap-patching"  
> both aggregate patches, but the "real" aggregate can do much clever  
> decisions with the added complexity.
>
> And i've made it now explicit that the notifier MAY respond with all  
> of these 3 ways if aggregate is requested. If notifier requests xcap- 
> patching "aggregate" MUST NOT be used, and with "no-patching"  
>>> IIRC, in partial PIDF where we use the exact same patchings  
>>> there's not a single line about this since this timer is inherited  
>>> from the base PIDF package. In summary, you just don't have to do  
>>> anything mysterious with timers except wait for a certain period  
>>> of time. In practice, it happens to be quite a challenging task  
>>> (but these specs usually _ignore_ the implementation PITA ;-))
>>
>> multiple changes occur inside the 5 second window, but the client  
>> has not allowed aggregation? (The example requested above might  
>> help me understand this.)
>>

I _think_ I am okay with this, pending seeing the new text.

[...]

Thanks!

Ben.

---

From: Jari Urpalainen <[email-masked]>
Date: Thu, 03 Apr 2008 17:39:22 +0300

ext Ben Campbell wrote:
> The text was more about missing NOTIFY requests than it was 
> out-of-order NOTIFYs (CSeq will actually catch the out-of-order case). 
> Are you saying that it is okay to not be able to detect missing 
> NOTIFYs, even in patch mode? Note that missing and out-of-order 
> notifies can (rarely, we hope)  happen due to intervening devices even 
> if the notifier is perfectly well behaved.
>
the implicit rule _now_ for the notifier is: if you don't get a final 
200 ack for a notify, do not send a new request and for a timeout, tear 
down the session (this is what i propose but as explicit). So what 
happens with  4xx, 5xx, 6xx etc is unspecified. So the rule for waiting 
for the 200 OK rules out-of-order. So if you get 4/5/6xx will that mean 
drop-out possibility ? no imo, since you can't send a new one unless the 
previous one has been sent successfully. So personally i _could_ go that 
far that tear down always if return code != 200, but probably some 
intelligent notifiers could resolve e.g. 413, though i have my doubts....
>>>> there's a SHOULD directive fortunately... I'm not 100 % sure if you 
>>>> mean that xcap-patching is also disabled. So there's not a big 
>>>> difference in this context whether you have aggregation or 
>>>> xcap-patching modes, since in the xcap-patching mode you will see 
>>> I'm not sure I understand what you mean on the last two 
>>> sentences--can you give an example?
>> patching_ you'll report the document uri reference with Etags at time 
>> x+5s due to this 5s rate limitation:
it is in the format spec, it was implicit in some older versions, but i 
fixed that:
"If several <document>
   elements with the same "sel" selector value exist in the XCAP diff
   document, i.e. for example, the full ETag change history is
   indicated, the corresponding patches MUST be appliable in the given
   document order."
>> of these 3 ways if aggregate is requested. If notifier requests 
>>>> practice, it happens to be quite a challenging task (but these 
>>>> specs usually _ignore_ the implementation PITA ;-))
>>>
>>> has not allowed aggregation? (The example requested above might help 
>>> me understand this.)
>>>
great, i really hope you have time to look at the updated text when i 
get it "fully" ready with those reasonable examples ...

thanks,
Jari

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 03 Apr 2008 11:18:45 -0400

> intelligent notifiers could resolve e.g. 413, though i have my doubts....

It is always be possible to get a 401 or 407 response to a NOTIFY, and 
it should be possible to retry it with the proper credentials. That 
ought not screw up the subscription. This could happen because your 
nonce expired on a long lived subscription.

Admittedly it would be pretty odd to have authorization in the NOTIFY 
direction, but it could be possible I think.

	Paul

---

From: Ben Campbell <[email-masked]>
Date: Thu, 3 Apr 2008 10:45:59 -0500

On Apr 3, 2008, at 9:39 AM, Jari Urpalainen wrote:

[...]

>>>>>> NOTIFY requests. For example, if the NOTIFY request is  
>>>>>> challenged by an intervening proxy, the subscriber will see non- 
>>>>>> sequential CSeq values. It may be unusual for NOTIFY to get  
>>>>>> challenged, but unless we forbid it, then we cannot depend on  
>>>>>> CSeq for this purpose.
>>>> causes than just digest challenges that may cause the client to  
>>>> see non-sequential CSeqs. If detection of lost notifies is  
>>>> critical, we need another solution (either to detect lost  
>>>> notifies or to remove the need to do so.)
>>> unordering doesn't happen when the notifier acts _properly_, so  
>>> it's better to move that text altogether.
>>
>> you saying that it is okay to not be able to detect missing  
>> notifies can (rarely, we hope)  happen due to intervening devices  
>> even if the notifier is perfectly well behaved.
>>
> the implicit rule _now_ for the notifier is: if you don't get a  
> final 200 ack for a notify, do not send a new request and for a  
> timeout, tear down the session (this is what i propose but as  
> explicit). So what happens with  4xx, 5xx, 6xx etc is unspecified.  
> So the rule for waiting for the 200 OK rules out-of-order. So if you  
> get 4/5/6xx will that mean drop-out possibility ? no imo, since you  
> can't send a new one unless the previous one has been sent  
> successfully. So personally i _could_ go that far that tear down  
> always if return code != 200, but probably some intelligent  
> notifiers could resolve e.g. 413, though i have my doubts....

Ah, I _think_ that helps, although keep in mind that not all non-200  
responses necessarily indicate the subscription should be torn down.