Subject: [Sip] Notes on draft-camarillo-sip-body-handling-01

From: [email-masked]
Date: Fri, 6 Jul 2007 11:41:22 -0400

Technical:

- Related to Open Issue 3, there is also the question of what the
Content-Disposition of a response body is.  For SDP answers, "session"
makes sense, but the body may contain control information that doesn't
fall under "session" or "render" cleanly.

- Section 4.1:  "If the handling of a 'multipart/alternative' body is
required, the UA MUST set the 'handling' parameter of the
'multipart/alternative' body and to the last body part within the
'multipart/alternative' to 'required'."

Is there a typo here?  The whole point of multipart/alternative is
that one need only understand one component, and tagging the last
component 'required' contradicts this.

It would seem that even if the whole body was "required", any
individual component would be "optional".  (Though of course, the
reader is obliged to understand at least one component.)  Indeed, the
handling of any component of a multipart/alternative is implied by its
membership in the multipart/alternative and need not be stated.

- In regard to error reporting, perhaps we should use the Warning header
and describe the problem in natural language, rather than trying to
provide errors that can be processed automatically.

- In regard to other multipart types:

   This specification recommends support for 'multipart/mixed' and
   'multipart/alternative'.  At present, there are no SIP extensions
   that use different 'multipart' subtypes such as parallel [RFC2046],
   digest [RFC2046], or related [RFC2387].  If such extensions were to
   be defined in the future, their authors would need to make sure
   (e.g., by using an option-tag or by other means) that entities
   receiving those 'multipart' subtypes were able to process them.  As
   stated earlier, UAs treat unknown 'multipart' subtypes as 'multipart/
   mixed'.

Since there is a standard fallback, an extension does not need to
provide an option-tag as long as it is willing to have its multipart
type processed as multipart/mixed.  So it would be more accurate to
say "If such extensions were to be defined in the future, their
authors might need to provide UAs a way (e.g., by using an option-tag)
to make sure that entities receiving those 'multipart' subtypes were
able to process them as such."

Editorial:

- There is a tendency of the terminology to overlook the fact that all
SIP bodies are MIME bodies, and to use "MIME body" as synonymous with
"MIME multipart body".  E.g., in section 1, "Multipart message bodies
are encoded using the MIME (Multipurpose Internet Mail Extensions)
[RFC2045] format." is literally correct but suggests that
non-multipart message bodies somehow aren't encoded using MIME.  In
reality, Content-Type is a MIME header, etc.

Dale

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 06 Jul 2007 14:52:10 -0400

> 'multipart/alternative' to 'required'."

The general recommendation for processing multipart/alternative is to 
process the *last* part that you are capable of understanding. Thus the 
least capable recipient will be processing the first and ignoring the rest.

> membership in the multipart/alternative and need not be stated.

I think clearly the goal is that if handling of the 
multipart/alternative itself is "required", then *one* of the 
alternatives is to be understood and processed, but no particular one is 
required. If handling for the multipart is "optional" then either one of 
the parts may be processed, or none.

The question is: what is the way to express that?

I think I'm with Dale, that the handling parameter on the 
multipart/alternative specifies the intent, that all the contained parts 
should be optional, and the semantics of processing the alternative 
implies that one of the parts will be.

	Paul