Subject: [Sip] draft-ietf-sip-resource-priority-02

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 15 Feb 2004 17:53:19 -0500

I will shortly (finally...) be submitting 
draft-ietf-sip-resource-priority-02

http://www.cs.columbia.edu/sip/draft/resource-priority/draft-ietf-sip-resource-priority-02.html

Changes are noted below, based on my reading of the January 2004 mailing 
list discussions and the reviews by Paul Kyvizat and Ben Campbell last fall.

(1) Corrected BNF. [Paul, Rohan]

(2) Added namespace registration template and converted initial 
registrations to that template. [multiple]

(3) Now there is a single IANA section with subsections. [Rohan]

(4) Current behavior for DSN, Q.735 specified as non-preemptive. DRSN 
left as implementation-defined. Not sure what other behavior one can 
specify for priorities. [Rohan]

(5) Resource priority for SUBSCRIBE could make sense if a UA has a 
finite capacity for subscriptions and notifications (memory or 
bandwidth). Since NOTIFY establishes no state, only the generic 
request-queueing behavior applies. Text added. [Rohan]

(6) Addressed wording comments (Section 3); was no longer in the draft 
anyway. [Rohan]

(7) Complete request method list. [Rohan] Rather than speculating where 
this might be used, marked as 'o'. [Paul]

(8) Changed 'support' to 'implement' and added some explanatory wording. 
[Rohan]

(9) resource-priority option tag defined in Section 3. [Rohan]

(10) RFC XXXX note added, but not really necessary since the new XML 
version contains &rfc.number; [Rohan]

(11) Removed Appendix A ('Addressing the Requirements') [Ken Karlberg]

(12) Typo and wording corrections [Paul, Ben]

(13) Added distinction to Priority header, but left old text intact. [Paul]

(14) For simplicity, restricted Accept-R-P to UAS; multiple R-P values 
have always been possible. [Paul]

(15) Accept-R-P 420 marked as 'o', with explanation [Paul]. (I'm dubious 
on the reasoning since this means that 'm' cannot appear in any 
extension, thus diminishing the value of the table.)

(16) Multiple namespaces handling made more concrete. [Paul]

(17) Added caveat to OPTIONS handling under overload. [Paul]

(18) OPTIONS handling made MUST. [Ben]

(19) Added discussion on what happens if you modify an R-P value in 
transit. [Ben, others]

Changes discussed, but not made:

- Continues to allow one priority value since the presence of any value 
indicates special treatment, regardless of whether there is another 
value. (In other words, default behavior is a request with no 
Resource-Priority header.)

This may be partially due to confusion in versioning; since the last 
IETF, there were no more 'default' values. (Indeed, the word does not 
appear in the document.) [Mike Pierce]

- 417 generalization to any unknown parameter (since this would not 
allow the user to determine why the request failed) [Alex Audu]

- No mechanism to name all elements in namespace, for simplicity and to 
avoid arguments over which list is referred to by all when a namespace 
gets additional values. [Paul]

Given the stretch of the discussion, it is possible I missed a comment 
or discussion thread. If you respond to this message, please keep each 
item in a separate message as it is very difficult to deal with monster 
messages covering 20 different points.

Henning

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Tue, 17 Feb 2004 13:16:42 -0500

Henning,

(Splitting comments by subject.) There are still problems with the ABNF, 
around the usage of "*" to indicate repetition. As it stands, it accepts:

     Resource-Priority: f.1,,,-.-
     Resource-Priority: 9.a f.-

but it doesn't accept:

     Resource-Priority: foo.bar, foo-1.bar-1, foo-1.bar-2

Assuming the intent is to permit more than two values, separation of
values by exactly one comma, and namespaces and priorities that can
include multiple dashes and alphanums, then I think the following is 
what you want:

     Resource-Priority  = "Resource-Priority" HCOLON
                          Resource-value *(COMMA Resource-value)
...
     namespace          = *(alphanum / "-")
     r-priority         = *(alphanum / "-")

ABNF for Accept-Resource-Priority is similarly flawed. It should be:

     Accept-Resource-Priority = "Accept-Resource-Priority" HCOLON
                                [Resource-value *(COMMA Resource-value)]

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 Feb 2004 13:19:46 -0500

Henning,

OPTIONS handling: there is good explanation of options processing in a
UAS, but it is very UAS specific. There isn't any discussion of options
processing in proxies that support this extension. It is possible to get
a proxy to respond to an options request (using Max-Forwards). This
might be used in testing, just a strict mode might.

