Subject: [Sip] update to caller preferences

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 05 Jul 2002 14:20:33 -0400

Folks,

I submitted an update to the caller preferences specification. It should 
appear in the archives shortly. Until it does, you can pick up a copy at:

http://www.jdrosen.net/papers/draft-ietf-sip-callerprefs-06.txt

The changes are substantial:

* complete rewrite to be based on rfc2533. It amazes me how much of
the work we did was already done. Fortunately, this results primarily
in a change in presentation, and less of a change in the syntax and
overall behavior from a black box perspective.

* The media contact parameter is now only used to indicate top level
MIME types (audio, video, message), and not full MIME
types. Indicating full MIME types is done through the existing "type"
feature tag, defined in RFC 2913. THis will break interop with people
using the media contact parameter.

* Added new "automata" and "events" caller preferences tags.

* As a consequence of using an ordered token to represent priorities,
we no longer have the ability to handle unknown priorities as equal to
normal (I don't think). In addition, a UA can now register multiple 
priorities,
although this is redundant, since the matching operation is the same
as before - the call will be routed to a UA which has indicated it
supports a priority equal to, or higher than, the priority in the
Priority header of the INVITE.

* The q value has to appear as the last parameter in the
Accept-Contact or Reject-Contact header fields.

* The Accept-COntact and Reject-Contact header field can contain
explicit preferences for methods and events, even though a proxy
computes implicit preferences based on the request (based on the
request method and Event header field value, respectively). Explicit
preferences always override implicitly derived ones.

* Providing preferences for URI are still allowed. However, since they
are done as part of the RFC 2533 matching procedure, the scope is
restricted. Matches are only done on the user part and domain
part. The matching rule is case sensitive match for both. The ability
to match on the user part only, and not the domain, has been removed.

* The specification used to differentiate between the features
expressible in a registration, and those expressable in an
Accept-Contact and Reject-Contact. All of those restrictions are
removed. Both express feature sets, and can contain the same
things. As an example, the spec used to forbid a Contact header in a
REGISTER like:

Contact: sip:1.2.3.4;mobility="!fixed"

since it had a negation. This restriction is removed.

* Eliminated the use of the & construct in the Accept-Contact and
Reject-Contact header fields. This signficantly changes the scope of
feature predicates that can be constructed. An open issue is whether
to bring it back by simply allowing for an actual rfc2533 expression
in the Accept-Contact header.

There are a number of open issues in the spec, all of which are called 
out. Comments are appreciated on them.

Having done the rewrite based on 2533, I am quite happy it was done. Its 
a significant improvement in the specification. The document is much 
shorter - don't let the page count fool you; much of it is IANA 
registrations.

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