Hi Francois,
thanks for the comments. Answers inline:
[by the way, Gonzalo has one 'l'; it is Camarillo the one with two 'l's
;o) ]
Francois Audet wrote:
This is great Gonzallo. Thanks for doing this.
Here are some comments:
- In section 4, another example that I think you should list for
Multipart/Mixed is RFC 3204 which actually has examples of
INVITEs with Multipart/Mixed (one for SDP, the other for
QSIG/ISUP tunnelling). That spec also illustrates the content-
disposition mechanism (i.e., "optional" for QSIG/ISUP).
I have added another reference to it in Section 3 as an additional
example. You can fetch the new working version of the draft from:
http://users.piuha.net/gonzalo/temp/draft-camarillo-sip-body-handling-01.txt
- I like your text on Multipart/Alternative. I'd like to include the
following snippet of text from draft-jennings-sipping-multipart-02.txt
in there:
It is critical that multipart/alternative offers follow the semantics
of multipart/alternative, notably the following text from RFC2046
[2]:
"THE SEMANTICS OF CONTENT-ID IN MULTIPART/ALTERNATIVE: Each
part of a "multipart/alternative" entity represents the same
data, but the mappings between the two are not necessarily
without information loss. For example, information is lost
when translating ODA to PostScript or plain text. It is
recommended that each part should have a different Content-ID
value in the case where the information content of the two
parts is not identical."
I'd also like to see an example of Multipart/Alternative for the
MESSAGE message (with text/plain and text/html for example).
I have not copy/pasted the text above, but I have included all of it
rephrasing it.
- I believe that the following text in section 4 is not strong enough:
If a UAS does not support multipart bodies and receives one, the UAS
SHOULD return a 415 (Unsupported Media Type) response.
Instead, it should read as follows:
If a UAS does not support multipart bodies and receives one, the UAS
MUST return a 415 (Unsupported Media Type) response, and it MUST
return a list of acceptable formats as specificed in
[RFC3261]/21.4.13.
When it comes to response generation, I always use SHOULD because a
request may cause other error, apart from the ones we are defining here,
and the UAS may need to return a different status code. That's why I do
not use MUST in this case.
In any event, I have added more text stressing the importance of this.
I believe this is in line with RFC 3261/8.2.3. I will point out that
we have found in the field that if a UAS does NOT send a 415 and just
"ignores" the Multipart body altogether, what happens is that the
receiver of the
INVITE interprets the INVITE as having NO initial Offer, and sends an
an
Offer of it's own in the 200/18X. This is interpreted by the sender of
the
INVITE as an Answer, resulting in all hell breaking loose.
Yes, this is really bad. I have added text stressing the importance of
being able to produce error responses (Section 3.3).
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
