Subject: [Sip] Question about caller preferences

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 25 Sep 2002 15:52:09 +0300

Hi:

I had a discussion with some folks about the caller preferences draft, and we have some questions that we weren't able to answer by reading the document.

We understand that by not publishing the support for a feature set, the UA is not providing any information. Therefore, the feature set may or may not be supported at the UA.

But the question is, if the UA decides to provide information about a supported feature set, shall that information be complete?

We are thinking of the methods parameter in the Contact header for registration. In case the methods parameter is included, shall it be complete and list all the methods supported by the UA?

Example:

Contact: <sip:ua.example.com>;methods="INVITE,ACK,BYE,CANCEL,OPTIONS,REGISTER,UPDATE,SUBSCRIBE,NOTIFY,PRACK,MESSAGE"

Some folks think that the complete list is not essential. In my opinion, if a feature is present, it should be complete. In this case, all the methods supported by the UA must be present.

Other folks didn't see the need to publish the support for methods like ACK (implicitly supported if INVITE is supported), or NOTIFY (implicitly supported if SUBSCRIBE is supported).

In my opinion, that assumption is always wrong, because the methods parameter indicates support for SIP methods, not for SIP capabilities.

I would like to hear the opinion of the WG to give us some guidance.

Last, but not least, whatever is the correct thing to do, can you please add a very clear sentence to the caller preferences draft, so that there is no doubt as with respect the interpretation?

Regards,

       Miguel
-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:[email-masked]     Phone:  +358 9 299 3553
mailto:[email-masked]        Mobile: +358 40 5140002

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Thu, 26 Sep 2002 13:21:27 -0400

inline.

Miguel A. Garcia wrote:
 > Hi:
 >
 > I had a discussion with some folks about the caller preferences
 > draft, and we have some questions that we weren't able to answer by
 > reading the document.
 >
 > We understand that by not publishing the support for a feature set,
 > the UA is not providing any information. Therefore, the feature set
 > may or may not be supported at the UA.

Actually, RFC 2533 (which we are using) does say something concrete 
about what it means to say nothing about a feature tag. It means that 
you are supporting all values. This means you need to be careful about 
the semantics of the headers - the existing Reject-Contact semantic of 
"reject this contact if its feature set matches" is bad, because it will 
cause a UA to be rejected even if it has said nothing about a particular 
feature tag!

 >
 > But the question is, if the UA decides to provide information about a
 > supported feature set, shall that information be complete?

Yes.

 >
 > We are thinking of the methods parameter in the Contact header for
 > registration. In case the methods parameter is included, shall it be
 > complete and list all the methods supported by the UA?

Yes.

There was a thread on the list (likely followed by no one) between 
myself, Juha, and Paul K. on this exact issue. Our conclusion was that 
it was reasonable to mandate that a UA include all values it supports 
for a feature tag, when it includes that feature tag.

 >
 > Example:
 >
 > Contact:
 > <sip:ua.example.com>;methods="INVITE,ACK,BYE,CANCEL,OPTIONS,REGISTER,-
 > UPDATE,SUBSCRIBE,NOTIFY,PRACK,MESSAGE"
 >
 > Some folks think that the complete list is not essential. In my
 > opinion, if a feature is present, it should be complete. In this
 > case, all the methods supported by the UA must be present.

That is correct.

 >
 > Other folks didn't see the need to publish the support for methods
 > like ACK (implicitly supported if INVITE is supported), or NOTIFY
 > (implicitly supported if SUBSCRIBE is supported).
 >
 > In my opinion, that assumption is always wrong, because the methods
 > parameter indicates support for SIP methods, not for SIP
 > capabilities.

I would agree. Without listing all methods, you put the burden on the 
server to lean what other methods a UA will support based on the ones it 
listed. That won't always be a trivial exercise.

 > Last, but not least, whatever is the correct thing to do, can you
 > please add a very clear sentence to the caller preferences draft, so
 > that there is no doubt as with respect the interpretation?

Yes. I have already done that in my working draft as a result of the 
aforementioned thread with Paul K. and Juha.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Fri, 27 Sep 2002 02:59:48 +0300

Jonathan Rosenberg wrote:
> feature tag!s

This is a little bit weird. I consider that the feature tags are not closed,
they are or will be expanding, and new feature tags will appear in the 
future. 

