Re: [sipcore] Proposal: Call for adoption & WGLC: draft-roach-sipcore-priority-00

13 nov 2012 kl. 03:04 skrev Adam Roach <adam@nostrum.com>:

> [as an individual]
> 
> I would *really* like to keep protocol semantics out of the IANA registry. The referenced RFC (3261 in this case) is supposed to define the semantics for the Priority values.
> 
> In particular, there isn't any clear indication in RFC 3261 that Priority is supposed to be a strictly ordered set. If we want to go down the path of redefining semantics for parts of RFC 3261, then we're looking at a much, much larger effort than I envisioned for this document.
> 
> All I'm intending to do here is set up an IANA registry.
And that answered my previous mail... Should read all mail before starting to answer ;-)

I do support wg adoption of this draft.

/O

> 
> /a
> 
> On 11/12/12 19:02, Dan Wing wrote:
>> Can something be said about the difference between "non-urgent"
>> and "normal"?   I sort of get the feeling that non-urgent is
>> intended to have a lower priority than "normal" (just based on
>> the ordering), but that is not clear.  Just saying "have the
>> priority in the listed order" would help.
>> 
>> -d
>> 
>>> -----Original Message-----
>>> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On
>>> Behalf Of Paul Kyzivat
>>> Sent: Monday, November 12, 2012 12:49 PM
>>> To: SIPCORE; sipcore-ads@tools.ietf.org
>>> Subject: [sipcore] Proposal: Call for adoption & WGLC: draft-roach-
>>> sipcore-priority-00
>>> 
>>> PLEASE RESPOND TO THIS MESSAGE
>>> 
>>> This is a request to the sipcore wg to adopt the new individual draft
>>> draft-roach-sipcore-priority-00, and a start of WGLC on that document,
>>> to end on Sunday, November 25, 2012. (This is a trivial doc to review,
>>> but people may be slow getting back to work after the meeting and there
>>> is a holiday coming in the US, so I'm giving more time than I otherwise
>>> would.)
>>> 
>>> The reason for this is that the ecrit wg wants to define a new value for
>>> the Priority header field. RFC 3261 defines that header field and an
>>> initial set of values. It also mentions the possibility of extension.
>>> But it failed to establish an IANA registry for that purpose, and didn't
>>> otherwise define a process for extension.
>>> 
>>> The intro to *this* document explains its purpose:
>>> 
>>>     This document defines a new IANA registry to keep track of the
>>> values
>>>     defined for the Session Initiation Protocol (SIP) "Priority" header
>>>     field.  This header field was defined in [RFC3261], section 20.26.
>>>     It was clearly specified in a way that allows for the creation of
>>> new
>>>     values beyond those originally specified; however, no registry has
>>>     been established for it.
>>> 
>>> Once that is done, ecrit will be able to make their extension in accord
>>> with the registration procedures that have been defined. The
>>> registration policy is "IETF Review", so discussion of the merits of
>>> that new value can be discussed as part of the review of *that*
>>> document: draft-ietf-ecrit-psap-callback.
>>> 
>>> REQUESTED ACTIONS:
>>> 
>>> - indicate (ASAP) willingness, or not, for the sipcore wg to work on
>>>    this problem, and adopt this draft as the basis for that work.
>>> 
>>> - provide any comments you have on this document before the end of
>>>    the WGLC period (Friday, November 25.)
>>> 
>>> 	Thanks,
>>> 	Paul
>>> _______________________________________________
>>> sipcore mailing list
>>> sipcore@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sipcore
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf.org
>> https://www.ietf.org/mailman/listinfo/sipcore
> 
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore