Hi Jonathan,
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.
I sent an email with the slides I intend to use to present this draft
right before you sent your comments to the list. In those slides I
already propose to make it a MUST. So, we are on the same page.
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'.
It is not our requirement. It is just how MIME works.
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).
I do not think we should be changing how MIME works.
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?
AFAICT, we have decided not to pursue SDPng but we still need a
mechanism in order to be able to, at some point, migrate to new session
description formats. The current consensus, as I understand it, is that
multipart/alternative should not be used to provide alternative SDP
descriptions, but that it could be used to provide alternative session
descriptions written in different formats.
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}.
yes, that is what the draft intends to say. I will clarify it in the text.
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.
we have a separate email thread where we are discussing this. The
current proposal is to avoid having to process the message two times.
Thanks for your comments,
Gonzalo
_______________________________________________
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
