Subject: [Sip] Callerprefs: Implicit preferences

From: Ben Campbell <[email-masked]>
Date: 21 Apr 2003 17:38:40 -0500

The treatment of implicit vs. explicit preferences worries me. If I
understand correctly, if an Accept-Contact header field exists, then
implicit preferences are ignored. Further, the header field should
contain entries matching the implicit preferences.

It seems dangerously error prone to have this sort of information appear
in two different places in a request. To use the method as an example, I
can game the system by putting methods values that do not match the
actual method of my request.

My first inclination was to say that things like methods and events
should not show up at _all_ in Accept-Contacts. But I realize there may
be cases where I want to send an INVITE request to a UA that also
accepts SUBSCRIBE, so I would put both INVITE and SUBSCRIBE in a methods
parameter in Accept-Contacts.

I think the correct answer, at least for methods and event tags, is to
have the actual method or event tag treated by proxies as if it were
explicitly added to the Accept-Contacts header even if it were not. I
suspect this is true for _any_ parameter that can conflict with
information elsewhere in the request.

_______________________________________________
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, 22 Apr 2003 10:25:59 -0400

> contain entries matching the implicit preferences.

I don't think this is the intended interpretation. If an a-c exists but 
doesn't contain a feature tag for th implicit feature, then one gets 
added. If a feature tag already exists for that feature, then it gets 
left along.

Of couse that still makes it possible to do something dumb, but you have 
to be pretty overt about it. For instance, you could send an INVITE, but 
accept contacts that support only SUBSCRIBE. In that case I think you 
get what you deserve.

> information elsewhere in the request.

Need to look at the mechanics of forming the proper expression to do 
this. The explanation might be pretty ugly.

	Paul

---

From: Ben Campbell <[email-masked]>
Date: 22 Apr 2003 09:33:24 -0500

>From 7.2.2:

"If, and only if, the proxy did not find any explicit preferences in the
request (because there was no Accept-Contact or Reject-Contact header
field), the proxy extracts implicit preferences."

This wording seems pretty all or nothing.

> accept contacts that support only SUBSCRIBE. In that case I think you 

I can imagine the caller doing this on purpose as an intentional
circumvention of callee policy.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 22 Apr 2003 15:16:53 -0400

> This wording seems pretty all or nothing.

My brain is getting fuzzy on this. I'm pretty sure it used to be the 
other way. I have a vague recollection of discussing this with Jonathan, 
but don't recall why this change was made. We'll have to wait for an 
explanation from him.

> circumvention of callee policy.

Callerprefs  aren't a good way for the callee to impose mandatory 
policies - they are a way for a callee to facilitate a caller guiding a 
choice. If the callee wants to enforce this, then he should use some 
other mechanism, like CPL.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 23 Apr 2003 02:34:05 -0400

inline.

Paul Kyzivat wrote:
> 
> 
> Ben Campbell wrote:
> 
>>
>>> I don't think this is the intended interpretation. If an a-c exists 
>>> but doesn't contain a feature tag for th implicit feature, then one 
>>> gets added. If a feature tag already exists for that feature, then it 
>>> gets left along.
>>
>>
>>
>>> From 7.2.2:
>>
>>

Yes, this did change during the evolution of the draft.

We even had a thread on the sip list on this, as I recall. The problem 
was that the network simply cannot accurately determine the user intent 
when the user includes caller preferences. There are several ways one 
might attempt to include implicit preferences into a request that 
already has explicit preferences. You could add a new term in each 
existing conjunction, or you can add a new predicate entirely. What I 
found was that sometimes one was the right thing, and other times, the 
other. It depended on what the user was trying to accomplish. But, the 
proxy cant know what the user was trying to accomplish.

Since implicit preferences were really meant to cover the case where the 
caller didnt support them, I changed the spec to only have proxies 
compute implicit preferences when there were no explicit ones. I then 
added text recommending that a UAC place explicit prefrences for methods 
and event packages.

So, I feel that the current behavior is the right thing.

> 
>>> Of couse that still makes it possible to do something dumb, but you 
>>> have to be pretty overt about it. For instance, you could send an 
>>> INVITE, but accept contacts that support only SUBSCRIBE. In that case 
>>> I think you get what you deserve.
>>
>>

I don't really see the danger here. It definitely makes sense for the 
Accept-Contact to list methods beyond the one for the request iself, so 
we've already decoupled the two. The spec recommends that you do include 
the method of the request in the listing:

> A UAC can express explicit preferences for the methods and event
>    packages supported by a UA. It is RECOMMENDED that a UA include a
>    term in an Accept-Contact feature set with the "methods" feature tag,
>    whose value includes the method of the request.

This is at SHOULD/RECOMMENDED strength. I think thats right. Nothing 
breaks if you don't include it. You just may get a 405. Maybe that was 
the intent, in which case, your request was properly formulated. So, 
SHOULD is the right strength - do this unless you have a compelling 
reason otherwise.

-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