Subject: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05

From: Christer Holmberg <[email-masked]>
Date: Wed, 12 Sep 2012 14:31:33 +0200

Hi,

I've submitted a new version of the psap-callback draft, due to expiration of the previous version.

There are NO changes compared to the previous version.

Once I get some guidance on where to define the new SIP Priority header field "psap-callback" value, I will either update this draft or submit a separate one in SIPCORE.

Regards,

Christer

---

From: Roger Marshall <[email-masked]>
Date: Fri, 14 Sep 2012 21:37:19 +0000

All:
We need to select a priority-value in order to move the ecrit-psap-callback draft forward.

Putting aside, for the moment, the questions of if/how/where the priority-value token is defined (if a new value is required - e.g., whether RFC or Registry), we should be able to agree on the value itself.

We've seen some suggestions for a priority-value given on the list over the last few weeks with no clear convergence. The value "emergency" is already included in the RFC3261 definition, but some others have voiced a preference to define a new priority-value, using other-priority = token.

Priority           =  "Priority" HCOLON priority-value

priority-value    =  "emergency" / "urgent" / "normal"

                        / "non-urgent" / other-priority

other-priority    =  token

We've seen a few mentioned on the list, now the chairs are calling to close the list of candidate values, and request the work group to vote their choice.

Of the priority-values put out there on the list, we have the following mentioned a few times:
- emergency
- emergency-callback
- psap-callback

Also mentioned once were:
- expedited-emergency
- urgent-emergency
- emergency-override

If I've forgotten one, please let me know.

Send your vote to the ecrit list.  The voting will go through 18:00 (Pacific), next Friday, 9/21/2012.

-roger.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Wednesday, September 12, 2012 5:32 AM
To: [email-masked]
Subject: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05

Hi,

Regards,

Christer

CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Sep 2012 18:05:11 -0400

+1 for "emergency".