Imagine that my UA implements feature tags 1, 2 and 3. A new feature 4 is 
defined, and my proxy or the remote UA supports that feature, by not my UA. 
Then, are you saying that the proxy or the remote UA will think that my 
terminal supports feature 4 because my UA didn't say anything about that?

That is not what I consider support for backward compatibility.

/Miguel

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 27 Sep 2002 16:03:23 -0400

inline.

> they are or will be expanding, and new feature tags will appear in the 

Absolutely.

> terminal supports feature 4 because my UA didn't say anything about that?

No, I'm not saying that.

 From the syntax in the contact header that describes the capabilities 
(the predicate), its clear what the UA is explicitly saying, and what 
its omitting. So, a UA that sees the predicate in a 200 OK to an INVITE, 
for example, will know what is supported and what is omitted, and so 
does a proxy that sees one in a REGISTER.

What I AM saying is that the matching operation used for routing doesn't 
care. If a caller places into an INVITE an Accept-Contact saying that 
feature tag 4 should have a value of foo, a proxy will route this call 
to UA's that explicitly indicate that they support this value, and to 
those that say nothing.

This is reasonable; the complete lack of information about a feature tag 
should not imply its not supported. Interoperability is better if you 
assume that no information means that it may or may not be supported, 
and then let the protocol itself deal with the situation where its not 
(i.e., reject with 405, 415, etc). This is explicitly called out in rfc2533:

> 3.4.2 Recipient capabilities
> 
>    The following expression describes a receiving system that has:
>    (a)  a screen capable of displaying 640*480 pixels and 16 million
>         colours (24 bits per pixel), 800*600 pixels and 64 thousand
>         colours (16 bits per pixel) or 1024*768 pixels and 256 colours
>         (8 bits per pixel), or
>    (b)  a printer capable of rendering 300dpi on A4 paper.
> 
>          (| (& (| (& (pix-x<=640)  (pix-y<=480) (color<=16777216) )
>                   (& (pix-x<=800)  (pix-y<=600) (color<=65535) )
>                   (& (pix-x<=1024) (pix-y<=768) (color<=256) ) )
>                (ua-media=screen) )
>             (& (dpi=300)
>                (ua-media=stationery) (papersize=iso-A4) ) )
> 
>    Note that this expression says nothing about the colour or grey-scale
>    capabilities of the printer.  In the scheme presented here, it is
>    presumed to be unconstrained in this respect (or, more realistically,
>    any such constraints are handled out-of-band by anyone sending to
>    this recipient).

-Jonathan R.

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 30 Sep 2002 10:47:34 -0700

Jonathan,

So are you saying that:

	Reject-Contact: *;class="personal"

should assume a mobility attribute of "any"  (Reject any personal 
contact whether mobile or not), and:

	Accept-Contact: *;class="business"

should also assume a mobility attribute of any (accept any business 
contact regardless of other attributes)?
(if so, i think this is goodness).

What would the status be of unincluded attributes in a REGISTER?  Is 
the semantic "unknown", "none", or "any"?

	Contact: <sip:[email-masked]>;class=business
	Contact: <sip:[email-masked]>;class=personal

thanks,
-rohan

On Friday, September 27, 2002, at 01:03 PM, Jonathan Rosenberg wrote:

>> they are or will be expanding, and new feature tags will appear in 
>> the future.
>
> Absolutely.
>
>> Imagine that my UA implements feature tags 1, 2 and 3. A new feature 
>> 4 is defined, and my proxy or the remote UA supports that feature, by 
>> not my UA. Then, are you saying that the proxy or the remote UA will 
>> think that my terminal supports feature 4 because my UA didn't say 
>> anything about that?
>
> No, I'm not saying that.
>
> its omitting. So, a UA that sees the predicate in a 200 OK to an 
> INVITE, for example, will know what is supported and what is omitted, 
> and so does a proxy that sees one in a REGISTER.
>
> What I AM saying is that the matching operation used for routing 
> doesn't care. If a caller places into an INVITE an Accept-Contact 
> saying that feature tag 4 should have a value of foo, a proxy will 
> route this call to UA's that explicitly indicate that they support 
> this value, and to those that say nothing.
>
> This is reasonable; the complete lack of information about a feature 
> tag should not imply its not supported. Interoperability is better if 
> you assume that no information means that it may or may not be 
> supported, and then let the protocol itself deal with the situation 
> where its not (i.e., reject with 405, 415, etc). This is explicitly 
> called out in rfc2533:
>