Subject: [Sip] MIME: Alternative and identical Content-Types

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 28 May 2007 09:05:31 +0200

Hi,

Gonzalo's draft say that, when multipart/alternative is used, different
body parts can not have the same content type.

Below are a couple of use-cases where the same content type is used, and
which may still be feasible for alternative:

1.
 
Let's assume I have two HTML bodies. They both contain the same 
information, but one is "text friendly", while the other contains 
pictures etc. Now, is that alternative or mixed(or parallel)?

2.
 
Let's assume I have the same information, but in different languages - 
ie the Content-Language values are different. Is that alternative or 
Mixed(or parallel)?

Now, we may not have the expertise to determine whether alternative is
allowed or not in these cases. But, if the think there could be cases
where the same content type would be used for alternative, we need to
allow it.

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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 28 May 2007 11:29:03 -0400

Christer,

As best I understand, multipart/alternative assumes that you either do 
or don't "support" a particular alternative, and that the alternatives 
are arranged from least-preferred to most-preferred by the sender. The 
recipient is supposed to use the most-preferred (as defined by the 
sender) that it "supports".

I guess we could allow different attributes, besides content-type to be 
used to decide if a part is "supported", *if* we can come up with a well 
defined meaning for "supported".

I guess this could work for content-language. But I don't know about the 
text-friendly vs image-containing html. Maybe, but it needs better 
definition.

	Paul

---

From: [email-masked]
Date: Mon, 28 May 2007 16:02:11 -0400

From: "Christer Holmberg (JO/LMF)" <[email-masked]>

You have a good point, though the use cases you've presented might be
dubious.  But I'd say that we don't want to *prescribe* that the
alternative parts must be different (based on any particular
attributes) in case some implementation decides to *depend* on that
rule, and we later discover a use case that makes the rule
disadvantageous.

A better statement is that repeated content-types are likely to be due
to an error in design on the sender's part, but they are allowed.

Dale

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Wed, 30 May 2007 09:43:09 +0200

Hi Paul,

>As best I understand, multipart/alternative assumes that you 
>either do or don't "support" a particular alternative, and 
>that the alternatives are arranged from least-preferred to 
>most-preferred by the sender. The recipient is supposed to 
>use the most-preferred (as defined by the
>I guess we could allow different attributes, besides 
>content-type to be used to decide if a part is "supported", 
>*if* we can come up with a well defined meaning for "supported".
>
>I guess this could work for content-language. But I don't 
>know about the text-friendly vs image-containing html. Maybe, 
>but it needs better definition.

Chapter 5.1.4 in RFC2046 says (and I think that describes my use-case):

"Multipart/alternative" may be used, for example, to send a message
   in a fancy text format in such a way that it can easily be displayed
   anywhere:

     From: Nathaniel Borenstein <[email-masked]>
     To: Ned Freed <[email-masked]>
     Date: Mon, 22 Mar 1993 09:41:09 -0800 (PST)
     Subject: Formatted text mail
     MIME-Version: 1.0
     Content-Type: multipart/alternative; boundary=boundary42

     --boundary42
     Content-Type: text/plain; charset=us-ascii

       ... plain text version of message goes here ...

     --boundary42
     Content-Type: text/enriched

       ... RFC 1896 text/enriched version of same message
           goes here ...

     --boundary42
     Content-Type: application/x-whatever

       ... fanciest version of same message goes here ...

     --boundary42--

   In this example, users whose mail systems understood the
   "application/x-whatever" format would see only the fancy version,
   while other users would see only the enriched or plain text version,
   depending on the capabilities of their system."

Regards,

Christer

> > Gonzalo's draft say that, when multipart/alternative is used, 
> > different body parts can not have the same content type.
> > 
> > Below are a couple of use-cases where the same content type 
> is used, 
> > and which may still be feasible for alternative:
> > 
> > 1.
> >  
> > 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
> > 
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip