Subject: Re: [Sip] Comments on Resource Priority Header

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 17 Feb 2002 17:48:24 -0500

Mike,

thanks for your comments.

[email-masked] wrote:
> 
> I have the following comments on draft-polk-sip-resource-01:
> 
> General: It is suggested that statements regarding the use of the header
> (i.e., definition of a service which uses the header) should be deleted from
> this draft. Some of these procedures may be different for various situations
> or services or depend on network policies, so this document should not state
> MUST or SHOULD NOT provisions for these procedures.

Agreed; see
http://www.cs.columbia.edu/~hgs/sip/drafts/draft-polk-sip-resource-02.txt
for the about-to-be-submitted version.

> 
> Section 3:
> 
> 2nd paragraph: Is it necessary for the priority values to be assigned by
> IANA? After a namespace is registered, would it be sufficient for the "owner"
> of that namespace to assign priority values without IANA registration?

The owner should pick (so I updated the wording), but what's wrong with
having them documented in the IANA registration?

> 
> 3rd paragraph: "As a response header ..." - It is unknown where this function
> would be used in the required procedures. Current requirements are that the
> priority level is specified by the caller and the called party has no option
> to change or reject the level. It is okay to identity that this header may
> optionally be included in the response, but it should not state its actual
> meaning (procedures). The following paragraph is suggested: "The resource
> priority header MAY be included in a response, either with the same or
> different value than the one contained in the request. The meaning of this
> response value depends on the application and details are beyond the scope of
> this document.."

See new, slightly less wordy, wording.

> 
> 4th paragraph: "If the header field is missing ..." should be deleted, since
> this relates to the procedures for use rather than the definition of the
> header itself. In some networks, this could be cause for rejecting the call
> rather than defaulting to a specific value.

Noted, although purists would argue that this is not SIP behavior. In
SIP, you reject calls based on the explicit or implied value, not
because an optional header is missing. Resource-Priority is an optional
header. Suffice it to say that this difference matters.

> 
> 5th paragraph: "The values are adopted from RFC 791 ..." and following 2
> paragraphs should be moved to go with the description of the specific levels
> for the "dsn". It would probably be useful to include all information
> regarding the values for the Defense Switched Network in an Annex, with a
> reference to it in the IANA considerations for the initial registration. (See
> final comment.)

Good idea; so moved :-)

> 
> 8th paragraph "Proxies MAY downgrade ... SHOULD NOT reject requests..." -
> This should be deleted or changed since the procedures to be followed depend
> on the network policies and the service being provided. For example, in the
> equivalent ISDN standards today, the call is released (rejected) in this
> case. The following paragraph is suggested: "Proxies MAY downgrade the
> Resource-Priority of or reject unauthenticated requests. Details are specific
> to each administrative domain and beyond the scope of this document."
> 

Avoided use of 'administrative domain' and simply called it local
policy. Administrative domain is not a SIP concept.

> 4. IANA
> 
> Why is a restriction needed that an existing list not be extended? If the dsn
> wishes to later add a new level below "Routine", it should be allowed to do
> so.

The reasoning is simple: If my implementation believes it understands
namespace 'foo' based on an IANA registration at the time I built the
system, I shouldn't be surprised by some new value in that same name
space. How can the implementation deal with this sensibly? If you say
that any new value has to have priority below the current lowest one,
that would indeed work. Having new values added later that fall
somewhere in the middle is not possible without risking interoperability
surprises. Is that what you had in mind?

> 
> Other: Since one of the uses is "carrying information from one multi-level
> domain in the telephone network, e.g., using the facilities of Q.735.3, to
> another, without the SIP proxies themselves inspecting the header field", it
> would be useful and efficient to preassign a single standard "namespace" of
> something like "PSTN" with values of "0", "1", "2", "3", and "4" to directly

Added, with slightly different wording.

> Mike Pierce

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: [email-masked]
Date: Thu, 21 Feb 2002 13:58:45 EST

>  surprises. Is that what you had in mind?
An implementation would already need to have a procedure to follow if it got 
a priority it did not understand, like defaulting to the lowest it knows. So 
if a new value were defined and an old implemenation received that new value, 
that is what it would do. It just seems too restrictive to say that a 
"domain" or network could never in the future add a new priority value. 
Granted, the proper use of that new value would require upgrading any 
equipment that might use the value in its processing, but then I suspect the 
same will be true for many other improvements/extensions to the protocol in 
the future. Isn't it true that the current situation is that a device must 
ignore any thing it doesn't understand, just like http?

I guess the use of "SHOULD NOT" in the draft in fact indicates that it could 
be done, but it is not recommended, so I suppose this wording is acceptable.

Mike