Subject: [Sip] review of draft-ietf-sip-caller-prefs-08.txt

From: "Bob Penfield" <[email-masked]>
Date: Fri, 18 Apr 2003 18:30:48 -0400

Here are my comments caller prefs draft. I apologize for their 
tardiness.

The only technical issue is the processing of require and explicit 
tags (see item 12 below). The spec says that the explicit flag is
checked first and then the require flag. It seems to me it should
be the other way around.

The rest of the items are inconsistencies in requirements, some
suggestions for improving the readability/usability of the spec,
and typos.

1) Page 7: Insert "the" or "a" between "describes" and "full" in
the last line of the "Feature Set" definition.

2) The concept of base-tags (and using "+" for other tags) is not
mentioned until section 7.2.1. I think they should be mentioned in 
the overview, or at least the first time the spec talks about what 
feature tags can be used (section 6.1).

3) In section 6.2, it says "Proxy-Require: pref" MAY be included, 
but in the very next sentence it says that it is NOT RECOMMENDED.
This seems to be a conflict as "MAY" is not equivalent to "NOT 
RECOMMENDED". I personally prefer NOT RECOMMENDED. I suggest text 
along the lines of:

    A UAC SHOULD NOT include a Proxy-Require header with a
    value of "pref" unless it is reasonably certain that all
    proxies along the path between the UAC and the proxy
    responsible for the domain of Request-URI support the
    "pref" extension.

4) Section 6.2.2 says "Each feature set MUST follow the 
constraints of section 6.1". However, not all the requirements 
in section 6.1 apply to Feature Set Preferences. I recommend that 
the 3rd and 4th paragraphs on page 12, and the 2nd and 3rd 
paragraph on page 13 be placed in a separate Feature Set 
Constraints section preceding the existing section 6.1, and 
have 6.1 and 6.2.2 refer to the new section. However, the 
requirement in the 2nd paragraph on page 13 for the UA to "list 
all values it supports" does need to be reworded to say that when 
expressing capabilities it must list all values that it supports 
and when expressing preferences it must list all values it 
desires.

5) The last sentence of the 2nd paragraph of section 6.2.2 repeats 
a requirement in 6.1 and can be removed.

6) Suggest including a sample Accept-Contact and/or Reject-Contact 
in section 6.2.2 to help in understanding feature set preferences.

7) Suggest including a reference to sections 8, 8.2 and 10 in 
section 6.2.2 (similar to that in 6.2.1 for Request-Disposition).

8) Should the requirement for using different contact URIs (3rd 
paragraph of section 6.4) be in section 6.1 since it applies to 
expressing capabilities in a registration?

9) The two requirements in the 2nd paragraph of section 7 are 
confusing to me. The first states that a proxy may add a value to 
an existing header field, but the second says that a proxy must 
not modify an existing header field.

10) In section 7.2, it says "SHOULD apply the processing in this 
section" and "MUST do so as described below". When I first read 
it, I interpreted it to mean section 7.2 (which encompasses 7.2.1, 
7.2.2, and 7.2.2.1 too), but clearly section 7.3 and 7.4 also 
apply. You may want to explicitly enumerate the required sections 
or renumber them such that they all fall within 7.2.

11) The last paragraph on page 22 uses the term "contact set" 
rather than "target set". Should it be "target set"?

12) Page 23 & Figure 1: Shouldn't the require tag be checked first 
rather than the explicit flag? On page 15 it says:

    If one of the values contains the "require" parameter,
    it means that the UA must match that value.

In the example in section 7.4.1, u2 is discarded because the first 
predicate has a require tag. However, if you follow the flow 
chart, u2 would get a score of 0. In order to make my test program 
generate the same results as in the example, I had to check the 
require flag first.

13) The tables in section 8 indicates that a proxy may add and/or 
remove Accept_Contact, Reject-Contact, and Request-Disposition 
headers, but the text in section 7 says a proxy MUST NOT remove 
the header values.

14) Section 9 says "new media feature tags MAY be registered with 
IANA". Given the requirements in section 6.1, shouldn't this say 
"New media feature tags MAY be defined and they MUST be registered 
with IANA"?

15) Section 9: For those feature tags whose values are defined in 
an IANA registry, the specific registry should be referenced to 
find the appropriate values for the tag (as suggested by RFC 
2506). Section 9.13 needs to refer to the IANA "SIP Parameters - 
Methods" registry for valid method names. Section 9.14 (SIP 
Extensions) does explicitly mention IANA and section 9.11 (Event 
Package) mentions "event packages that are registered", but does 
not mention IANA.

