Subject: [Sip] New callee-caps draft

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 11 Dec 2003 16:49:17 -0500

Folks,

You may have noticed that I put out a new revision of callee-caps. 
This update is based on comments received during IETF last call. Here 
are the changes:

* added support for the "text" media type

* Added forward references in a few places to the section which 
creates the IANA registry for sip media feature tags, to clarify where 
the tags come from

* added a Security Consideratiosn bullet to each of the media feature 
tags definition. This is just a reference to the Security 
Considerations section of callee-caps, which has been significantly 
enhanced.

* significantly expanded the security consideratiosn section. It now 
talks about considerations for the media feature tags independent of 
their usage, and then discusses specific considerations and mecahnisms 
for usage with REGISTER, OPTION, and remote-target URIs

* clarified that new media feature tags are added based on the 
guidelines in RFC 2506 (previously it said they SHOULD be registered 
with IANA)

* Aligned the rules for creating tags in the SIP tree with the IETF 
tree. Namely, they require "IETF consensus", which means an RFC - 
informational or standards track. Previously it required standards track.

* clarified that, if you register a sip.priority feature tag, it 
doesnt mean that your UA *has* to reject calls of lower priority

* And last and not at all least, there was one non-trivial change. 
Turns out that the draft really confused our two uses of media types. 
One use of media types in SIP is in the bodies of SIP messages. The 
other is codec types used in RTP. So, if I say that I support 
"audio/G728", does that mean you can put a body of that type in a SIP 
message when you send it to me? Or, does it mean that I support this 
codec in RTP? Same goes for the "audio", "video", etc. attributes. The 
draft confounded the two meanings.

So, here is where I concluded:

1. the "type" attribute indicates MIME types that can be received in 
SIP messages. so, if you could receive message/sip, you could include 
that. This is consistent with the way the tag is currently defined (it 
already exists in the media feature tag registry)

2. the media feature tags - audio, video, etc. - indicate the 
streaming media types supported. This means they are sip specific, and 
no longer belong in the ietf tree. They are now registered in the sip 
tree. Indeed, the spec now makes all of its registrations in the sip 
tree. None are in the ietf tree.

3. there is no way to indicate support for a specific media codec 
(video/h263). As a result, I removed the text which said that, if you 
register type="video/h263", you also register video=true. If this 
function is really needed (indicated support for specific codecs), we 
can register a parameter in the sip tree for it at any time.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    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