[EMAIL PROTECTED] wrote:
Unfortunately, I don't particularly like this document, as it gives a
lot of discussion of various cases, but doesn't present a clear and
unified description of the semantics of multipart body part handling.
So much so that it would take me a long time to verify that the
various rules in the document covered all cases and were not mutually
contradictory.
In a lot of situations, it seems that the rule is "the designer of the
software should be able to figure out what is meant in each particular
situation". Which inevitably leads to "No, he can't." or rather "He
will think he can, but he'll get it wrong."
But I don't know that we have time to fix that now.
Well...
This was WGLC, and you did get your comment in before the WGLC closed.
If the draft isn't right, its better to fix it now than later.
Like a lot of things, it seems that they only get noticed by a small
number of people until it is almost "too late".
More specifically:
There seems to be no clear statement that "required" and "optional"
mean "required/optional for successful processing of the enclosing
body/body part" -- after all, the enclosing body part may itself be
optional, so "required" and "optional" can only be relative to the
necessity of understanding of the enclosing body part. Or
alternatively, maybe we don't want this degree of complexity. But to
avoid it, we would have to ban nested multiparts, or at least, all but
certain specific usages of nested multiparts.
Well, the handling parameter wasn't invented for sip. So presumably we
should try to stick with its intended definition if we can. Assuming we
knew what that was.
ISTM that if a part has handling=optional, and you choose not to handle
it, then you won't notice the handling parameter of any enclosed parts.
But that is an ISTM, not a normative reference.
There are a lot of mentions of the 415 response in passing. As far as
I can tell, it is expected that the Accept header in a 415 response
will contain all the media types that the UA understands *in any
context whatsoever*, but that doesn't seem to be stated clearly
anywhere. (E.g., it would be reasonable for a designer to think that
the Accept should only list media types understood for the particular
request method.)
IMO this is a huge problem with all Accept-* headers. There is a fairly
good chance that the 415 will only list those supported in a particular
context. Consider for instance a case where a proxy for an AOR routes
SUBSCRIBE requests for presence to one UA, and INVITE requests to a
different UA. Those two UAs will most likely support different content
types.
Even within a single UA there may be routing to different "applications"
and that may result in different indications of what is accepted.
One might argue that this only makes sense within a dialog, but there
are plenty of examples where the dialog is the wrong scope for this. I
don't know a good answer here, but I expect that in practice the 415 may
only reflect "this is what I can support here and now in this context."
In section 5.1 the description is not really correct, as the "This
way..." sentence doesn't follow from the preceding sentence. A better
phrasing is:
Each body part within a 'multipart/alternative' carries an
alternative version of the same information. The body parts SHOULD
be ordered in increasing richness of representation of the
information. More exactly, the UAS MUST process the last body part
that it understands, and the UAC MUST order the body parts so
that the this rule causes the UAS to behave as the UAC desires.
In section 6.1, I see:
If the parameter [...] has the value 'required', the UAS returns a
415 (Unsupported Media Type) response.
This is incorrect. Of course, what is meant is, "If the parameter has
the value 'required', and the body part must be processed in order to
process the entire SIP message, then the UAS returns...", but that's
not what it says.
This is just the tip of an iceberg. The iceberg is the meaning of "handle".
IMO, "handle" has to mean "process in a way compliant according to the
specifications for this C-T and C-D in the current context. (Which
includes the current message type and the processing of any containing
body parts, referencing headers, etc., as well as the role (UAC, UAS,
proxy, ...) of the processor.) In many cases, "ignore" may be a valid
form of processing.
In section 6.2 there is various discussion of the handling parameter
for parts within a multipart/alternative body part. But the
discussion could be made clearer by starting with the statement that
the handling parameter is not significant: "The handling parameters of
the parts of a multipart/alternative part are ignored in processing
(the processing is determined by the type multipart/alternative), and
SHOULD be set to optional." Or should we just omit 'handling' on
parts of a multipart/alternative?
The specification of C-D states that the default for the handling
parameter is "handling=required", so omitting it solves nothing.
The sentence before that one is peculiar: "If the handling of a
'multipart/alternative' body is required, the UA MUST set the
'handling' parameter of the 'multipart/alternative' body to
'required'." This seems tautological -- why is it stated?
Goes back to the meaning of "required". I don't think it is
tautological, but maybe it could be stated better. The goal here would
be define the relationship between "handling=required" in the header to
desired behavior in the recipient of the body part.
In section 7.3, it is stated that "If the SIP message contains a
reference to the body part, the UA processes the body part according
to the reference.", but in the next paragraph, it says "Note that,
following the rules in [RFC3204], if a UA does not understand a body
part whose handling is optional, it ignores it." But these are
contradictory if the part containing the reference is required but the
part that is referenced is marked optional. In effect, the referenced
part becomes required (or rather, required under any circumstances
where the referencing part is required). This can conflict with the
desire that all parts of a multipart/alternative are effectively
optional within that part. What is really intended here?
We discussed this a lot, and I thought we finally got something workable.
As I understand it, processing based on a reference and processing based
on presence are more-or-less independent.
Assume for the moment that the type and disposition are understood. If
there is some implied processing based on the type and disposition, then
it will be done. If there is also a reference to it via CID from one or
more headers (or other body parts), then those may also be performed
based on the rules for those references. If the goal is to include a
body part solely so that it can be referenced from elsewhere, then it
ought to have a C-T/C-D that doesn't result in any unexpected processing.
If a part has handling=required, but is not understood, then references
to it aren't going to work.
This is all pretty hard to explain. Expecially if you include references
from other body parts. After listening to Adam, I suspect that maybe
reference between body parts should be within a multipart/related, which
will get us into the other discussion of C-D with multipart/related. But
I think there are cases where multipart/related isn't appropriate.
Consider the following:
An INVITE that contains both sdp and a body part referenced by a Geoloc
header. Those two parts aren't related to one another, so they go into a
multipart/mixed in the INVITE. The reference is from the headers of the
sip message to one of the body parts within the multipart/mixed.
Something similar could occur in a response to an INVITE as well, though
probably not with geoloc. For instance there could be an Alert-Info
header referencing a body part containing a picture of the callee.
Now suppose a REFER causes an INVITE that has such a response. And the
entire response is returned in sipfrag in a NOTIFY to the referror. So
then you have: A REFER with a body of type sipfrag. The body in turn
contains a body of type multipart/mixed. The multipart/mixed contains an
SDP part and an image part. The sip headers in the sipfrag reference the
image part in the contained multipart/mixed.
Now *probably* the image part in the response to the invite would have
handling=optional. Or it could have had handling=required if the callee
felt strongly about presenting its image. I don't know what should
happen to the INVITE if the image body part wasn't understood. Nor do I
understand what should happen to the NOTIFY if the recipient doesn't
understand the image.
Paul
Dale
_______________________________________________
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
_______________________________________________
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
