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

[Adam Roach <[e-mail]>]

  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