Hi Christer,
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.
Cheers,
Gonzalo
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
