Re: [sipcore] AD review: draft-ietf-sipcore-event-rate-control-03

[Robert Sparks <[e-mail]>]

sigh - critical typo correction below:

On Jul 19, 2010, at 2:24 PM, Robert Sparks wrote:

> This reply clarified my discomfort - thanks.
> 
> Your point of syntactic concession was essential - it made sense to add parameters to the Event header in requests,
> so as a matter of convenience, the draft is reusing the Event header and the new parameters  for the special case 
> where you are wanting to convey information in a response. The group could well have chosen a new header with 
> the same contents for inclusion in responses (I don't think folks explicitly considered this?), but this thing that looked
> like the Event header was around, so it was easier to use that. This is only an issue in that  if we ever  wanted to more 
> generally take advantage of the Event header in responses, whatever we did would be constrained by this document 
> and the semantics for an Event header showing up in a 200 to a NOTIFY that it defines.
> 
> As it stands, this document needs to do a few things it doesn't yet:
> 
> 1) Explicitly call out that the use of the Event header field  in responses other than 200 OKs to NOTIFYs is (still) undefined.
> 
> 2) Explicitly note than any of the other parameters currently defined for the Event header do
->NOT<-
> have meaning if copied from
>     the NOTIFY into it's 200 OK (so that we don't have people being surprised when they return a 200 OK with an
>     expires= with some shorter value and it doesn't shorten their subscription).
> 
> 3) State that the event-type can't be changed between the NOTIFY and it's 200 OK (yes, that seems obvious, but..,)
> 
> 4) So that someone stumbling across an Event header field in a 200 OK to a NOTIFY can look up what it means, 
>     this document should update the IANA registry at <http://www.iana.org/assignments/sip-parameters> as follows:
> 
>     OLD:
>        Event                o        [RFC3265]
>     NEW:
>        Event                o        [RFC3265][RFC-ietf-sipcore-event-rate-control]
> 
> (btw - I assume it is intended to be ok to use the short-form ("o" ) in responses?)
> 
> Personally, because of thought's like what I have in 2) above,  I feel there's a good chance we're making another 
> ACK-200/ACK-non200 mistake that we could be avoiding.
> 
> RjS
> 
> 
> 
> On Jul 13, 2010, at 5:18 PM, Adam Roach wrote:
> 
>> On 7/13/10 16:23, Jul 13, Robert Sparks wrote:
>>> I don't think it's as clear-cut as that.
>>> 
>>> 4662 used the extension points 3265 expected to be used.
>> 
>> Not any more than anything else. The extension points that 3265 defines are new event packages. 4662 uses feature tags to negotiate usage -- a basic SIP extension mechanism.
>> 
>> Event-rate-control uses new header field parameters -- another basic SIP extension mechanism.
>> 
>>> Someone that had written a network monitor, for example, just using
>>> 3265 for reference could have produced code that made sense out of a stream of messages emitted by implementations of 4662.
>>> 
>>> That same code would probably not do the right thing with a stream of messages from this spec
>> 
>> I can't imagine why not. It will look like a stream of state information sent in NOTIFY messages.
>> 
>> I also don't have a lot of sympathy for the "network monitor" use case as a motivator unless we're going to explicitly deprecate TLS and S/MIME.
>> 
>> 
>>> - at the very least, it wouldn't know to be looking for Event headers in 200 responses
>> 
>> No, and it won't know to care about them either. Which is exactly the right thing to do reaction.
>> 
>> The event header fields in responses are there as a syntactic concession -- we needed somewhere to hang the parameters. The actual event name itself can't change. It can be safely ignored by network monitors, and they'll do the right thing.
>> 
>>> What does 3265bis say about Event headers in responses to NOTIFYs at the moment?
>> 
>> Nothing yet. I have a note to add text addressing this case (as well as the suppressed NOTIFY situation that arises from subnot-etags).
>> 
>> /a
>