Re: Comments on draft-niemi-sipping-event-throttle-06

The change in location would not trigger a notification based on min.
However, if min was set, time would trigger a notification.  If you
unconditionally exclude location, the PIDF wouldn't contain location I would
think.

Brian

> -----Original Message-----
> From: sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org] On Behalf
> Of Paul Kyzivat
> Sent: Saturday, August 09, 2008 12:42 AM
> To: krisztian.kiss <at> nokia.com
> Cc: sipping <at> ietf.org
> Subject: Re: [Sipping] Comments on draft-niemi-sipping-event-throttle-06
> 
> Hi Krisztian,
> 
> krisztian.kiss <at> nokia.com wrote:
> > Hi Paul et al,
> >
> >> Or are you saying that you will receive a notification after Y
> >> seconds if the event state has changed, even if the result
> >> after applying filters is unchanged???
> >
> > That is exactly the idea. If you look at the use case Brian described
> > as...
> > "send me an update when the target has moved at least 10 meters, but
> > don't send more than 10 updates per minute.  Also, if the target hasn't
> > moved more than 10 meters in a minute, send me an update anyway" you
> > would get a NOTIFY if the target moved 9 meters and one minute already
> > passed from the last notification.
> 
> Well, it still seems a bit odd to me. But I think the main thing thatSo,
> needs to be considered is to distinguish between voluntary filters
> applied by request of the caller, and authorization based filters that
> are applied because a subscriber isn't permitted to see certain parts of
> the state. In that case, notifications that show no change would leak
> information about state changes to inaccessible information.
> 
> If the filter is just related to the amount of change, not masking a
> particular piece of state, then this isn't a problem. But then this only
> applies to that class of filter.
> 
> So just to double check - if I am subscribed to presence with a filter
> that says to unconditionally exclude location - and I have a "min"
> throttle - will a change to the location trigger a notification based on
> the min throttle?
> 
> 	Thanks,
> 	Paul
> 
> > I also prefer this approach (adding a "min" value to throttle) instead
> > of letting the watcher constantly monitor whether the supplied filter is
> > still satisfactory and re-SUBSCRIBE with new filter if needed.  The
> > watcher could still do that in some cases but in most cases enough
> > NOTIFYs could be received thanks to the "min" value.
> >
> > During the discussion with Brian, Salvatore and Adam we also discussed
> > adding an average rate as a 3rd parameter to throttle.  Some
> > applications may need that in addition to minimum time between
> > notifications. We need some kind averaging algorithm, nothing really
> > complex but a simple running average. It would be good to extend the
> > discussion also about this parameter and get the WG's feedback.
> >
> > Cheers,
> > Krisztian
> >
> >> -----Original Message-----
> >> From: sipping-bounces <at> ietf.org
> >> [mailto:sipping-bounces <at> ietf.org] On Behalf Of ext Paul Kyzivat
> >> Sent: Thursday, August 07, 2008 9:20 AM
> >> To: Salvatore Loreto
> >> Cc: 'sipping'
> >> Subject: Re: [Sipping] Comments on
> >> draft-niemi-sipping-event-throttle-06
> >>
> >>
> >>
> >> Salvatore Loreto wrote:
> >>> Hi Paul,
> >>>
> >>> just to clarify,
> >>> with the *max=X* you are asking not to receive more then a Notify
> >>> every X seconds, no matter what will happen during the X
> >> seconds with
> >>> the *mix=Y* you are asking to receive an update, if something has
> >>> changed, every Y second. So if you won't receive anything after Y
> >>> second you can relay on the fact that nothing is changed .
> >> OK, at least you aren't proposing to send every Y seconds even
> >> if nothing has changed!
> >>
> >> But what is the difference between the min present and the min absent?
> >> What you describe sounds like what would happen anyway - when
> >> there is a change, you get notified.
> >>
> >> Of course the notifier will always have some latency, and so
> >> may not get around to sending for awhile. But I don't think
> >> you can legislate that away.
> >>
> >> Or are you saying that you will receive a notification after Y
> >> seconds if the event state has changed, even if the result
> >> after applying filters is unchanged???
> >>
> >> 	Paul
> >>
> >>> Sal
> >>>
> >>>
> >>> Paul Kyzivat wrote:
> >>>>
> >>>> Brian Rosen wrote:
> >>>>> It works, it's just too much signaling. It's also hard for the
> >>>>> watcher to know when to switch.
> >>>>>
> >>>>> I really think min is s simpler mechanism.
> >>>>>
> >>>>> I've been talking to the throttle authors. I'll have a proposal on
> >>>>> the list shortly.
> >>>> I hear you. I understand it is simpler. But I just have trouble
> >>>> making any *sense* semantically out of a minimum frequency
> >> for a throttle.
> >>>> I certainly hope it won't have you sending *identical* data when
> >>>> nothing has changed since the last send.
> >>>>
> >>>> Paul
> >>>>
> >>>>> Brian
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Paul Kyzivat [mailto:pkyzivat <at> cisco.com]
> >>>>>> Sent: Thursday, July 31, 2008 10:22 PM
> >>>>>> To: Brian Rosen
> >>>>>> Cc: 'sipping'
> >>>>>> Subject: Re: [Sipping] Comments on
> >>>>>> draft-niemi-sipping-event-throttle-06
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Brian Rosen wrote:
> >>>>>>> I agree: we could instantiate two independent
> >> subscriptions, with
> >>>>>>> two independent filters, two throttles, etc, and get
> >> what we want.
> >>>>>>> We could also have a min throttle option.
> >>>>>> That isn't what I meant.
> >>>>>> Start the subscription with one filter and one throttle.
> >>>>>> When that isn't what you want any longer, change it to a
> >> different
> >>>>>> filter and a different throttle.
> >>>>>>
> >>>>>> AFAICT you don't need both settings at the same time.
> >>>>>>
> >>>>>> Paul
> >>>>>>
> >>>>>>
> >>>>>>> Brian
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Paul Kyzivat [mailto:pkyzivat <at> cisco.com]
> >>>>>>>> Sent: Thursday, July 31, 2008 12:36 PM
> >>>>>>>> To: Brian Rosen
> >>>>>>>> Cc: 'sipping'
> >>>>>>>> Subject: Re: [Sipping] Comments on
> >>>>>>>> draft-niemi-sipping-event-throttle-
> >>>>>> 06
> >>>>>>>>
> >>>>>>>> Brian Rosen wrote:
> >>>>>>>>> This really is pretty easy. You are tracking an
> >> object. You want
> >>>>>>>>> to
> >>>>>>>> filter
> >>>>>>>>> the notifications. If the target is moving rapidly (large
> >>>>>>>>> changes),
> >>>>>> you
> >>>>>>>> can
> >>>>>>>>> tolerate 10 updates a minute. If the target is moving slowly,
> >>>>>>>>> you
> >>>>>> don't
> >>>>>>>>> want to be bothered (because it isn't changing much), but, at
> >>>>>>>>> least
> >>>>>> once
> >>>>>>>> in
> >>>>>>>>> a while, you want to update the location.
> >>>>>>>>>
> >>>>>>>>> If you set the update rate to be the same, but a very small
> >>>>>>>>> motion
> >>>>>>>> change
> >>>>>>>>> spec, you will nearly always get a high rate of change. That's
> >>>>>>>>> not interesting (it's why you set the change limit high in the
> >>>>>>>>> first
> >>>>>> place).
> >>>>>>>>> However, you also want to get, eventually, the smaller changes.
> >>>>>>>>>
> >>>>>>>>> You can think of this as the way your eyes work: they have a
> >>>>>>>>> filter
> >>>>>> for
> >>>>>>>>> rapid change, and you can follow that motion. When you
> >> are doing
> >>>>>> that,
> >>>>>>>> you
> >>>>>>>>> don't notice small changes. If the object stops moving, you
> >>>>>>>>> engage a different part of the brain, and it's more
> >> sensitive to
> >>>>>>>>> small changes.
> >>>>>>>>> However, if you get a lot of small changes, you
> >> perceive that as
> >>>>>>>>> blur.
> >>>>>>>> What you describe is entirely consistent with having two
> >>>>>> filter/throttle
> >>>>>>>> combinations and switching between them. The switch can be
> >>>>>>>> because you are getting close and need the more detailed
> >>>>>>>> information, or simply because you are getting no
> >> updates at the
> >>>>>>>> course granularity.
> >>>>>>>>
> >>>>>>>> It doesn't require a minimum rate on the throttle.
> >>>>>>>>
> >>>>>>>> Paul
> >>>>>>>>
> >>>>>>>>> Brian
> >>>>>>>>>
> >>>>>>>>>> -----Original Message-----
> >>>>>>>>>> From: Paul Kyzivat [mailto:pkyzivat <at> cisco.com]
> >>>>>>>>>> Sent: Thursday, July 31, 2008 11:01 AM
> >>>>>>>>>> To: Brian Rosen
> >>>>>>>>>> Cc: Rosen, Brian; 'sipping'
> >>>>>>>>>> Subject: Re: [Sipping] Comments on draft-niemi-sipping-event-
> >>>>>> throttle-
> >>>>>>>> 06
> >>>>>>>>>> Brian Rosen wrote:
> >>>>>>>>>>> Having thought about, and discussed the idea of multiple
> >>>>>>>>>>> filters, it
> >>>>>>>>>> won't
> >>>>>>>>>>> work. We would need multiple subscriptions to get
> >> "update when
> >>>>>> target
> >>>>>>>>>> moves
> >>>>>>>>>>> every 10 meters, no more than 10 per minute, but
> >> tell me where
> >>>>>>>>>>> the
> >>>>>>>>>> target is
> >>>>>>>>>>> if it moves at all at least once a minute"
> >>>>>>>>>>>
> >>>>>>>>>>> You need one subscription with a min move of 10 meters and a
> >>>>>> throttle
> >>>>>>>> of
> >>>>>>>>>> 6
> >>>>>>>>>>> seconds, and another with a min move of 1 cm and a
> >> throttle of
> >>>>>>>>>>> 60
> >>>>>>>>>> seconds.
> >>>>>>>>>>> Not good.
> >>>>>>>>>> There is something wrong with that requirement - I'm
> >> trying to
> >>>>>>>>>> figure out what it is.
> >>>>>>>>>>
> >>>>>>>>>> If you are willing to get notifications every 6
> >> seconds for big
> >>>>>> moves,
> >>>>>>>>>> then why aren't you willing to take notifications every 6
> >>>>>>>>>> seconds for small moves?
> >>>>>>>>>>
> >>>>>>>>>> I gather this must just be a cost/benefit tradeoff:
> >> the benefit
> >>>>>>>>>> of knowing about a big move is worth the cost of frequent
> >>>>>>>>>> notifications, but the benefit of knowing about small
> >> moves is
> >>>>>>>>>> less, and so isn't
> >>>>>>>> worth
> >>>>>>>>>> so high a price. Is that right?
> >>>>>>>>>>
> >>>>>>>>>> Maybe its not that you need two filters and throttles
> >>>>>>>>>> simultaneously
> >>>>>> -
> >>>>>>>>>> rather than you need them in different contexts. When you are
> >>>>>>>>>> dispatching the ambulance, you need the coarse
> >> location. If the
> >>>>>> target
> >>>>>>>>>> is moving rapidly, you may have to chase them, or dispatch a
> >>>>>> different
> >>>>>>>>>> ambulance, etc. But when the workers finally arrive at the
> >>>>>>>>>> coarse location, then you need a fine location to direct them
> >>>>>>>>>> to the target.
> >>>>>>>> So
> >>>>>>>>>> at that point you could switch to a different filter
> >> and throttle.
> >>>>>>>>>> The minimum just doesn't make any sense to me.
> >>>>>>>>>>
> >>>>>>>>>> Thanks,
> >>>>>>>>>> Paul
> >>>>>>>>>>
> >>>>>>>>>>> So, I'm back to needing min, recognizing that it's not a
> >>>>>>>>>>> direct
> >>>>>> answer
> >>>>>>>>>> to
> >>>>>>>>>>> the actual problem, but a perfectly acceptable mechanism that
> >>>>>>>>>> accomplishes
> >>>>>>>>>>> the goal.
> >>>>>>>>>>>
> >>>>>>>>>>> Several of us had a meeting today at IETF where this was
> >>>>>>>>>>> discussed,
> >>>>>>>> and
> >>>>>>>>>> a
> >>>>>>>>>>> change to throttle that does a couple of things for us looks
> >>>>>> possible.
> >>>>>>>>>>> Brian
> >>>>>>>>>>>
> >>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>> From: Rosen, Brian [mailto:Brian.Rosen <at> neustar.biz]
> >>>>>>>>>>>> Sent: Tuesday, July 29, 2008 11:42 AM
> >>>>>>>>>>>> To: Paul Kyzivat; Brian Rosen
> >>>>>>>>>>>> Cc: sipping
> >>>>>>>>>>>> Subject: RE: [Sipping] Comments on
> >> draft-niemi-sipping-event-
> >>>>>>>> throttle-
> >>>>>>>>>> 06
> >>>>>>>>>>>> Ah, I get it.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hmmm. Okay, the requirement is some way to catch
> >> small changes.
> >>>>>>>>>>>> So, maybe we need a series of filters. A min rate is so much
> >>>>>> simpler
> >>>>>>>>>>>> than that :)
> >>>>>>>>>>>>
> >>>>>>>>>>>> Brian
> >>>>>>>>>>>>
> >>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>> From: Paul Kyzivat [mailto:pkyzivat <at> cisco.com]
> >>>>>>>>>>>>> Sent: Tuesday, July 29, 2008 10:04 AM
> >>>>>>>>>>>>> To: Brian Rosen
> >>>>>>>>>>>>> Cc: Rosen, Brian; 'sipping'
> >>>>>>>>>>>>> Subject: Re: [Sipping] Comments on
> >>>>>>>>>>>> draft-niemi-sipping-event-throttle-06
> >>>>>>>>>>>>> Brian Rosen wrote:
> >>>>>>>>>>>>>> No, it's not a keep alive.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> If the target moves by less than 10 meters, it moves, but
> >>>>>>>>>>>>>> we
> >>>>>> don't
> >>>>>>>>>>>> know.
> >>>>>>>>>>>>> We
> >>>>>>>>>>>>>> need to know. The "at least 10 meters, no more than 10
> >>>>>>>> updates/sec"
> >>>>>>>>>>>> is
> >>>>>>>>>>>>> all
> >>>>>>>>>>>>>> a rate limit. If the target moves a little,
> >> slowly, we get
> >>>>>>>>>>>>>> slow
> >>>>>>>>>>>>> updates.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> But if the target doesn't move at all (to the limits of its
> >>>>>> ability
> >>>>>>>> to
> >>>>>>>>>>>>> detect) then you don't need an update??? Its been my
> >>>>>>>>>>>>> impression
> >>>>>> from
> >>>>>>>>>>>>> this discussion that you were requesting unconditional
> >>>>>> notifications
> >>>>>>>>>>>> of
> >>>>>>>>>>>>> location at some minimum frequency.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Its significant for the large population of devices that
> >>>>>>>>>>>>> have a
> >>>>>>>> fixed
> >>>>>>>>>>>>> location.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Paul
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Brian
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>>>> From: sipping-bounces <at> ietf.org
> >>>>>>>>>>>>>>> [mailto:sipping-bounces <at> ietf.org]
> >>>>>>>> On
> >>>>>>>>>>>>> Behalf
> >>>>>>>>>>>>>>> Of Paul Kyzivat
> >>>>>>>>>>>>>>> Sent: Tuesday, July 29, 2008 9:32 AM
> >>>>>>>>>>>>>>> To: Rosen, Brian
> >>>>>>>>>>>>>>> Cc: sipping
> >>>>>>>>>>>>>>> Subject: Re: [Sipping] Comments on
> >>>>>>>>>>>> draft-niemi-sipping-event-throttle-
> >>>>>>>>>>>>> 06
> >>>>>>>>>>>>>>> WHY is it necessary to get a notification of
> >> location even
> >>>>>>>>>>>>>>> if
> >>>>>> the
> >>>>>>>>>>>>>>> location has not changed?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Is this just a keep-alive? If so, why not
> >> address the need
> >>>>>>>>>>>>>>> for a keep-alive instead of imposing a requirement for
> >>>>>>>>>>>>>>> location?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Keep-alives can be handled via session timer.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Paul
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Rosen, Brian wrote:
> >>>>>>>>>>>>>>>> It was suggested in geopriv that -throttle be used to
> >>>>>>>>>>>>>>>> control
> >>>>>> the
> >>>>>>>>>>>> rate
> >>>>>>>>>>>>>>>> at which notifications are sent when a watcher is
> >>>>>>>>>>>>>>>> tracking a
> >>>>>>>>>>>> moving
> >>>>>>>>>>>>>>>> target. This may be a reasonable way to do it,
> >> but I have
> >>>>>>>>>>>>>>>> two observations about the current throttle draft
> >>>>>>>>>>>>>>>> relative to use
> >>>>>>>> with
> >>>>>>>>>>>>>>>> location.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> First, we need a minimum rate (or maximum time) for
> >>>>>>>> notifications.
> >>>>>>>>>>>> In
> >>>>>>>>>>>>>>>> location, we may wish to have a rate limit that is
> >>>>>>>>>>>>>>>> something
> >>>>>> like
> >>>>>>>>>>>>> "send
> >>>>>>>>>>>>>>>> me an update when the target has moved at least 10
> >>>>>>>>>>>>>>>> meters, but
> >>>>>>>>>>>> don't
> >>>>>>>>>>>>>>>> send more than 10 updates per second. Also, if
> >> the target
> >>>>>> hasn't
> >>>>>>>>>>>>> moved
> >>>>>>>>>>>>>>>> more than 10 meters in a second, send me an
> >> update anyway".
> >>>>>> This
> >>>>>>>>>>>>>>>> implies a maximum time as well as a minimum time for the
> >>>>>>>> throttle.
> >>>>>>>>>>>>> I'm
> >>>>>>>>>>>>>>>> not sure if there are other uses for a maximum
> >> time, but
> >>>>>>>>>>>>>>>> we
> >>>>>> would
> >>>>>>>>>>>> need
> >>>>>>>>>>>>>>>> one for location.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Secondly, I observe that there are two ways to control
> >>>>>>>>>>>>>>>> event notification. One way is expressed in the current
> >>>>>>>>>>>>>>>> draft, which
> >>>>>>>> is
> >>>>>>>>>>>> a
> >>>>>>>>>>>>>>>> minimum time in seconds between notifications. Another
> >>>>>>>>>>>>>>>> way to
> >>>>>>>>>>>> express
> >>>>>>>>>>>>>>>> rate is an average over a time period. The former is an
> >>>>>>>>>>>> instantaneous
> >>>>>>>>>>>>>>>> limit, the latter is a longer term average. For this
> >>>>>>>>>>>>>>>> purpose,
> >>>>>> I
> >>>>>>>>>>>> think
> >>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>> simple running average would be good enough, so
> >> we would
> >>>>>>>>>>>>>>>> not
> >>>>>> need
> >>>>>>>>>>>> to
> >>>>>>>>>>>>>>>> keep much history state. I think most applications are
> >>>>>>>>>>>>>>>> better
> >>>>>>>>>>>> served
> >>>>>>>>>>>>> by
> >>>>>>>>>>>>>>>> averaging rather than instantaneous limits.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Brian
> >>>>>>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>>>>>> Sipping mailing list
> >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sipping
> >>>>>>>>>>>>>>>> This list is for NEW development of the application of
> >>>>>>>>>>>>>>>> SIP Use sip-implementors <at> cs.columbia.edu for
> >> questions on
> >>>>>>>>>>>>>>>> current
> >>>>>> sip
> >>>>>>>>>>>>>>>> Use sip <at> ietf.org for new developments of core SIP
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>>>>> Sipping mailing list
> >>>>>>>> https://www.ietf.org/mailman/listinfo/sipping
> >>>>>>>>>>>>>>> This list is for NEW development of the
> >> application of SIP
> >>>>>>>>>>>>>>> Use sip-implementors <at> cs.columbia.edu for questions on
> >>>>>>>>>>>>>>> current
> >>>>>> sip
> >>>>>>>>>>>>>>> Use sip <at> ietf.org for new developments of core SIP
> >>>>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>>>> Sipping mailing list
> >>>>>> https://www.ietf.org/mailman/listinfo/sipping
> >>>>>>>>>>>>>> This list is for NEW development of the
> >> application of SIP
> >>>>>>>>>>>>>> Use sip-implementors <at> cs.columbia.edu for questions on
> >>>>>>>>>>>>>> current sip Use sip <at> ietf.org for new developments of core
> >>>>>>>>>>>>>> SIP
> >>>>>>>>>>>>>>
> >>>>>>>>>>> _______________________________________________
> >>>>>>>>>>> Sipping mailing list
> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sipping
> >>>>>>>>>>> This list is for NEW development of the application
> >> of SIP Use
> >>>>>>>>>>> sip-implementors <at> cs.columbia.edu for questions on
> >> current sip
> >>>>>>>>>>> Use sip <at> ietf.org for new developments of core SIP
> >>>>>>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Sipping mailing list
> >> https://www.ietf.org/mailman/listinfo/sipping
> >>>>>>> This list is for NEW development of the application of SIP Use
> >>>>>>> sip-implementors <at> cs.columbia.edu for questions on
> >> current sip Use
> >>>>>>> sip <at> ietf.org for new developments of core SIP
> >>>>>>>
> >>>>>
> >>>> _______________________________________________
> >>>> Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
> >>>> This list is for NEW development of the application of SIP Use
> >>>> sip-implementors <at> cs.columbia.edu for questions on current sip Use
> >>>> sip <at> ietf.org for new developments of core SIP
> >>>>
> >>>
> >> _______________________________________________
> >> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> >> This list is for NEW development of the application of SIP Use
> >> sip-implementors <at> cs.columbia.edu for questions on current sip
> >> Use sip <at> ietf.org for new developments of core SIP
> >>
> > _______________________________________________
> > Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use sip-implementors <at> cs.columbia.edu for questions on current sip
> > Use sip <at> ietf.org for new developments of core SIP
> >
> _______________________________________________
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors <at> cs.columbia.edu for questions on current sip
> Use sip <at> ietf.org for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP