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

[Robert Sparks <[e-mail]>]

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