Subject: Re: [Sip] Re: Question about caller preferences

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 04 Oct 2002 23:06:57 -0400

inline.

Rohan Mahy wrote:
> 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).

Yes, that is how the matching will work. The above Reject-Contact would 
reject a contact like this:

sip:user@domain;class="personal";mobility="mobile"

Its important to note that Reject-Contact is particularly troublesome as 
currently defined. Thats because the above reject-contact would also 
match this contact:

sip:user@domain;mobility="fixed"

thats because lack of information on an attribute implies that any value 
is supported, including, in this case, a value of "personal" for the 
class attribute.

For this reason, I plan to introduce a different semantic - "reject this 
contact if it DOESNT match this rule". So, to avoid personal UAs:

Require-Contact: *;class="!personal"

so, a contact like this:

sip:user@domain;mobility="fixed"

does match the rule (since class isn't specified, it is assumed to have 
both values - personal and business, and therefore the value of business 
matches the rule of !personal), and therefore stays. But, a contact like 
this:

sip:user@domain;class="personal"

does not match the rule, and therefore, the contact is rejected.

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

The semantics are unchanged. In all cases, the parameters specify a 
predicate that defines a feature set. If an attribute is not explicitly 
specified, the feature set includes all possible values of that attribute.

-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

_______________________________________________
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: Beckmann Mark ICM MP P PS 4 SAL 2 <[email-masked]>
Date: Wed, 9 Oct 2002 14:00:02 +0200

Hi,

I have another question about the caller preferences, especially regarding
the method tag of the contact parameter.

Perhaps, this was discussed before on the list. In the draft, however, I
couldn't find any hint whether it is possible to indicate the "direction",
in which a UA supports a specific method.

For example a UA that indicates support for the methods SUBSCRIBE and NOTIFY
would add a contact parameter as follows:

Contact: <sip:ua.example.com>;methods="SUBSCRIBE,NOTIFY"

Now, does this mean the UA has to accept and be able to send both methods? I
would guess that for some UAs it would make sense to support the ability to
subscribe to an event and receive NOTIFYs, but not to accept SUBSCRIBEs and
send NOTIFYs itself.

Regards,

Mark

Mark Beckmann			Siemens AG

ICM MP P PS 4S2
P.O.Box 100702			phone: +49 (5341) 906 1814
D-38228 Salzgitter   		fax:   +49 (5341) 906 2010

mailto: [email-masked]

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Thursday, September 26, 2002 7:21 PM
> To: Miguel A. Garcia
> Cc: [email-masked]; Keith Drage
> Subject: [Sip] Re: Question about caller preferences
> 
> 
> 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.
> 
>  >
>  > 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?
> 
> Yes. I have already done that in my working draft as a result of the 
> aforementioned thread with Paul K. and Juha.
> 
> -Jonathan R.
> 
> 
> --