The draft makes support of multipart a SHOULD in RFC 3261. If our
objective is to use multipart as a vehicle for extending SIP (e.g., by
including optional bodies in addition to the mandatory one - a location
object plus SDP for example), this is much better served by a MUST.
Otherwise, a UAC will have to send a request first with multipart, and
if its rejected, retry the request with just the supported parts. Its
effectively the same as the behavior we'd see if the only way to extend
SIP was with Require, and not Supported.
This draft also strikes me as something that is in the essential
corrections category, but its debatable.
For multipart/alternative - I don't understand the requirement to order
them from least to most 'rich'. Is that a general MIME behavior or are
we defining it that way? If we want to prioritize, shouldn't we use an
explicit q-value or something? Using order seems like it will be brittle
(as it has been in SDP where m-lines were never numbered).
The use case described for multipart/alternative - new SDP mechanisms -
seems kind of bogus. We've decided not to pursue that. Do we have a REAL
use case for this?
The reason for not having such a mechanism is that disposition types
are typically supported within a context. Outside that context, a UA
(User Agent) may not support the disposition type.
I think the same can be send for content-types. A UA may support a
content-type of application/sdp, but only for one disposition
('session') and not another ('render'). So, generally I would say that a
UA never really supports a content-type; it supports a set of tuples of
{content-type, content-disposition, method}.
UAs process message bodies and body parts in the following way. On
receiving a SIP message, if a body part is not referenced in any way
(e.g., there are no header fields or other body parts with a
Content-ID URL pointing to it), the UA processes the body part as
indicated by its disposition type and the context in which the body
part was received.
OPEN ISSUE 4: this means that a UA would need to parse all body parts
to find references between them before being able to fully process
them. If we are OK with this, we need to include text here
explaining it.
This behavior seems like a bad idea, and I don't understand why it is
needed. If the CID URL is part of an optional extension, then you make
the body handling optional, and the UA will know to pick up the body
part if it supports the extension, otherwise not.
Thanks,
Jonathan R.
--
Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
Cisco Fellow Parsippany, NJ 07054-2711
Cisco Systems
[EMAIL PROTECTED] FAX: (973) 952-5050
http://www.jdrosen.net PHONE: (973) 952-5000
http://www.cisco.com
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
