Hi,
what I am hearing is that there are implementations out there that
support multipart but not nested. Therefore, we need to decide two things:
1) do we want to have a MUST for multipart and a SHOULD for nested? I
would say that we should have the same level (e.g., MUST, if we decided
that MUST is appropriate) for both.
2) do we need a way for implementations that support multipart but not
nested to be quickly updated to, at least, report that fact with an
error response? This may make sense.
Cheers,
Gonzalo
Paul Kyzivat wrote:
More or less repeating what I said before:
I expect we do have to account in some way for implementations that have
already been deployed, in absence of a clarifying document. Exactly how
we deal with that is still TBD.
But as we define what is required to support this in the future, I think
there is *no* benefit to defining two levels of support - full and
partial. Anybody that sets out to provide support for this document
should be expected to do it all - its not that much harder.
Paul
Christer Holmberg (JO/LMF) wrote:
Hi,
I wonder whether we should define an option-tag for the support of
nested bodies.
I don't think there's a lot to be gained from defining such an
option-tag. The sender should already be aware that there is a risk
the recipient can't understand nested bodies, and have arranged for
suitable fallbacks. Conversely, the recipient should (at least) be
able to skip the nested multipart body part in the proper "I don't
understand this body part" way. All an option-tag would do is allow
the sender to not add a fallback.
In that case we need some specific text saying that if the receiver does
not support nested multiparts it MUST do-this-and-do-that.
Because, as I said earlier, I don't think we will achieve what we want
by saying that one MUST be able to parse nested multiparts. It can be
rather tricky to implement (depending on how the parser is implemented,
though), and since there aren't really any use-cases out there yet I am
pretty sure some people will choose not to implement it (and saying that
people are not compliant in that case will not really help from an
interop perspective). So, because of that I think it would be good not
to mandate the support of nested multiparts, but to mandate appropriate
behavior if not supported - just like in any other case when a MIME body
contains an unsupported but required content type.
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
_______________________________________________
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
