Re: [sipcore] Establishing a "Priority" header field registry

["Roy, Radhika R CIV (US)" <[e-mail]>]

Folks:

I have another point to explain:

                        +------------+-----------+
                        | Priority   | Reference |
                        +------------+-----------+
                        | non-urgent | RFC 3261  |
                        | normal     | RFC 3261  |
                        | urgent     | RFC 3261  |
                        | emergency  | RFC 3261  |
                        +------------+-----------+

The definition of each value needs to be provided.

It is not clear how one label will differ with all others. 

Also, come confusions arise with respect when priority labels are applied
related to call, media, and others.

RFCs 4411 and 4412, 5478, 6433, 6061, 5031, and 3689 need to be seen for
some guidance before explaining the labels so that terminologies and
definitions do not overlap or contradict.

BR/Radhika

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of DRAGE, Keith (Keith)
Sent: Tuesday, November 06, 2012 2:33 PM
To: [e-mail]
Subject: Re: [sipcore] Establishing a "Priority" header field registry

I have reviewed the document and saw no issues with the current contents. It
performs a useful function and should be proceeded with.

As the document stands, I still see no reason why the document should update
RFC 3261. It makes no normative changes within the scope of RFC 3261, which
is to define the protocol between two entities.

Part of this discussion may relate to whether one sees the creation and
entry of material into IANA registries as being a normative action or not. I
don't. To me they are just the housekeeping that has to be done.

As regards the template (which other mails have suggested), we possibly do
not need one.

Part of this down to the level of review that is required; in the document
this is set as IETF review. At this level, an RFC has to exist and go
through IETF community review. There will be enough people around in this
process to ensure that all the information that people need to see outside
the IANA table actually exists. Conversely where we are allocating values on
expert review, a template could be essential if only to ensure the expert
doing the review has enough information available to perform the review;
that information may well exceed the information that needs to appear in the
template itself.

Note that I did have a discussion with IANA on both these issues, and it
would be wrong to say an opinion was expressed, Michelle seemed to be in
alignment with these points.

Regards

Keith

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Adam Roach
> Sent: 06 November 2012 15:54
> To: [e-mail]; [e-mail]
> Subject: [sipcore] Establishing a "Priority" header field registry
> 
> [as an individual]
> 
> The document draft-ietf-ecrit-psap-callback has identified a desire to 
> add a new value to the "Priority" header field for SIP. While RFC 3261 
> clearly intended the values in this header field to be extensible, it 
> did not define a registry of such values.
> 
> To address this oversight, I have put together a small draft that 
> defines such a registry and populates it with the values defined by 
> RFC 3261. Because this is a correction to the core SIP specification, 
> it is my belief that it falls within the charter of the SIPCORE working
group.
> 
> The only real open issue, in my opinion, is the IANA registration 
> policy that should apply to new "Priority" header field values. To 
> avoid blocking any work in ECRIT, we need to move this work (or 
> something
> equivalent) forward very quickly. If you have any interest in the 
> topic, please review and comment with some urgency.
> 
> http://www.ietf.org/id/draft-roach-sipcore-priority-00.txt
> 
> 
> [The following request is being made in my WG chair role] As this is a 
> SIPCORE matter, please discuss it on the SIPCORE list rather than the 
> ECRIT list.
> 
> Thanks!
> 
> /a
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
_______________________________________________
sipcore mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sipcore