16) Page 46: Should [/ ""' /] be [/ "'" /] in the BNF for 
"ftag-name"?

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

_______________________________________________
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: Mon, 21 Apr 2003 13:07:57 -0400

> "New media feature tags MAY be defined and they MUST be registered 

Bob,

Section 6.1 points out that feature tags from any of the various trees 
defined in RFC 2506 may be used. Some of those require registration, but 
not all of them.

Perhaps section 9 should be saying that new base-tags may be registered 
with IANA. Or maybe this is adequately covered elsewhere and nothing 
need be said about it here.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 23 Apr 2003 01:58:59 -0400

Bob,

Thanks for the comments. Responses inline.

> the last line of the "Feature Set" definition.

Inserted "a".

> feature tags can be used (section 6.1).

OK. I added a discussion of this in Section 6.1. Here is the paragraph 
(apologies for the embedded latex commands):

A UA MAY use any feature tags that are registered through IANA in the
IETF or global trees \citenorm{rfc2506}; this document registers
several that are appropriate for SIP. The feature tags discussed in
this specification are referred to as base tags. While other tags can
be used, in order to identify them as feature parameters (as opposed
to parameters for another SIP extension) they are encoded with a
leading ``+'' sign in the Contact header field. See Section
\ref{sec:mapping} for details. It is also permissible to use
the URI tree
\citenorm{rfc2506} for expressing vendor-specific feature
tags. Feature tags in any other trees created through IANA MAY also be
used.

>     responsible for the domain of Request-URI support the

I agree that the current wording is inconsistent, but your proposed 
text, as Mary points out in her email, defeats the purpose of 
Proxy-Require.

I think its reasonable to continue to allow PRoxy-Require. The nice 
thing abuot caller preferences is that, should the request fail becuase 
its not supported somewhere along the path, the fallback is really easy 
- just remove the Proxy-Require. So, it can basically serve as a way for 
a UA to determine whether or not its request will be processed.

I can also imagine applications where a user will want to be certain its 
call routing request will be honored, and if not, attempt to do 
something else. As an example, if I want to make sure a call is routed 
to a user's business line at 3am (to leave a message), and NOT to his 
home line, I might want to use Proxy-Require in this case.

So, I suggest this wording:

> If the UAC wants to be sure that servers understand the header fields
> described in this specification, it includes a Proxy-Require header
> field with a value of ``pref''. However, this is NOT RECOMMENDED, as
> it leads to interoperability problems. In any case, caller preferences
> can only be considered preferences - there is no guarantee that the
> requested service is executed. As such, inclusion of a
> Proxy-Require header field does not mean the preferences will be
> executed, just that the caller preferences extension is understood by
> the proxies.

this eliminates the strength ambiguity.

> and when expressing preferences it must list all values it 

Good point.

Moving the constraints text prior to 6.1 will disrupt the flow of the 
section, I think. I prefer to put that text as section 6.6, and include 
a forward reference. Also, I do not believe that the 3rd paragraph on 
page 13 is a shared constraint. It is specific to registrations.

Also, I found four references to the constraints of 6.1. All have been 
changed to reference the new 6.6.

> a requirement in 6.1 and can be removed.

Removed.

> in section 6.2.2 to help in understanding feature set preferences.

I added an Accept-Contact example.

> section 6.2.2 (similar to that in 6.2.1 for Request-Disposition).

Added a reference in the first paragraph to 8.2 and 10.

> expressing capabilities in a registration?

Yes. Moved.

> not modify an existing header field.

It means, its not supposed to muck with things that are already there. 
Is this clearer:

> In addition to processing these headers, a proxy MAY add one if not
> present, or add a value to an existing header field, as if it were a
> UAC. This is useful for a proxy to request processing in downstream
> proxies in the implementation of a feature. However a proxy MUST NOT
> modify or remove an existing header field value. This

> or renumber them such that they all fall within 7.2.

Its a section numbering problem. They should all fall within 7.2. Good 
catch.

> rather than "target set". Should it be "target set"?

Yes. Fixed.

> generate the same results as in the example, I had to check the 

The require flag is used twice. If a contact doesnt match, and there was 
a require tag, the contact is dropped. Then, if it does match, as part 
of the score computation, its looked at again.

> headers, but the text in section 7 says a proxy MUST NOT remove 

Careful here. "r" means read, not remove. From RFC 3261:

The "proxy" column describes the operations a proxy may perform on a
    header field:

       a: A proxy can add or concatenate the header field if not present.

       m: A proxy can modify an existing header field value.

       d: A proxy can delete a header field value.

       r: A proxy must be able to read the header field, and thus this
            header field cannot be encrypted.

So, "ar" means that the proxy needs to be able to read it, and can add a 
value.

> "New media feature tags MAY be defined and they MUST be registered 

As Paul points out, IANA registration is not required for media feature 
tags in the URI tree. I suspect SHOULD is the appropriate term above. 
Interoperability requires a registration, but there are cases, such as 
lab, where its not needed.

> Package) mentions "event packages that are registered", but does 

Wow, good catch. Thats a very subtle point in RFC2506 that I had missed. 
You've clearly been reading closely. Note also that 9.15 should 
reference the IANA schemes registry. This allows me to remove the 
enumerated listing of the current methods, event types, extensions, and 
schemes, which will always be out of date. Nice.

> 16) Page 46: Should [/ ""' /] be [/ "'" /] in the BNF for 

Yes. This appears to be a bug in my latex converter (my new I-Ds since 
Dec 02 have been using xml2rfc, which I highly recommend).

Thanks for your careful review and comments,

Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com