Christer Holmberg (JO/LMF) wrote:
Hi,
we should be ready for a transition to a new session
description protocol, which includes experimental networks
using their own stuff, and people seem to agree that
alternative is the way to go. That is why it would be great
if we could mandate its support already now.
The more we wait, the more trouble we could have in the
future to use it.
Yes.
But, at the same time we need to try to be backward compatible, and take
into consideration existing implementations which may support mixed but
not alternative. If those implementations reject alternative I think our
spec should not make them "not compliant".
The MIME spec already says that if you don't understand multipart/X then
you should treat it as if it were multipart/mixed. So at a minimum we
should expect implementations to do that much with alternative.
If we are going to make more accommodation than that based on what is in
the wild then I suggest we should take a survey first to find out what
we really need to cope with. We should be able to get some good data
from SipIT. Maybe we should be trying to come up with a list of specific
questions, or maybe we can have an essay question on the survey to get a
description of exactly what is/isn't supported.
I think we will have a pretty good chance of seeing support in the
future if we can tell implementors what they must do. I did
specifications for multipart support in a stack a few years ago (which
is when I discovered all these open issues), and I had to make up what
was done based on speculation about what would be used. Even hard things
can be straightforward to implement if the requirements are clear.
Paul
The same thing goes for
nested bodies.
The more we can "fit" the spec into what is already out there, the
better.
So, I don't mind to strongly recommend people to implement alternative,
and give examples why it may be useful in the future, but at the same
time I think we should also say that if the receiver does not support
alternative a error response MUST be sent - in order to avoid cases e.g.
described by Francois, where the receiver simply discard the multipart
and continues the call setup.
Regards,
Christer
Christer Holmberg (JO/LMF) wrote:
Hi,
OPEN ISSUE 1: do we need to say something about other types?
Related (rfc2387), parallel, digest, external-body.
I don't know much about these. I quickly scanned 2387 and
see that
it has some special rules re processing
Content-Disposition of the
contained (related) parts. I *think* those are consistent
with what
we are doing.
I have added the following text to Section 5:
"This specification recommends support for 'multipart/mixed' and
'multipart/alternative'. At present, there are no SIP
extensions
that use different 'multipart' subtypes such as parallel
[RFC2046], digest [RFC2046], or related [RFC2387]. If such
extensions were to be defined in the future, their authors would
need to make sure
(e.g., by using an option-tag or by other means) that entities
receiving those 'multipart' subtypes were able to
process them. As
stated earlier, UAs treat unknown 'multipart' subtypes as
'multipart/mixed'."
I think the text is good.
But, I wonder whether we should alternative to the list of
"different
multipart subtypes". At present there are no SIP extensions using
alternative either, so...
Or, at least we could leave support of alternative open for the
moment, until we get more information about how it's supposed to be
used in the first place (regarding identical content type
values etc).
OPEN ISSUE 2: we know that we do not want two SDPs in a
'multipart/
alternative', but is this valid generally with any content type?
Would it be possible to provide two alternative body parts using
the same format and, thus, the same content type but in, say,
different languages?
Its my understanding that the distinction is based on
which can be
understood, relative to Content-Type. It isn't apparent
to me that
making this decision based on other attributes is valid.
For one thing the parts are supposed to be ordered by increasing
richness. If they differed by language this wouldn't be true.
So I think what you have is ok.
I double check with an email expert to make sure we get this right.
Another thing in Section 3: You have used SHOULD in this
section. I
thought we wanted to change this to MUST. Did we?
You refer to the following statement, right?
"In particular, UAs SHOULD support the 'multipart/mixed'
and 'multipart/alternative' MIME types."
If people agree that this should be a MUST, I will be
happy to change
it.
Again, I think we should wait a little regarding alternative.
Regards,
Christer
_______________________________________________
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
