Subject: Re: [Sip] Queries/Comments on Resource Priority-04

From: "Piers O'Hanlon" <[email-masked]>
Date: Mon, 24 Jan 2005 18:10:38 +0000

Hi Henning,

I've taken a look at the 05 draft and noticed most of the changes you acknowledged below (for draft-04) don't seem to have made it into this draft.

In addition I noticed that there is a hanging reference from section 3.4 to section to 4.2.2 (which is not present in draft-05).

Also just to clarify - If a UAC wants to use an OPTIONS request to determine if a proxy supports Resource-priority - it would send a "Require: Resource-priority" and might expect a "Supported: Resource-priority" header and Accept-Resource-priority: namespace.value, ... (given sufficient authorisation)?

Wouldn't a 420 response be obliged include a Unsupported header - or is this assumed from RFC3261 compliance?

In the definition of strict mode - it doesn't seem to be quite clear whether you mean that all SIP messages in every dialogue MUST contain the RP header or every message in the domain? Is it assumed that user agents are all authorised in a 'strict' mode environment? (or just don't need to include an authorisation header or trait-based auth as with semi-strict mode)

Also in the 'semi-strict' mode a similar question arises - when it is stated that "it is not required that every SIP message have a Resource-Priority header" - is this per dialogue or per domain?

It's not quite clear whether the strict and semi-strict 'modes' apply to the configuration of a user agent, proxy or a whole domain? And how each entity behaves in each mode. In the previous draft it seemed strict mode was just 'activated' by the presence of the Require header. 

Thanks,

Piers O'Hanlon
--------------
Computer Science 
University College London

> > 
> > General comments: - The fact that it isn't mandatory to mark all
> > responses with RP headers means that one should at least make it a
> > SHOULD(MUST?) to provide "resource prioritization" based on a dialog
> > or session initiated with the RP header (possibly requiring Stateful
> > proxy?). Otherwise it seems that being able to know if a node
> > "supports Resource priority" (using OPTIONS or a Require hdr) may not
> > be of use if you can't be assured the whole dialog/session will be
> > assured of the "resource prioritization"? If it's not specified in
> > this document then I guess it will need to be specified in some
> > external policy document...(out of scope)
> 
> There are two types of resource prioritization, as alluded to in the 
> document (Introduction), namely to prioritize the signaling handling 
> itself and, more importantly, the resources such signaling controls, 
> e.g., trunk circuits.
> 
> Resources such as trunk circuits are inherently stateful, as they are at 
> UAs, and thus don't require the response to carry the R-P indication.
> 
> The only time the response would need to carry the R-P header is for 
> prioritizing the handling of the SIP request itself. Since a response is 
> part of a transaction, transaction-stateful proxies (i.e., most of them) 
> would already know that the transaction has high priority and can handle 
> this without additional indication. Thus, only the rare case of a 
> stateless proxy is relevant. However, since that proxy can't readily 
> ascertain that the response is authorized (ignoring S/MIME for now), 
> this isn't likely to be useful.
> 
> I'll add a sentence that summarizes this.
> 
> 
> > 
> > 
> > Section 3.3 - minor comment: It might be useful to label table
> > something like 'Table 1'. 
> 
> Done.
> 
> - In the second the paragraph the 420
> > response is incorrectly defined as "(Not Supported)" - when it should
> > be "(Bad Extension)". 
> 
> Fixed.
> 
> - In the same paragraph the explanation
> > following the handling of the 420 response seems at odds with the
> > description in section 4.2.2 and that of RFC3261. Firstly this is
> > because it indicates that a 420 is generated when it encounters a
> > unknown RP value (on an RP capable node) -  shouldn't that be covered
> > in section 4.2.2 
> 
> That part of the paragraph below the table is an orphaned remnant of 
> some earlier behavioral description. The error behavior is now described 
> in Section 4.2. I ditched the confusing set of sentences.
> 
> - Shouldn't a 420 be generated only by non RP
> > capable node in response to Require? Secondly it seems to reccomend
> > adding an 'Accept-Resource-Priority' header when RFC3261 specifies
> > adding an "Unsupported" header for a 420 response? Or maybe it was
> > intended to talk about the 417 handling here?
> 
> See above.
> 
> 
> > 
> > Example 7.2 - In this example - according to section 4.2.2 a 417
> > response should only generated when in strict mode, in which case the
> > shouldn't the INVITE contain the Require header?
> 
> Indeed.
> 
> > 
> > 
> > Piers O'Hanlon --------------_____________ Computer Science
> > Department University College London
> 
> _______________________________________________
> 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

_______________________________________________
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