Subject: [Sipping] Content-Related-To

From: Dan Wing <[email-masked]>
Date: Thu, 24 Mar 2005 09:21:50 -0800

Cullen,

While reviewing draft-jennings-sipping-multipart-00, I found the name 
of the new MIME header "Content-Related-To" confusing because of its 
similarity with multipart/related.  If you consider someone may find a 
use for multipart/related with SIP, and also use 
-jennings-sipping-multipart-, we could avoid potential confusion by 
using a different header name.  I suggest that you consider names which 
aren't closely related to another multipart subtype, such as:

   Previous-Content-ID
   Responding-to-Content-ID

In section 3.1, you mention the Content-ID must be unique.  This needs 
to be specified more fully (see the last paragraph of section 5.1.4 of 
RFC2046, which states, in part:

    It is recommended that each part should
    have a different Content-ID value in the case where the information
    content of the two parts is not identical.  And when the information
    content is identical [...] the same Content-ID field value should be
    used, to optimize any caching mechanisms that might be present on the
    recipient's end.

Your section 3.1 needs to state if the Content-ID is supposed to be 
globally unique, or just unique within this SIP dialog.  I noticed your 
example is using a Content-ID that appears it will only be unique 
within this SIP dialog.  (I feel this is sufficient for SIP, but 
RFC2045 (section 7) does require the Content-ID value to be globally 
unique, so we should follow RFC2045's requirement).

In section 3.2, your I-D states:

    If a UA receives multiple SDP offers in an multipart/alternative
    body, it MUST interpret these as it would a normal multipart
    alternative, as defined in RFC 2046 [2], which means it picks the
    last alternative that it can support.  Any S/MIME bodies that cannot
    be decrypted MUST be treated as unsupportable.

I would prefer you delete the last sentence and replace it with a 
recommendation that any unrecognized bodies be treated as unsupported.  
I believe you should cite RFC3840 so the sender can indicate supported 
bodies to the receiver, with appropriate security considerations about 
how the sender should treat such hints about lack of S/MIME support.

The text is a bit unclear if a multipart/alternative Answer should 
contain the same Content-Related-To value for each alternative, or if 
the Content-Related-To should be just at the top of the 
multipart/alternative bodypart.

Section 5 says:

    5.  Multipart Outside of Offer/Answer

    Applications such as presence and 911 location information result in
    information with significant privacy requirements being sent in SIP.
    Particular MIME types may define special meanings when both encrypted
    and unencrypted bodies are received, but, unless otherwise specified,
    the UA SHOULD use the encrypted version if it can decrypt it, and
    ignore the unencrypted version.  There is no requirement that the two
    versions have the same information.

Could you explain how an implementor would determine if a body needs to 
be handled specially -- that is, what causes "unless otherwise 
specified" to be true (I expect it's if the handling-param is 
"required", but please spell this out in the I-D or cite the 
appropriate external reference).

I'm not sure if section 5, as a whole, is talking about multipart/*, or 
is just talking about multipart/alternative.  If it's talking about 
just multipart/alternative, the semantics of multipart/alternative are 
different from the last sentence of section 5 - specifically, 
multipart/alternative's semantics require that each part ("version" in 
your text above) contain the same information, just in higher fidelity 
to the original version.

I believe you need a section which describes the suggested ordering for 
unencrypted SDP, unencrypted SDPng, encrypted SDP, and encrypted SDPng. 
  That same section should also describe how multipart/alternative is 
inappropriate for IPv6 or ICE, and how use of multipart/alternative for 
"negotiating" IPv6 or ICE would fail.  Specifically, that section needs 
to prohibit a UAS (and the UAC which might also receive a 
multipart/alternative answer) from trying all of the various 
alternatives in the hope of getting one of them to succeed, as such 
behavior would add complexity to preconditions as well as Jonathan's 
recent changes to ICE (which send re-Invites).

-d

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 31 Mar 2005 17:50:30 -0500

I've been staring at this for days, thinking it deserved an answer. 
Nobody else has commented, so I will. Comments inline.

	Paul

Dan Wing wrote:
> Cullen,
> 
> While reviewing draft-jennings-sipping-multipart-00, I found the name of 
> the new MIME header "Content-Related-To" confusing because of its 

I take your point about confusion with multipart/related. But if it is 
to be a MIME header I think its name must be of form Content-*, so your 
suggestions don't work. Ignoring the *potential* confusion you point out 
I quite like Content-Related-To, and don't find the confusion so great 
since it isn't being used with multipart/related. But if that is a 
problem, then maybe something like:

	Content-Referenced-Alternative
	Content-Corresponding-To
	Content-In-Response-To

> example is using a Content-ID that appears it will only be unique within 
> this SIP dialog.  (I feel this is sufficient for SIP, but RFC2045 
> (section 7) does require the Content-ID value to be globally unique, so 
> we should follow RFC2045's requirement).
> 
> 

ut is an undecryptable body unrecognized? What should the receiver do if 
it understands S/MIME, but doesn't have the needed credentials to 
decrypt? That isn't the primary use case we had in mind here, but seems 
like it could happen. For instance it might happen when messages are 
forwarded. I might get a secure session if the boss answers the phone, 
but only an insecure one if the secretary answers.

> multipart/alternative bodypart.

I'm a little troubled about a multipart/alternative answer. I don't see 
any use cases when it would be appropriate, and I don't know what it 
implies about how the call then proceeds. Presumably the offerer then 
has to pick the answer it prefers and use that, but there is no way to 
signal which was chosen, unless preconditions are in use.

I'm inclined to not mention this as a valid answer.

> "required", but please spell this out in the I-D or cite the appropriate 
> external reference).
> 
> is just talking about multipart/alternative.  If it's talking about just 
> multipart/alternative, the semantics of multipart/alternative are