Subject: [Sip] Splitting caller preferences in half

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 25 Apr 2003 17:49:28 -0400

Folks,

Despite the great feedback we've gotten from the group on the caller 
preferences draft lately, there appear to still be some pretty 
fundamental issues that have come up in discussions with some of our 
area directors. In particular, our q-value arithmetic operations have 
serious issues. Since q-values are meant to be ordinal in nature, not 
cardinal, any kind of arithmetic you might perform on them won't work. 
You also can't compare q-values received from disparate sources, which 
is another thing the draft is sort-of doing (it actually punts this to 
domain policy, but there is no policy that will work properly).

The authors of the draft have some ideas on how to fix this. Our current 
thinking is to eliminate the caller q-values (i.e., no q-values in the 
Accept-Contact header field), and use the score as a way to order the 
contacts ONLY for those contacts whose q-value (specified by the callee) 
is identical. Its not clear that this will work well enough for us, or 
whether there are more q-value issues lurking there. As such, it looks 
like there will be significant additional delays as we work these issues 
and discuss them with ADs.

The problem is that there are now several drafts with normative 
dependencies on caller preferences, including the SIMPLE specification. 
As it turns out, nearly all of these only need the registration piece of 
caller preferences, not the call routing and proxy matching pieces. In 
order to avoid dragging all of those specifications down by caller 
preferences, our proposal is to split caller preferences in half. One 
draft will focus only on capabilities. It will define the contact 
parameters, show how to use them in REGISTER (and also in the INVITE/200 
OK contact and OPTIONS), and describe the rfc2533 mapping. This draft is 
uncontroversial and can proceed immmediately. The other draft will allow 
for caller preferences. It will define the Accept-Contact and 
Reject-Contact header fields, and will describe the proxy matching 
algorithm. We will need to continue to think about how to make that work 
in a reasonable fashion.

The chairs and spec co-authors believe this is the best course of 
action. So, please speak up if you have problems with this tactic, since 
we will move in this direction unless we hear otherwise.

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

_______________________________________________
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