Subject: [Ietf-calsify] iMip and Mixing content

From: camerost at exchange.microsoft.com (Cameron Stillion)
Date: Sat Aug 21 08:42:42 2004

While I appreciate the effort to be clear and exhaustive, I wonder at
the value of including multiple iCalendar objects in a single MIME
message that have different METHOD parameters.  Can anyone think of a
good reason a client might do so?

Clients who receive a message with iCals having PUBLISH methods can
assume the included content comprises a published calendar that is being
sent to the recipient of the message.  They can include whatever client
behaviors are interesting for such entities.

Clients who receive a message with iCals having REQUEST methods can
assume the included content comprises a meeting request, and can include
proper client behaviors in that case.

A client receiving a message with both... Will likely either not support
it, or be confused and pick the first one.  Interoperability especially
seems thwarted by this case.

On the sending end, I'm trying to imagine a client UI that might
indicate a user verb that goes something like - "Send calendar X and
also send an updated meeting request for event Y".  It just doesn't seem
to work.  Someone with more creativity, please help me understand the
sending client needs here.

I suggest that we deprecate the use of mixed METHOD iCals.

cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Doug Royer
Sent: Friday, August 20, 2004 11:57 AM
To: [email-masked]
Subject: Re: [Ietf-calsify] iMip and ALTREP and ATTACH

Does not RFC-2447 section "2.4 Content Type" cover that?

Rich bodies as in multipart/alternate?

Examples, yep more would help.

Cameron Stillion wrote:

>I don't see anything in iMip that reflects the Lotus implementation.
>And I don't see a PUBLISH example with attachments and rich bodies.
>This might be worth adding.  Who's working on this?
>
>  
>

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[email-masked]                 | Office: (208)520-4044
http://Royer.com/People/Doug   | Fax:    (866)594-8574
                               | Cell:   (208)520-4044

              We Do Standards - You Need Standards

---

From: Doug at Royer.com (Doug Royer)
Date: Sat Aug 21 13:12:41 2004

>good reason a client might do so?
To transfer an entire calendar and scheduling queue.

>seems thwarted by this case.

A calendar can have items that have not been processed by the CU/CUA yet.

>sending client needs here.
To have a copy of the calendar, so the CUA can display it to the CU and
the CU can act upon the contents. Accepting some REQUESTs and changing
them to booked entries. Accepting or declining COUNTER objects, ...

>I suggest that we deprecate the use of mixed METHOD iCals.
There can only be one METHOD value per mime object now per the RFCs.
however your can send multiple MIME objects, each with a unique METHOD
value in one email.

-- 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4696 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20040821/07192544/smime.bin

---

From: nsb at guppylake.com (Nathaniel Borenstein)
Date: Wed Aug 25 15:26:38 2004

> good reason a client might do so?

I'd pose a different question:  Can we possibly prevent it?  Imagine 
that I get 7 different messages in the mail, each containing an ical 
object.  My MUA allows me to select all 7 and forward them as a group.  
I'd probably be intending, in doing that, for the recipient to get all 
7, but I can't assume a priori anything about them, can I?  -- 
Nathaniel

---

From: Robert_Ransdell at notesdev.ibm.com ([email-masked])
Date: Wed Aug 25 15:45:21 2004

the iMip already restricts contents if a single vCalendar stream to 1 
method

2.4 Content Type

   A MIME body part containing content information that conforms to this
   document MUST have an [RFC-2045] "Content-Type" value of
   "text/calendar". The [RFC-2045] "Content-Type" header field must also
   include the type parameter "method". The value MUST be the same as
   the value of the "METHOD" calendar property within the iCalendar

   object.  This means that a MIME message containing multiple iCalendar
   objects with different method values must be further encapsulated
   with a "multipart/mixed" MIME entity. This will allow each of the
   iCalendar objects to be encapsulated within their own "text/calendar"
   MIME entity.

Nathaniel Borenstein <[email-masked]> 
Sent by: [email-masked]
08/25/2004 06:26 PM

To
"Cameron Stillion" <[email-masked]>
cc
[email-masked]
Subject
Re: [Ietf-calsify] iMip and Mixing content

_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify