Subject: [Sip] A change in the presentation of caller preferences

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 28 Jun 2002 01:26:11 -0400

Folks,

The caller preferences specification (which has actually expired :( ):
http://www.jdrosen.net/papers/draft-ietf-sip-callerprefs-05.txt

had been shoved on the back burner for a while as we worked on more 
pressing drafts. Beyond the general lack of priority, another problem 
that arose during WGLC, mostly in private comments, was that the 
specification lacked clarity on what the lists of contact and 
accept-contact parameters meant. Were these sets? Where these boolean 
expressions? The definitions were inconsistent between the contact 
header and the accept-contact header. There were also concerns raised 
about the amount of code in the spec. I felt it was necesary to properly 
get the algorithm right. The final issue, which was nagging me, was that 
this whole thing was REALLY reinventing the wheel. There exists IETF 
work on specifying capabilities and preferences, and then matching them 
together - RFC 2533. We had considered this mechanism in the early days 
of caller preferences, but discarded it as "too complex". I was 
concerned that this would not be a sufficiently good reason for ignoring 
that work. At the same time, I don't want to discard the syntax and 
general operation of caller-prefs, since its been used in many other 
specs so far.

So, I have come up with a change in the *presentation* of the extension. 
  The syntax will stay as is. However, the specification will show how 
to map the syntax into the standard structures of RFC 2533, and then it 
will point to RFC 2533 for the matching algorithms. Now, the matching 
algorithm in 2533 is not-trivial. Turns out, you can simplify it if you 
restrict the scope of the expressiveness of the feature sets. If you 
specify that all feature sets have to specify constraints on each 
feature orthogonally, the algorithm can be much simplified. Indeed, it 
can be simplified to whats currently documented in caller-prefs, since 
the caller prefs spec assumes orthogonal feature constraints.

A benefit of making use of RFC 2533 is that the meaning of the contact 
and accept-contact params becomes well-defined - both represent feature 
sets as defined in 2533. Another benefit is that the caller prefs spec 
becomes a lot shorter. All the code can go, as can the description of 
the matching algorithm.

I will attempt to complete this rework in time for the cutoff on Monday. 
However, I wanted to make the group aware of this proposed change, and 
seek input on it.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (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: Christer Holmberg <[email-masked]>
Date: Fri, 28 Jun 2002 08:48:47 +0300

Hi Jonathan,

I think the link you gave points to version -04 of the draft, OR you have
forgot to change the text at the beginning of the draft :)

"Internet Engineering Task Force                                   SIP WG
Internet Draft                                     Schulzrinne/Rosenberg
draft-ietf-sip-callerprefs-04.txt                Columbia U./dynamicsoft
November 21, 2001
Expires: December 2001"

Regards,

Christer Holmberg
Ericsson Finland