Hi Dale,
thanks for all your comments and for putting your time on analyzing
these issues. Let's agree on how to resolve the open issues, which you
list below in your summary:
There is an open discussion point on the precise semantics of
'required' -- in the SIP context, it is probably more convenient to
mean "required for processing of the containing body part", but in
the e-mail gateway context, it is used to mean "required for the
overall message to be processed". (The two are equivalent for
non-nested multiparts.)
yes, the current I-D specifies the latter; what has been called "global"
in the email threads. The idea was to be consistent with email. However,
I agree with the conclusions of the email discussions. That is, using
the "local" approach probably makes more sense in a SIP context.
So, if nobody objects, I suggest we specify the following:
multipart/mixed:
o the handling of a multipart/mixed is 'required' if its processing as a
whole is required.
o the handling parameter of a given component inside the multipart/mixed
is set regardless of the handling parameter of the multipart/mixed.
This rules means that we can have an optional multipart/mixed that has
required parts in it. *If* and only if the processor decides to
process the multipart/mixed, then it needs to process the required
parts.
It can also happen that we have a required multipart/mixed with all
its components being optional. This is not a big deal. The only thing
that could happen is that the processor decides to process the
multipart/mixed and then it decides not to process any of its parts.
This of course relates to Paul's point on what it takes to process a
body part.
multipart/alternative:
o the handling of a multipart/alternative is 'required' if its
processing as a whole is required.
o the handling parameter of a given component inside the
multipart/alternative is irrelevant. We can still recommend that it is
set to optional.
This rules means that now the multipart/alternative can contain
multipart/mixed parts that contain required components. This was not
possible with the rules in the current I-D.
multipart/related:
o the handling of a multipart/related is 'required' if its processing as
a whole is required.
o the handling of the root element within a multipart/related should
probably always be required. However, since we support required
multipart/mixed bodies with only optional components, I suggest we do
not bother specifying anything here.
My elaborate algorithm is, IMHO, a direct expression of the rules in
the I-D, although I've probably added some "it could only mean this"
assumptions which should be made explicit. Whether the algorithm
itself is given in the I-D is a presentation issue.
I tend to agree with others in that I prefer a declarative
specification. My suggestion would be not to include the algorithm in
the draft.
If the algorithm it too complex to implement, we must simplify the
I-D.
I think we should make some statement that multipart/related should
not be used unless it is "protected" by some extension-requirement
that ensures the recipient can process multipart/related.
the draft already states that. In any case, in one of your previous
emails, you suggested to strengthen the text. I suggest we do this:
OLD:
Authors wishing
to make use of 'multipart/related' bodies should keep in mind that
UAs that do not understand 'multipart/related' will treat it as
'multipart/mixed'.
NEW:
Authors wishing
to make use of 'multipart/related' bodies should keep in mind that
UAs that do not understand 'multipart/related' will treat it as
'multipart/mixed'. If such treatment by a recipient is not acceptable
for a particular extension, the authors of such extension would need
to make sure (e.g., by using an option-tag or by other means) that
entities receiving the 'multipart/related' body were able to
correctly process them.
Cheers,
Gonzalo
_______________________________________________
Sip mailing list https://www.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
