Re: [Sip] Comments of Resource Priority header

[Henning Schulzrinne <hgs@cs.columbia.edu>]

Mpierce1@aol.com wrote:

[I split the response into two, to avoid exceeding message size limits...]

> The abstract says "defines a new SIP header field ... called 
> Resource-Priority", but the draft then defines two headers. If the 
> second header is included (see comments below), references should be 
> added in the abstract and throughout the Introduction.
Noted.

> In the statement in the abstract that this header "does not influence 
> the forwarding behavior of IP routers", it needs to be made clear that, 
> while there is no "direct" influence, it is certainly possible for such 
Added 'not directly'. I don't think the abstract is the place for 
lawyer-like disclaimers...

> influence to exist, based on procedures and processes not described in 
> believe the sentence should read: "While it does not directly influence 
> the forwarding behavior of IP routers, procedures for using this header 
> to cause such influence may be defined in other documents."
I added the detail in the Introduction. One reason that I didn't want to 
go there is that I'm sure somebody will now pipe up and say that 
entities seeing the header may not be in the datapath at all, etc.

> 3. The definition of the Resource-Priority header should not allow 
> multiple resource values to be carried. I am unaware of any requirement 
> for this. The use described always needs exactly one value within one 
> namespace. Anything beyond this will bring on questions like "Which 
> priority has priority?"
>
> Note: REQ-13 says that "Some UAs will need to support multiple different 
> priority schemes". It does not say that the indication (header) needs to 
> support a "list of names".
The only reason that I can think of is to support the case where I'm 
operating in a multi-namespace environment and where I want to say 
"please use namespace X if you can, or Y if that suits you". I don't 
know whether this is likely to occur in practice. The priority 
resolution is easy - the entity receiving the header ignores the stuff 
it doesn't know and picks the highest priority among those it does. 
However, I agree that this is probably more complication than warranted. 
The Accept-R-P header can achieve roughly the same thing, with less 
trouble, albeit more round-trips.


> 3. Instead of defining a separate Accept header, it seems that there 
> could be a single Resource-priority Header which is then included in 
> specific messages (responses) to mean "accept". (I'm trying to find an 
> existing example of a header that is used like this.)
We don't pay a registration fee for header names, so there seems no 
benefit in overloading. Indeed, the whole design of SIP headers is to 
have headers have well-defined meanings, without needing a lot of context.




_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip