Gonzalo,
Thank you for doing this. It is a great start. I largely agree with what
you have written.
One specific comment about the draft:
- Open issue in section 3: perhaps a new Reason code, to be used
with a 415 response would be adequate.
I think there are a number of loose ends, some mentioned, some not. In
many cases, while I have an opinion what the right answer might be I
think it needs discussion. Here is what I came up with:
- How to determine what processing a body part should receive
In many cases the processing of a body part is determined by: the
content disposition, the content type, and perhaps the context within
which the message is received. For instance, this is true for type sdp
with disposition session in an INVITE; for type text/plain with
disposition render in a MESSAGE; and for type kpml with disposition ???
in a SUBSCRIBE. In these cases there is no overt *reference* to the body
part.
In other cases the processing is determined by the context of a
reference to the body part via a cid: url that references the Content-ID
of the body part. You mentioned this as well.
The case I am concerned with is when there is ambiguity between these.
For instance 3261 defines Content-Dispositions "alert" and "icon". While
these aren't described very well, it appears that if a body part is
present with disposition "alert" then it should be used for alerting
based on its presence, without any overt reference. But there is also an
Alert-Info header, which *could* contain a cid: url. If there was an
Alert-Info header with a cid: url that referenced a body part, must that
body part be of disposition "alert"?
Its my feeling that the definition of each disposition should specify
how use decisions should be made for body parts having this disposition.
There should be one or more dispositions that state that their use is to
be determined by how they are referenced. And headers that might
reference body parts should define the acceptable dispositions for the
body parts that are referenced.
If a message contains a body part with type and disposition that defines
how it is processed without need of a reference, and there *also* is a
reference to it, then it should be processed both ways. (This however
should happen rarely or never.)
- What Content-Disposition type should multipart bodies have?
When you have a multipart body, it has a disposition, and each of its
contained body parts also has a disposition. I have never seen any
specification of what disposition the multipart itself should have. None
of the examples I have seen have had a Content-Disposition header in the
multipart. According to the sip defaulting rules, a multipart body
without a C-D header has disposition "render", which seems a bit weird.
In the case of multipart/alternative, I think the disposition type of
all the contained body parts should be identical. I think it would also
make sense for the multipart/alternative itself to contain the same
disposition. That would simplify processing, because the whole thing
could be ignored if the disposition has a type that will be ignored.
In the case of multipart/mixed, the disposition types of the contained
body parts will typically vary. The type of the mixed body simply needs
to be something that causes it to be processed. Using the default of
"render" seems weird to me. It would make sense to me to have some
special C-D type for this purpose. Potentially it could be defined as
the default C-D for multipart/mixed in the same way that "session" is
the default for type application/sdp.
- Must the recipient of a message process all multipart bodies and their
contents? Recursively?
Note that a multipart body can contain other multipart body parts, thus
potentially forming a tree of body parts of arbitrary shape and depth.
So, the developer of a UA will want to know: do I have to parse all of that?
I think the answer is: like anything else, you make this decision based
on the disposition type and handling. (If you understand multipart/mixed
(and you should) then you also understand that multipart/X where you
don't know X should be processed the same as multipart/mixed.)
If handling is optional and the disposition type and content type are
known to you, then you must parse it. Each contained body part is then
processed based on its own disposition. If the handling is optional and
the disposition type or content type are not known to you then you can
ignore it.
(This puts a premium on having an agreed to disposition type that is
typically used for multipart/mixed and which everyone that supports
multipart is expected to support.)
- What "handling" value should be used for multipart bodies and the
contained body parts?
If a body part is referenced by a cid: url in a header (or in another
body part I suppose), then the handling of the body part should be required.
Contained, non-multipart body parts that aren't referenced by cid: can
have handling required or optional as appropriate for their use.
A multipart body should have handling of required if any of the parts it
contains are required. Otherwise it may have optional handling.
Multipart/alternative is tricky. Only one alternative is to be used, and
it is assumed that some alternatives may not be understood. So it seems
that all except the first contained body part should have optional
handling. The first may be required or optional depending on whether its
ok to handle none. And the handling of the multipart/alternative
container is as above.
- What about "gratuitous" nesting of multiparts?
It seems that it is technically valid to wrap a body part, such as an
SDP offer, in one or many levels of multipart wrappers. A recipient who
receives such a thing, and processes it according to what Gonzalo has
specified and what I have suggested above, should be able to deal with this.
But its not a good thing.
So I think we ought to at least state that the sender of a request
SHOULD NOT use a multipart wrapper when there is only one part, and
SHOULD NOT nest one multipart/mixed within another unless there is a
*reference* to the nested one. (Instead of nesting, include all the
parts in the outer multipart.) And a sender SHOULD NOT nest one
multipart/alternative within another.
Thanks,
Paul
Gonzalo Camarillo wrote:
Hi,
I have taken a stab at writing a quick draft about both issues (I agree
it makes sense to tackle them in a single document). Until it appears in
the archives, you can fetch it from:
http://users.piuha.net/gonzalo/temp/draft-camarillo-sip-body-handling-00.txt
I have marked a few open issues so that we can continue discussions
around those on the list (this is, of course, just an initial draft).
Cheers,
Gonzalo
Francois Audet wrote:
My preference is one document.
-----Original Message-----
From: Paul Kyzivat [mailto:[EMAIL PROTECTED] Sent: Wednesday, May
16, 2007 05:18
To: Gonzalo Camarillo
Cc: Audet, Francois (SC100:3055); [email protected]; Dan Wing; Christer
Holmberg (JO/LMF)
Subject: Re: [Sip] Support for Multipart/MIME
Hi Gonzalo,
I guess the question is whether we want to write a document
specifically focused on Content-Disposition, or if we want to combine
work on that with work on specifying use of multipart.
They aren't the same thing, but content-disposition becomes more
significant when there are multiple body parts, so there is some
justification for combining the work.
Paul
Gonzalo Camarillo wrote:
Hi,
yes, Paul and I talked about writing a draft to clarify a
few issues
that relate to content dispositions in SIP a while ago. We
were quite
busy at that point and did not have time to write it, but
maybe it is
time to do it now.
Cheers,
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
