Subject: Re: [sipcore] Event rate control and GEOPRIV requirements

From: <[email-masked]>
Date: Thu, 10 Dec 2009 10:08:36 +0100

Hi Martin,

I will issue an updated version of the draft within the next couple of weeks and adopt your preference making the Event header field optional for 2xx to NOTIFY (in order to cover the case when someone  doesn't need this particular feature but otherwise implementing the max-interval functionality).

Cheers,
Krisztian

-----Original Message-----
From: ext Thomson, Martin [mailto:[email-masked]] 
Sent: Sunday, November 08, 2009 10:59 PM
To: Kiss Krisztian (Nokia-CIC/MtView); [email-masked]
Cc: [email-masked]
Subject: RE: [sipcore] Event rate control and GEOPRIV requirements

I don't think that there is a conflict.

If the subscriber wishes to change details, then they can provide the header.  If they do not provide the header - as is the existing behaviour - the values do not change.

Of course, if the _header_ is present, then the parameter must be, but that is not what the text in the document says.

Making this mandatory also makes it mandatory for those who implement this feature but don't intend to use it.  Let's not break existing event package implementations.

--Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, 9 November 2009 3:50 PM
> To: [email-masked]; Thomson, Martin
> Cc: [email-masked]
> Subject: RE: [sipcore] Event rate control and GEOPRIV requirements
> 
> Hi,
> 
> Making it optional may create a conflict with the following statement:
> 
>    A subscriber that wishes to remove the minimum rate control from
>    notifications MUST indicate so by not including a "max-interval"
>    Event header field parameter in a subsequent SUBSCRIBE request or a
>    200-class response to the NOTIFY request.
> 
> An Event header field without the "max-interval" parameter means that 
> the subscriber is deleting the "max-interval" feature from 
> notifications. Should we now allocate a special meaning for the case 
> when no Event header field exists in the 2xx response to the NOTIFY?
> Does that mean the "max-interval" parameter is not touched from the 
> previous value? Or something else? I'd prefer the same behavior as for 
> the SUBSCRIBE request, i.e. the "max-interval" parameter is always 
> present reflecting the current value and the lack of the parameter 
> means that the feature is deleted from notifications.
> 
> Existing implementations do not support Event header field in the 2xx 
> responses to NOTIFY, however new implementations adding the rate- 
> control feature to notifications will support adding the rate control 
> parameters to the Event header field in SUBSCRIBE and 2xx to NOTIFY as 
> well as the Subscription-State header field in NOTIFYs. As RFC 3265 
> did not define the Event header field to 2xx to NOTIFY, 
> draft-ietf-sipcore- event-rate-control has to do this in order to have 
> a placeholder for the new parameter.
> 
> Cheers,
> Krisztian
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of ext Salvatore Loreto
> Sent: Sunday, November 08, 2009 9:49 PM
> To: Thomson, Martin
> Cc: [email-masked]
> Subject: Re: [sipcore] Event rate control and GEOPRIV requirements
> 
> Hi Martin,
> 
> good point, I think we can relax it to optional .
> 
> /Sal
> 
> Thomson, Martin wrote:
> > Hi Sal,
> >
> > Thanks for the pointer.
> >
> > Regarding section 8.3, which addresses the requirement in question:
> >
> > I'm not sure why you would make the Event header mandatory in the 
> > 2xx
> responses.  Optional seems to make more sense to me.  Existing 
> implementations don't do this, after all.
> >
> >
> >> -----Original Message-----
> >> From: Salvatore Loreto [mailto:[email-masked]]
> >> Sent: Monday, 9 November 2009 2:25 PM
> >> To: Thomson, Martin
> >> Cc: [email-masked]
> >> Subject: Re: [sipcore] Event rate control and GEOPRIV requirements
> >>
> >> Hi Martin,
> >>
> >> an updated version of the event-rate-control draft was submitted 
> >> two days after the IETF76 deadline, for this reason it is not yet 
> >> on the I-D repository, however it will be available soon
> >>
> >> for the time being you can fetch a copy from
> >> http://krkiss.letolt.info/draft-ietf-sipcore-event-rate-control-
> 01.tx
> >> t
> >>
> >> /Sal
> >>
> >> Thomson, Martin wrote:
> >>
> >>> Is the -00 version the latest issue of this draft?  I expected a -
> 01
> >>>
> >> and so was under the impression that we were discussion changes 
> >> already made.
> >>
> >>> The following two minor changes were requested out of the GEOPRIV 
> >>> use
> >>>
> >> cases:
> >>
> >>>  - note that the rate control parameters can be updated in 
> >>> response
> >>>
> >> messages (i.e. the 200 response to an initial NOTIFY); the notifier 
> >> then indicates the agreed (and possibility modified) values in 
> >> subsequent NOTIFYs
> >>
> >>>  - note that rate control parameters can be changed at any time by
> >>>
> >> the notifier, based on policy- or implementation-determined 
> >> constraints
> >>
> >>> This is what we discussed in the meeting.
> >>>
> >>> I think that the second one is OK in the version -00 draft.  I
> could
> >>>
> >> not find anywhere that mentioned updating event parameters in a 
> >> response message.
> >>
> >>> --Martin
> >>>
> >>> _______________________________________________
> >>> sipcore mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/sipcore
> >>>
> >>>
> >
> >
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 11 Dec 2009 05:57:00 +0800

I think that we've misunderstood each other.

The Event header _parameter_ can be made mandatory.  I think that it should be mandatory if the notifier is applying rate control.

The table in the draft currently states that the Event _header_ is mandatory.  That was what I objected to.

Now, you can made the header mandatory as long as you qualify it sufficiently.  I actually think that the text in Section 8.3 is a little strong.  I'd prefer to use MAY instead of MUST.  After all, we don't want to diverge from existing behaviour too much: no subscriber includes the Event header in a 2xx response currently and they manage.

8.3. Event header field usage in responses to the NOTIFY request

   Implementations using the extensions described in this document *MAY*
   include an Event header field in any 200-class responses to NOTIFY
   requests.

   The following table expands the table described in Section 7.2 of
   SIP Events [RFC3265] allowing the Event header field to appear in a
   200-class response to a NOTIFY request.

      Header field      where proxy ACK BYE CAN INV OPT REG PRA SUB NOT
      -----------------------------------------------------------------
      Event             2xx          -   -   -   -   -   -   -   -   *o*
<<

--Martin

> Sent: Thursday, 10 December 2009 8:09 PM
> To: Thomson, Martin; [email-masked]
> Cc: [email-masked]
> I will issue an updated version of the draft within the next couple of
> weeks and adopt your preference making the Event header field optional
> for 2xx to NOTIFY (in order to cover the case when someone  doesn't
> need this particular feature but otherwise implementing the max-
> interval functionality).
> 
> Cheers,
> Krisztian
> 
> If the subscriber wishes to change details, then they can provide the
> header.  If they do not provide the header - as is the existing
> behaviour - the values do not change.
> 
> Of course, if the _header_ is present, then the parameter must be, but
> that is not what the text in the document says.
> 
> Making this mandatory also makes it mandatory for those who implement
> this feature but don't intend to use it.  Let's not break existing
> event package implementations.
> 
> --Martin
>