On 9/14/12 5:37 PM, Roger Marshall wrote:
> Putting aside, for the moment, the questions of if/how/where the
> priority-value token is defined (if a new value is required - e.g.,
> whether RFC or Registry), we should be able to agree on the value itself.
>
> We’ve seen some suggestions for a priority-value given on the list over
> the last few weeks with no clear convergence. The value “emergency” is
> already included in the RFC3261 definition, but some others have voiced
> a preference to define a new priority-value, using other-priority = token.
>
> We’ve seen a few mentioned on the list, now the chairs are calling to
> close the list of candidate values, and request the work group to vote
> their choice.
>
> If I’ve forgotten one, please let me know.
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf
> Of *Christer Holmberg
> *Sent:* Wednesday, September 12, 2012 5:32 AM
> *To:* [email-masked]
> *Subject:* [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05
>
> Hi,
>
> I’ve submitted a new version of the psap-callback draft, due to
> expiration of the previous version.
>
> Once I get some guidance on where to define the new SIP Priority header
> field “psap-callback” value, I will either update this draft or submit a
> separate one in SIPCORE.
>
> Regards,
>
> Christer
>
> CONFIDENTIALITY NOTICE: The information contained in this message may be
> privileged and/or confidential. If you are not the intended recipient,
> or responsible for delivering this message to the intended recipient,
> any review, forwarding, dissemination, distribution or copying of this
> communication or any attachment(s) is strictly prohibited. If you have
> received this message in error, please notify the sender immediately,
> and delete it and all attachments from your computer and network.
>
>
>
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
>

---

From: John-Luc Bakker <[email-masked]>
Date: Fri, 14 Sep 2012 22:12:34 +0000

+1 for "emergency".
--- 
John-Luc Bakker
Standards Manager
Research In Motion Corporation 
Mobile +1 (908) 463 7321
Office +1 (972) 373-1761
Internal (820) 63761
E-mail [email-masked]

Sent from my BlackBerry Bold (9900)

----- Original Message -----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Friday, September 14, 2012 05:05 PM
To: [email-masked] <[email-masked]>
Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value

+1 for "emergency".

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sat, 15 Sep 2012 00:57:55 +0200

Anything that is not one of the existing values.

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> John-Luc Bakker
> Sent: 14 September 2012 23:13
> To: [email-masked]; [email-masked]
> > We've seen some suggestions for a priority-value given on the list over
> > the last few weeks with no clear convergence. The value "emergency" is
> > We've seen a few mentioned on the list, now the chairs are calling to
> > field "psap-callback" value, I will either update this draft or submit a
> > separate one in SIPCORE.
> >
> > Regards,
> >
> > Christer
> >
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be
> unlawful.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 14 Sep 2012 16:03:23 -0700

"emergency"

---

From: Andrew Allen <[email-masked]>
Date: Sat, 15 Sep 2012 02:36:17 +0000

"emergency"

----- Original Message -----
From: Martin Thomson [mailto:[email-masked]]
Sent: Friday, September 14, 2012 06:03 PM
To: John-Luc Bakker
Cc: [email-masked] <[email-masked]>
Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value

"emergency"

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 15 Sep 2012 14:25:28 +0200

"psap-callback"

...or, as Keith indicated, anything but an existing value.

Regards,

Christer

________________________________
From: Roger Marshall [[email-masked]]
Sent: Saturday, September 15, 2012 12:37 AM
To: [email-masked]
Cc: Christer Holmberg; Marc Linsner
Subject: RE: Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value

All:

We’ve seen some suggestions for a priority-value given on the list over the last few weeks with no clear convergence. The value “emergency” is already included in the RFC3261 definition, but some others have voiced a preference to define a new priority-value, using other-priority = token.

other-priority    =  token

We’ve seen a few mentioned on the list, now the chairs are calling to close the list of candidate values, and request the work group to vote their choice.

-roger.

Hi,

I’ve submitted a new version of the psap-callback draft, due to expiration of the previous version.

Once I get some guidance on where to define the new SIP Priority header field “psap-callback” value, I will either update this draft or submit a separate one in SIPCORE.

Regards,

Christer

---

From: "Rosen, Brian" <[email-masked]>
Date: Sat, 15 Sep 2012 18:11:01 -0400

+1

---

From: Marc Linsner <[email-masked]>
Date: Mon, 17 Sep 2012 08:33:15 -0400

psap-callback

From:  Roger Marshall <[email-masked]>
Date:  Friday, September 14, 2012 5:37 PM
To:  "[email-masked]" <[email-masked]>
Cc:  Christer Holmberg <[email-masked]>, Marc Linsner
<[email-masked]>
Subject:  RE: Draft new version: draft-ietf-ecrit-psap-callback-05 - select
priority-value

> priority-value token is defined (if a new value is required - e.g., whether
> RFC or Registry), we should be able to agree on the value itself.
>  
> We¹ve seen some suggestions for a priority-value given on the list over the
> last few weeks with no clear convergence. The value ³emergency² is already
> included in the RFC3261 definition, but some others have voiced a preference
> to define a new priority-value, using other-priority = token.
>  
> We¹ve seen a few mentioned on the list, now the chairs are calling to close
> the list of candidate values, and request the work group to vote their choice.
>  
> If I¹ve forgotten one, please let me know.
>  
> Christer Holmberg
> I¹ve submitted a new version of the psap-callback draft, due to expiration of
> the previous version.
>  
> Once I get some guidance on where to define the new SIP Priority header field
> ³psap-callback² value, I will either update this draft or submit a separate
> one in SIPCORE.
>  
> Regards,
>  
> Christer
> privileged and/or confidential. If you are not the intended recipient, or
> responsible for delivering this message to the intended recipient, any review,
> forwarding, dissemination, distribution or copying of this communication or
> any attachment(s) is strictly prohibited. If you have received this message in
> error, please notify the sender immediately, and delete it and all attachments
> from your computer and network.

---

From: James Polk <[email-masked]>
Date: Mon, 17 Sep 2012 15:56:23 -0500

psap-callback is the logical choice to avoid confusion and not do any 
harm to other means of the use of "emergency" (that's a decade+ old already)...

At 07:33 AM 9/17/2012, Marc Linsner wrote:
>psap-callback
>
>
>From: Roger Marshall 
><<mailto:[email-masked]>[email-masked]>
>To: "<mailto:[email-masked]>[email-masked]" 
><<mailto:[email-masked]>[email-masked]>
>Cc: Christer Holmberg 
><<mailto:[email-masked]>[email-masked]>, 
>Marc Linsner <<mailto:[email-masked]>[email-masked]>
>We've seen some suggestions for a priority-value given on the list 
>over the last few weeks with no clear convergence. The value 
>"emergency" is already included in the RFC3261 definition, but some 
>others have voiced a preference to define a new priority-value, 
>using other-priority = token.
>
>We've seen a few mentioned on the list, now the chairs are calling 
>to close the list of candidate values, and request the work group to 
>vote their choice.
>
>From: <mailto:[email-masked]>[email-masked] 
>[mailto:[email-masked]] On Behalf Of Christer Holmberg
>To: <mailto:[email-masked]>[email-masked]
>Once I get some guidance on where to define the new SIP Priority 
>header field "psap-callback" value, I will either update this draft 
>or submit a separate one in SIPCORE.
>
>Regards,
>
>Christer
>
>CONFIDENTIALITY NOTICE: The information contained in this message 
>may be privileged and/or confidential. If you are not the intended 
>recipient, or responsible for delivering this message to the 
>intended recipient, any review, forwarding, dissemination, 
>distribution or copying of this communication or any attachment(s) 
>is strictly prohibited. If you have received this message in error, 
>please notify the sender immediately, and delete it and all 
>attachments from your computer and network.
>

---

From: Roger Marshall <[email-masked]>
Date: Tue, 25 Sep 2012 16:10:12 +0000

Based on the responses to my request for a priority-value, the vote totals came in as:

Existing value of "emergency" = 4
New value of "psap-callback" = 7
New value (other than existing) = 1

Since the "new value - other than existing" lines up with psap-callback, we have "psap-callback" favored at a count of 8 to 4.

These results are clear, and are based on what is posted to the current mail list.  Therefore we should be able to move this draft forward.

Thanks.

-roger marshall.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Roger Marshall
Sent: Friday, September 14, 2012 2:37 PM
To: [email-masked]
Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value

All:

other-priority    =  token

-roger.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Wednesday, September 12, 2012 5:32 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05

Hi,

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 26 Sep 2012 11:51:07 +0200

Thanks, Roger!

We intend to submit a new version of the callback draft, with text defining the new value.

But, I guess we should also verify with the ADs/SIPCORE chairs that it is ok to define the new value in ECRIT.

Regards,

Christer

From: [email-masked] [mailto:[email-masked]] On Behalf Of Roger Marshall
Sent: 25. syyskuuta 2012 19:10
To: [email-masked]
Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value

Thanks.

-roger marshall.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Roger Marshall
Sent: Friday, September 14, 2012 2:37 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value

All:

other-priority    =  token

-roger.

Hi,

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Sep 2012 11:20:06 -0400

> is ok to define the new value in ECRIT.

I will defer to the ADs, but it seems to me that it should be sufficient to:

- In this draft, do all the IANA considerations necessary to set up the
   new registry and register all the initial values, including all those
   defined in 3261 and the new one for this draft.

- Advertise this draft (with the above) on the sipcore list.

- Do a WGLC in both ECRIT and SIPCORE.

	Thanks,
	Paul

> Of *Roger Marshall
> *Sent:* 25. syyskuuta 2012 19:10
> *To:* [email-masked]
> *Subject:* Re: [Ecrit] Draft new version:
> draft-ietf-ecrit-psap-callback-05 - select priority-value
>
> Existing value of “emergency” = 4
>
> New value of “psap-callback” = 7
>
> Since the “new value – other than existing” lines up with psap-callback,
> we have “psap-callback” favored at a count of 8 to 4.
>
> These results are clear, and are based on what is posted to the current
> mail list.  Therefore we should be able to move this draft forward.
>
> Thanks.
>
> -roger marshall.
>
> *From:[email-masked] <mailto:[email-masked]>
> [mailto:[email-masked]] <mailto:[mailto:[email-masked]]>
> *On Behalf Of *Roger Marshall
> *Sent:* Friday, September 14, 2012 2:37 PM
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [Ecrit] Draft new version:
> draft-ietf-ecrit-psap-callback-05 - select priority-value
>
> All:
>
> *From:[email-masked] <mailto:[email-masked]>
> [mailto:[email-masked]] *On Behalf Of *Christer Holmberg
> *To:* [email-masked] <mailto:[email-masked]>

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 26 Sep 2012 12:35:48 -0400

Are we updating 3261?

That's an AD/chair (with sipcore chairs I think) call, right?

I'm okay either way -- it's not clear to me it changes 3261 in any way.  I'd want sipcore to review of course, but not clear we need to update 3261.

Brian

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 26 Sep 2012 19:57:45 +0300

We are adding a new value to the Priority header field. I looked at RFC 3261 and at RFC 2076 but there was no guidance on how new values are registered. There isn't even a registry for it.

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 26 Sep 2012 13:30:44 -0400

I think the plan is to add a registry in this document.

I think that doing that (adding the registry) could give rise to some concern that we were updating 3261, but I personally don't think we are.  The revised version of this document, which defines the registry, isn't going to say any value in the header has to be in the registry.  That WOULD be an update to 3261.  The registry is informational, I think.

Brian

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 26 Sep 2012 19:36:10 +0200

The documents that add registries for stuff originally defined in RFC 3261 are RFC 5727, RFC 3968 and RFC 3969.

None of those documents found it necessary to update RFC 3261 in order to do so.

Both RFC 3968 and RFC 3969 found it necessary to update RFC 3427, the predecessor of RFC 5727 (which is now obsolete) in order to do the work they do. However not entirely clear to me why they needed to do that, given that they don't seem to change the registration requirements for anything defined in that document.

So from an IANA registration perspective I don't see the need to update any other RFC.

The other aspect is that we create a registration policy for the registry. RFC 3968 did that but did not need to update RFC 3261 in order to do so.

As to whether there are other aspects of RFC 3261 that need to be extended, and therefore cause an update.

-	Discussion seems to have identified no need to enhance the RFC 3261 ABNF.

-	I note that the inclusion of the header field is currently not allowed in OPTIONS or REFER methods, while it is allowed in every other dialog creating or standalone method - we might want to allow that, in which case we would update RFC 3261 and RFC 3515 respectively.

Regards

Keith

> Hannes Tschofenig
> Sent: 26 September 2012 17:58
> To: Rosen, Brian
> Cc: [email-masked]; [email-masked]; [email-masked]
> We are adding a new value to the Priority header field. I looked at RFC
> 3261 and at RFC 2076 but there was no guidance on how new values are
> registered. There isn't even a registry for it.
> 
> > I'm okay either way -- it's not clear to me it changes 3261 in any way.
> I'd want sipcore to review of course, but not clear we need to update 3261.
> >
> > Brian
> >
> >>> Since the "new value - other than existing" lines up with psap-
> callback,
> >>> we have "psap-callback" favored at a count of 8 to 4.
> >>>
> over
> >>> Of the priority-values put out there on the list, we have the
> following
> >>> mentioned a few times:
> >>>
> >>> - emergency
> >>>
> >>> - emergency-callback
> >>>
> >>> - psap-callback
> >>>
> header

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 26 Sep 2012 20:27:21 +0200

Hi,

I don't think we are updating 3261. The 3261 Priority header field ABNF allows new values (see on of my previous e-mails).

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Rosen, Brian [[email-masked]]
Sent: Wednesday, September 26, 2012 8:30 PM
To: Hannes Tschofenig
Cc: [email-masked]; Rosen,       Brian; [email-masked]; [email-masked]
Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value

Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Sep 2012 15:18:01 -0400

> Both RFC 3968 and RFC 3969 found it necessary to update RFC 3427, the predecessor of RFC 5727 (which is now obsolete) in order to do the work they do. However not entirely clear to me why they need…

I agree with all the above, except that AFAIK 5727 is *not* obsolete.

But I don't understand *why* introducing the IANA registries after the 
fact for things first defined in 3261 was not an update to 3261.
AFAIK the intent was to change normative behavior - that defining a new 
value requires updating the corresponding registry.

The fundamental point of all this is tracability. If I want to find all 
the defined values for the priority header, where do I look? The first 
place I would start is where the Priority header is defined - 3261. Next 
I might look at all documents listed as updating 3261. If 3261 had 
spelled out an IANA registry for priority values then I would look 
there. But it doesn't. If some document that does update 3261 had 
specified an IANA registry then that would tell me where to look. 
Otherwise I think every draft that adds a priority value will need to 
indicate that it updates 3261 to preserve traceability.

But that same argument applies to header field parameters. ISTM that 
3427, and hence 5727, should have been considered updates to 3261. And 
then 3968, which updated 3427, would have transitively updated 3261.

This document could be viewed as analogous to 3968, and so update 5727.

Responding to Brian, I don't understand how the use of the IANA registry 
can be informative. It isn't useful if it isn't normative.

IMO we need AD input on this.

> The other aspect is that we create a registration policy for the registry. RFC 3968 did that but did not need to update RFC 3261 in order to do so.

I agree that the policy needs to be defined. (You can't establish an 
IANA registry without choosing a policy.) I suggest that it be Standards 
Action.

	Thanks,
	Paul

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 26 Sep 2012 15:28:32 -0400

Unless this document has a statement like "Priority values in SIP are hereby limited to those in the registry", then the registry is a useful aid to find out what values have been defined, but does not limit what values can be used beyond what 3261 says.

I think that's fine.

Brian

On Sep 26, 2012, at 3:18 PM, Paul Kyzivat <[email-masked]> wrote:

> But I don't understand *why* introducing the IANA registries after the fact for things first defined in 3261 was not an update to 3261.
> AFAIK the intent was to change normative behavior - that defining a new value requires updating the corresponding registry.
> 
> The fundamental point of all this is tracability. If I want to find all the defined values for the priority header, where do I look? The first place I would start is where the Priority header is defined - 3261. Next I might look at all documents listed as updating 3261. If 3261 had spelled out an IANA registry for priority values then I would look there. But it doesn't. If some document that does update 3261 had specified an IANA registry then that would tell me where to look. Otherwise I think every draft that adds a priority value will need to indicate that it updates 3261 to preserve traceability.
> 
> But that same argument applies to header field parameters. ISTM that 3427, and hence 5727, should have been considered updates to 3261. And then 3968, which updated 3427, would have transitively updated 3261.
> 
> Responding to Brian, I don't understand how the use of the IANA registry can be informative. It isn't useful if it isn't normative.
> 
> I agree that the policy needs to be defined. (You can't establish an IANA registry without choosing a policy.) I suggest that it be Standards Action.
> 
> 	Thanks,
> 	Paul
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Sep 2012 16:20:19 -0400

> Unless this document has a statement like "Priority values in SIP are hereby limited to those in the registry", then the registry is a useful aid to find out what values have been defined, but does…

Doing that is comparable to allowing P- values, but without the "P-". It 
has the potential to make a mess.

We are defining "psap-callback" because people are concerned that 
"emergency" might already be in use for something incompatible. But at 
least we aren't concerned that "psap-callback" might already be in use. 
If values can be used without registration, then you will never know if 
a candidate value is already in use.

So I think there must be a statement like the one you mention above.

	Thanks,
	Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 26 Sep 2012 22:38:29 +0200

> > Both RFC 3968 and RFC 3969 found it necessary to update RFC 3427, the
> predecessor of RFC 5727 (which is now obsolete) in order to do the work
> they do. However not entirely clear to me why they needed to do that,
> given that they don't seem to change the registration requirements for
> anything defined in that document.
> 

That is not what I said. It is the predecessor of RFC 5727 that is obsolete.

> value requires updating the corresponding registry.

I've given you three examples of documents that create IANA registries without updating the specification that defined the codespace in the first place.

Can you point me at an example that did the opposite?

Otherwise I'd argue that custom and practice strongly argues for this not being a reason for updating.

> can be informative. It isn't useful if it isn't normative.

IANA registries are informative. They are there to prevent dual assignment of codepoints by RFCs, and to give pointers to the document that defines the codepoint.

It is the concerned RFC that defines any normative material, and it should do that outside the IANA considerations subclause.

Keith

> Paul Kyzivat
> Sent: 26 September 2012 20:18
> To: [email-masked]; [email-masked]
> > The documents that add registries for stuff originally defined in RFC
> 3261 are RFC 5727, RFC 3968 and RFC 3969.
> >
> > Both RFC 3968 and RFC 3969 found it necessary to update RFC 3427, the
> predecessor of RFC 5727 (which is now obsolete) in order to do the work
> they do. However not entirely clear to me why they needed to do that,
> given that they don't seem to change the registration requirements for
> anything defined in that document.
> 
> > The other aspect is that we create a registration policy for the
> registry. RFC 3968 did that but did not need to update RFC 3261 in order
> to do so.
> 
> > -	I note that the inclusion of the header field is currently not
> allowed in OPTIONS or REFER methods, while it is allowed in every other
> dialog creating or standalone method - we might want to allow that, in
> which case we would update RFC 3261 and RFC 3515 respectively.
> >
> > Regards
> >
> > Keith
> >
> >
> >> Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-
> 05
> >> - select priority-value
> >>
> >>>>> But, I guess we should also verify with the ADs/SIPCORE chairs that
> it
> >>>>> is ok to define the new value in ECRIT.
> >>>>
> to
> >>>>> *Subject:* [Ecrit] Draft new version: draft-ietf-ecrit-psap-
> callback-
> >> 05
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> field "psap-callback" value, I will either update this draft or
> submit
> >> a
> >>>>> separate one in SIPCORE.
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> Christer
> >>>>>
> may
> >> be

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Sep 2012 16:59:48 -0400

> Can you point me at an example that did the opposite?

Yes, I know you did. I'm seeking the rationale for why that was the 
right thing to do.

> Otherwise I'd argue that custom and practice strongly argues for this not being a reason for updating.

I more or less agree. But still it seems wrong to me.
There should be a mechanism to discover what is valid and what is not 
according to a spec without the need to read *everything* published 
subsequent to that spec.

> It is the concerned RFC that defines any normative material, and it should do that outside the IANA considerations subclause.

And the RFC can do that by requiring that the IANA registry be used.
In that case the spec is delegating the authoritative reference for all 
defined values to the registry.

Otherwise, I guess the IANA registry could be optional and informative. 
But then to discover the complete set of valid values would be 
impossible, or would require that specs adding values also each indicate 
that they update the doc that defines the syntax.

ISTM we have been entirely too sloppy about this sort of thing in the 
past. We have gradually been getting better, but precedent doesn't 
always give good practice.

AFAIK, when 3261 was written, the syntax of the Priority header field 
was intended to be exhaustive of all valid values, and <other-priority> 
was there to make provision for future extensions, not to allow 
non-standard use of other values. The straightforward way to add new 
values in that context would be to revise, or update, 3261 and change 
the syntax of <priority-value> to list added values.

*This* draft could add "psap-callback" that way and then IMO there would 
be no controversy.

Doing it by introducing an IANA registry is a more modern way, and more 
convenient for lookups. But only if it can be relied upon to be as 
authoritative.

	Thanks,
	Paul

---

From: Robert Sparks <[email-masked]>
Date: Thu, 27 Sep 2012 12:57:32 -0500

Paul -

I think Keith's analysis around Updates is right. Using an extension 
point isn't enough
by itself to invoke Updates.

Having a registry for values like this is good. Working to make sure the 
registry is complete
is good. Saying that the registry is the normative list isn't. The RFC 
series is where we keep
the normative requirements.

RjS

On 9/26/12 3:59 PM, Paul Kyzivat wrote:
>> I've given you three examples of documents that create IANA 
>> registries without updating the specification that defined the 
>> codespace in the first place.
>>
>> IANA registries are informative. They are there to prevent dual 
>> assignment of codepoints by RFCs, and to give pointers to the 
>> document that defines the codepoint.
>>
>> It is the concerned RFC that defines any normative material, and it 
>> should do that outside the IANA considerations subclause.
>
> In that case the spec is delegating the authoritative reference for 
> all defined values to the registry.
>
> Otherwise, I guess the IANA registry could be optional and 
> informative. But then to discover the complete set of valid values 
> would be impossible, or would require that specs adding values also 
> each indicate that they update the doc that defines the syntax.
>
> was intended to be exhaustive of all valid values, and 
> <other-priority> was there to make provision for future extensions, 
> not to allow non-standard use of other values. The straightforward way 
> to add new values in that context would be to revise, or update, 3261 
> and change the syntax of <priority-value> to list added values.
>
> *This* draft could add "psap-callback" that way and then IMO there 
> would be no controversy.
>
> Doing it by introducing an IANA registry is a more modern way, and 
> more convenient for lookups. But only if it can be relied upon to be 
> as authoritative.
>
>     Thanks,
>     Paul
>

---

From: Robert Sparks <[email-masked]>
Date: Thu, 27 Sep 2012 12:58:23 -0500

> - Do a WGLC in both ECRIT and SIPCORE.
This seems reasonable to me.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 27 Sep 2012 18:29:22 -0400

> the normative requirements.

Then each draft that will be extending something that is managed by an 
IANA registry should also be marked as updating the spec that defined 
the thing being extended. (E.g. this draft should be marked as updating 
3261 where Priority is defined.) That would preserve the traceability 
without reference to the IANA registry. But that isn't being done.

And that will only work when the new values come from an RFC. E.g. for 
Expert Review and FCFS policies there is no other traceable record than 
the one in IANA.

Otherwise I think you are saying that there is *no* authoritative and 
exhaustive list of all legitimate values.

Let me be clear. The way I *think* this should work is:

1) ideally a spec that defines a new header, etc. will establish an IANA 
registry from day one. Then it is entirely clear where to look for an 
authoritative list of all legal values. Subsequent additions to the 
registry do *not* Update the spec.

2) if a spec fails to do (1), and instead just defines values in the 
text of the draft:

2a) a subsequent draft may define an IANA registry to allow additions. 
In this case the draft that establishes the IANA registry should be 
marked as updating the original draft(rfc), and should populate the 
registry with the values that were defined in the original draft. This 
preserves traceability: someone looking at the original can see the 
Updates indication, and from that discover the IANA registry, and so 
know where to look. Subsequent additions to the registry do *not* Update 
either the base spec or the draft that established the registry.

