Christer Holmberg (JO/LMF) wrote:
Hi,
My main concern is not what wording (SHALL, MUST, etc) we use.
The issue is that I think we need text saying what implementations that
DO NOT support alternative and/or nested shall do. If we say that they
shall reject the message I believe that many of the existing
implementations will be compliant with the spec.
And, if we give the possibility to simply reject the message, I believe
it will be easier to get people to change their implementations, if they
currently simply discard alternative and/or nested today.
I agree that simply ignoring a body can cause huge problems.
I believe we have addressed that by clarifying the use of
Content-Disposition and its handling parameter. In the absence of
handling=optional, the request must be rejected. This part must be of
MUST strength. And the default of handling=required in the absence of a
C-D header must also be of MUST strength.
But there is little we can do about existing implementations that don't
do that right. I guess I can see writing up somewhere that even if you
aren't going to make your implementation compliant to this full draft
you should at least do make sure you support Content-Disposition. Would
it be helpful in that regard to make that part a separate draft???
Paul
Regards,
Christer
-----Original Message-----
From: Gonzalo Camarillo [mailto:[EMAIL PROTECTED]
Sent: 29. toukokuuta 2007 16:06
To: Paul Kyzivat
Cc: Christer Holmberg (JO/LMF); [email protected]
Subject: Re: [Sip] MIME: Nested bodies with option-tag?
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
