If we have a significant body of implementations that support un-nested
multipart, but that don't support nested multipart, then maybe such a
tag would be useful. But first we should probably try to understand the
situation and choose the best migration approach.
But I would hesitate to give *new* implementations the option to only
support un-nested. If you are doing a new implementation you should
implement nesting from the beginning.
Paul
Christer Holmberg (JO/LMF) wrote:
Hi,
Gonzalo's draft describes a use-case where nested multipart bodies may
be used.
From the implementation community we know that multipart is not widely
supported - which is the reason the draft was put together in the first
place.
And, when looking at the implementations that actually do support
multipart, I have one seen one or two that actually supports nested bodies.
I wonder whether we should define an option-tag for the support of
nested bodies. Considering the limited support of non-nested multipart,
and the fact that it is still probably going to take a while before we
really needed nested multiparts (read: before we will have an
alternative to SDP), simply saying that entities MUST also support
nested multiparts may not have the real-life effect we wish (read:
people will not implement it no matter what the spec says), and we will
not get rid of the interop problems.
I think it's a big step forward if we manage to get people to implement
support of non-nested multipart bodies...
Comments?
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
_______________________________________________
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
