Francois Audet wrote:
I think we are on to something here. I believe that Paul Kyzivat and Dan
Wing have it
right.
What I'd like to see is something describing the following:
- How to use Multipart/mixed
I think Paul Kyzivat and Dan had some good explanation in this thread
about it.
We should really make proper treatment of multipart/mixed as mandatory
as we can.
This means, being able to understand parse the nested MIME bodies that
you DO support.
At a miminum, an implementation should be able to find in a
Multipart/mixed the SDP
for example. We probably need also to write some recommnedation on
what happens if
there is multiple SDPs in that multipart mixed.
I would like to bring up something that isn't discussed much:
Content-Disposition. I brought it up earlier in this thread for a
slightly different reason.
One *should not* look for a particular body part of interest solely
based on the Content-Type. Both the content type and the content
disposition need to be correct. For instance, a body part with content
type of application/sdp should not be considered an offer or answer
unless the content-disposition is "session". (This is confused because
there are are also defaulting rules for content-disposition.)
*In principle* you could have a multipart/mixed that had to parts, both
with content-type of application/sdp. This could be quite legal if only
one of them had content-disposition of "session" and the other had some
other content-disposition. It would be sufficient for the other to have
"Content-Disposition:foo;handling=optional".
I realize this is obscure, and it isn't likely that anyone will be
including an sdp body part that isn't intended to be an offer or answer.
But we are writing the specs here, and we ought to be complete and
precise about it.
It's not pretty out there. I've seen implementations that don't even
send 415
when receiving multipart/mixed: they just ignore the payload, and
believe
it's an SDP-less INVITE. They then put an offer in the response, which
the
real offerer believes is an answer. Then all hell breaks loose.
Some of them do send 415, but without the supported payload type in an
Accept
header in 415.
- Multipart/alternative
I agree with Dan that using Multipart/alternative in the way that was
described
in draft-jennings-sipping-multipart section 5 is in fact harmful.
Especially now that we
are defining capability negotiation. Section 6 would be OK, but now
that SDPng is gone,
it's irrelevant.
What we really need to say is that multipart/alternative may be used
only when we
are using alternative payload types for the same information. For
example, text/html and
text/xml or whatever. It would be applicable if one day we re-created
another SDPng
for example.
The perfect example for that is MESSAGE with text/plain and text/html,
quite analogous to an email message.
Section 3.1 explains this relatively well, but is restricted to Offers
(for which we have
no use cases anymore). I think it should instead talk about other
examples (e.g.,
text/html, text/xml, or maybe some example with pictures).
I really believe section 5 goes against the spririt of section 3.1
(specifically, of
the quote of RFC 2046). What it really has it two application/sdp (one
of them is
encrypted inside a application/pkcs7mime), but really it's still two
application/sdp
But we should make it clear that it is NOT for negotiating multiple
alternatives of
the same payload type, in particular, not for application/sdp &
application/sdp.
If we decide to go forward, I'd be happy to help too.
I don't have time to take authorship of the document, but I too can
contribute some text.
Paul
-----Original Message-----
From: Dan Wing [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 10, 2007 09:19
To: 'Christer Holmberg (JO/LMF)'; [EMAIL PROTECTED]
Cc: [email protected]
Subject: RE: [Sip] Support for Multipart/MIME
I have become convinced, through my efforts with RTPSEC, that
multipart/alternative is harmful if it contains multiple SDP parts.
Again, I am not in a position to disagree with you ,but is that
harmfulness documented somewhere?
Nope. If we're going to move multipart/* forward in SIP,
though, I'll be happy to write that section.
-d
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