I think what a proxy should return is pretty much the same as what a UAS 
returns.

	Paul

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 17 Feb 2004 14:40:00 -0600

>I think what a proxy should return is pretty much the same as what a UAS 

I agree with this point

>         Paul

cheers,
James

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 17 Feb 2004 18:12:49 -0500

I agree in general, but the details are a bit tricky. If I address an 
OPTIONS request to [email-masked], should the cisco.com proxy 
respond with its Accept-R-P version or should it let it go through and 
have your end system speak for itself? The two lists may obviously not 
be the same.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 17 Feb 2004 18:16:02 -0500

> - Now that Resource-Priority is optional in all requests, shouldn't
> Accept-Resource-Priority be permitted in 420 responses to all the same
> messages?

Agreed; except for ACK...

> 
> - Shouldn't the R-P be optional in responses to any request where it was
> permitted?

Same quick cut-and-paste error; yes.

> 
> - If A-R-P is mandatory in 417 responses to SUB, NOT, and MSG, shouldn't
> it also be mandatory (rather than optional) in 417 response to INVITE?
> And by logic just above, shouldn't it be mandatory in responses to any
> message where R-P is optional?
> 
> - So I think the table probably ought to look like:
> 
>     Header field             where proxy INV ACK CAN BYE REG OPT PRA
>     ----------------------------------------------------------------
>     Resource-Priority        R     amd    o   o   o   o   o   o   o
>     Resource-Priority        200   -      o   o   o   o   o   o   o
>     Accept-Resource-Priority 200   -      o   o   o   o   o   o   o
>     Accept-Resource-Priority 417   -      m   m   m   m   m   m   m
>     Accept-Resource-Priority 420   -      o   o   o   o   o   o   o
> 
>     Header field             where proxy SUB NOT UPD MSG REF INF PUB
>     ----------------------------------------------------------------
>     Resource-Priority        R     amd    o   o   o   o   o   o   o
>     Resource-Priority        200   -      o   o   o   o   o   o   o
>     Accept-Resource-Priority 200   -      o   o   o   o   o   o   o
>     Accept-Resource-Priority 417   -      m   m   m   m   m   m   m
>     Accept-Resource-Priority 420   -      o   o   o   o   o   o   o

Yup, minus the responses for ACK.

> 
> In section 4.1, why do you single out INVITE, MESSAGE, UPDATE, SUBSCRIBE
> and NOTIFY, but omit ACK and PRACK? If INVITE is important, then ACK and
> PRACK must be important too. This probably isn't an issue in a UAS,
> because it considers those to be part of the INVITE. But it could make a
> difference in a proxy.
> 
>     Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 Feb 2004 18:40:01 -0500

I thought this was clear in the definition of OPTIONS. If Max-Forwards 
is zero when it gets to the proxy, then the proxy is supposed to 
generate its own response to the OPTIONS. Otherwise it is supposed to 
proxy the request on.

	Paul

Henning Schulzrinne wrote:
>> I think what a proxy should return is pretty much the same as what a 
>> UAS returns.
>>
>>     Paul
>>
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 Feb 2004 18:42:11 -0500

> Agreed; except for ACK...

Duh! Sorry about that one.

	Paul

---

From: Alex Audu <[email-masked]>
Date: Wed, 18 Feb 2004 14:50:00 -0600

Subsection 4.1 (General Rules)  gave an example behavior of a SIP 
element supporting this
specification as:

  ... "For example, for SUBSCRIBE, a higher-priority request
   may get preferential treatment if storage or bandwidth for
   notifications are scarce, possibly displacing a lower-priority
   subscription."

Is this suggesting that resources allocated to a lower priority request
can be reclaimed for a higher priority one (say in the case of scarce
storage space)?  If that is the case, how are the clients of the lower
priority request notified of their misfortune?

Regards,
Alex.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 18 Feb 2004 15:57:23 -0500

SUBSCRIBE is never a guarantee or contract of delivery. The notifier can 
decide, for any reason whatsoever, to stop delivering notifications at 
any time. This is just one more, along with "I don't feel like it any 
more". It's unfortunate, but priority always involves stiffing the 
little guy in some way.

(The more likely behavior is that a system that is bandwidth-constrained 
might prioritize notifications resulting from a PUBLISH. It simply sends 
notifications in order of priority until the next PUBLISH arrives; the 
ones low on the totem pole might never get notified.)