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

From: "James M. Polk" <[email-masked]>
Date: Mon, 14 Feb 2005 07:28:02 -0600

Piers

sorry I didn't get back to your questions earlier (no excuses) ... answers 
below

At 06:10 PM 1/24/2005 +0000, Piers O'Hanlon wrote:
>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).

thanks, this is now in section 4.1 of version -06 (thanks for catching this 
one, I went right over it when revising this ID)

>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)?

I believe the normal procedure in an OPTIONs Request is to include 
extensions supported in an Accept header, the response should include the 
Supported header including the extensions listed in the Request that the 
Server supports.  An A-R-P header could be included as well in the 
Response, but I believe that should be a matter of local policy to dictate 
the behavior of - instead of the ID including some form of compliance 
statement here.

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

I am assuming 3261 compliance with this, should I specify this anyway?

>In the definition of strict mode

all the modes are gone/deleted/put in a grave....

I hope and pray version -06 is clearer and more acceptable; as I certainly 
changed a lot of the text to accommodate most of the comments

>Thanks,
>
>Piers O'Hanlon
>--------------
>Computer Science
>University College London

cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented

_______________________________________________
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