Hi Paul,
thanks for your comments. Answers inline:
Paul Kyzivat wrote:
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.
what do you mean by a reason code? Do you mean a Warning code?...
because Reason header fields are not allowed in responses.
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.)
I have added more structure to the draft (i.e., a few new sections) that
I believe make it easier to read. You can fetch a working version from:
http://users.piuha.net/gonzalo/temp/draft-camarillo-sip-body-handling-01.txt
The points above are covered in Sections 4.2, 4.3, and 5. I have added a
few guidelines to authors of future extensions so that folks writing
specs are also aware of all these issues and take them into
consideration when writing new extensions.
- 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.
That's now covered in Section 4.1
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.
That's OPEN ISSUE 3 now. We may indeed need to define a new disposition
type.
- 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.)
I think that is now clear in the new version... but let me know if you
do not think so.
- 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.
That's now covered in Section 4.1
- 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.
That's now covered in Section 3.2
I have numbered the OPEN ISSUES. Now the draft contain 4 of them. I
would like to discuss how to close them.
Thanks,
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