2b) As an alternative to (2a) a draft that wants to define a new value 
could just do so directly without recourse to IANA, using a syntax 
update. E.g.

	foo /= "newvalue"

In this case it must be marked as Updates the base spec. This again 
preserves traceability: when reading the original draft the Updates link 
will lead to discovering the added value.

But it appears that the precedents we have don't do any of this. RFC3968 
imposes a new MUST requirement for IANA registration of header field 
parameters. In this regard it is *effectively* an update to 3261. But it 
does not indicate that it updates 3261. Instead it says it updates 3427. 
RFC3427 also didn't indicate that it updated 3261, and perhaps it didn't 
- it didn't change the IANA registries.

As a result, a naive reader of 3261 would have no obvious way to 
discover that newly defined header field parameters MUST be registered 
with IANA.

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Thu, 27 Sep 2012 22:00:11 -0700

I agree entirely with the substance of Paul's argument.

With one exception in the detail, even a non-naive reader of RFCs will
probably miss all the stuff about "updated by RFCXXX" and whatever and
so forth.  There are many RFCs that are relevant to a problem I work
on, but I only discover them later by accident or when someone else
points out their relevance.  There is just too much to read and so
many titles are useless to the point of being unhelpful (e.g., RFC
6125).

On 27 September 2012 15:29, Paul Kyzivat <[email-masked]> wrote:
> Then each draft that will be extending something that is managed by an IANA
> registry should also be marked as updating the spec that defined the thing
> being extended. (E.g. this draft should be marked as updating 3261 where
> Priority is defined.) That would preserve the traceability without reference
> to the IANA registry. But that isn't being done.
>
> Expert Review and FCFS policies there is no other traceable record than the
> one in IANA.
>
> authoritative list of all legal values. Subsequent additions to the registry
> do *not* Update the spec.
>
> 2) if a spec fails to do (1), and instead just defines values in the text of
> the draft:
>
> 2a) a subsequent draft may define an IANA registry to allow additions. In
> this case the draft that establishes the IANA registry should be marked as
> updating the original draft(rfc), and should populate the registry with the
> values that were defined in the original draft. This preserves traceability:
> someone looking at the original can see the Updates indication, and from
> that discover the IANA registry, and so know where to look. Subsequent
> additions to the registry do *not* Update either the base spec or the draft
> that established the registry.
>
> 2b) As an alternative to (2a) a draft that wants to define a new value could
> just do so directly without recourse to IANA, using a syntax update. E.g.
>
>         foo /= "newvalue"
>
> RFC3427 also didn't indicate that it updated 3261, and perhaps it didn't -
> it didn't change the IANA registries.
>
> As a result, a naive reader of 3261 would have no obvious way to discover
> that newly defined header field parameters MUST be registered with IANA.
>
>         Thanks,
>         Paul
>
>
>> RjS
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Sep 2012 12:01:54 -0400

> I'm okay either way -- it's not clear to me it changes 3261 in any way.  I'd want sipcore to review of course, but not clear we need to update 3261.

Well, I'm not sure either.
My first thought was that 3261 did not institute an IANA registry for 
Priority values, so putting one in effect now would be an update to 3261.

This is analogous to putting in the IANA registry for header field 
parameters and parameter values. This was done by RFC3968. But I see 
that 3968 does not indicate that it updates 3261. (But it does update 
3427, which also does *not* update 3261.)

So I will defer to the ADs on what is the right way to do this.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 30 Sep 2012 12:57:08 +0200

Hi,

No matter whether we'll update 3261 or not, I guess we can go ahead and update the ecrit psap callback draft, by adding the new value.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Paul Kyzivat [[email-masked]]
Sent: Friday, September 28, 2012 7:01 PM
To: Rosen, Brian
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Ecrit] Draft new version: draft-ietf-ecrit-psap-callback-05 - select priority-value

        Thanks,
        Paul