Subject: [Ietf-calsify] Open issues in iMIP revision (draft-ietf-calsify-rfc2447bis-00.txt)

From: alexey.melnikov at isode.com (Alexey Melnikov)
Date: Fri Aug 19 07:27:04 2005

[email-masked] wrote:

>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>This draft is a work item of the Calendaring and Scheduling Standards Simplification Working Group of the IETF.
>
>	Title		: iCalendar Message-Based Interoperability Protocol (iMIP)
>	Author(s)	: A. Melnikov
>	Filename	: draft-ietf-calsify-rfc2447bis-00.txt
>	Pages		: 20
>	Date		: 2005-8-18
>	
>   This document, [iMIP], specifies a binding from the iCalendar
>   Transport-independent Interoperability Protocol (iTIP) to Internet
>   email-based transports. Calendaring entries defined by the iCalendar
>   Object Model [iCAL] are composed using constructs from [RFC-2822],
>   [RFC-2045], [RFC-2046], [RFC-2047], [RFC-2048] and [RFC-2049].
>
Hi everyone.

I've just submitted a revision of iMIP document. It mostly contains the 
editorial changes:
1). Updated boilerplate.
2). Updated some references, split them into Normative and Informative.
3). Updated mailing list information.
4). Updated examples to use example.com/example.net domains.

Here is the list of open issues (I've started addressing some of them):
1). In section "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".

I think the "must" in the last sentence is actually a MUST. Is there any 
objection to changing that?

2). Reading mailing list archives I got impression that there were some 
iMIP interop issues because some clients were (are?) unable to handle 
calendars encapsulated in multipart/*. I've added a new paragraph that 
tries to clarify the issue:

Any receiving UA compliant with this specification MUST be able to 
process "text/calendar" body parts enclosed within "multipart/*".
<<Is any clarification about handling of "multipart/alternative" 
needed?>> Note that a "multipart/mixed" MIME message can include 
multiple "text/calendar" components. The receiving UA MUST be able to 
process all of them. <<Should infinite multipart/mixed nesting be allowed?>>

Note my 2 editorial comments in <<>>. Any input on the text (and the two 
comments in particular) is welcomed.

3). In section "2.5 Content-Transfer-Encoding".

The section says:

 Note that the default character set for iCalendar objects is UTF-8.

After rereading the sentence several times I am not entirely sure what 
it means.
RFC 2822 says that the default charset is US-ASCII, if not specified. 
The iMIP document can't override this rule.
I think this sentence is trying to say that all CUAs MUST be able to 
accept calendars with data in UTF-8.
If it is the case, this sentence should be rewritten to clarify.

Later in the same section RFC 2447 said:

 A transfer encoding SHOULD be used for iCalendar objects containing any
 characters that are not part of the US-ASCII character set.

Once again I was not entirely sure what this sentence was trying to say. 
Is it trying to say that unless you use 8bit safe transport, you should 
use content transfer encodings like quoted-printable or base64?

Alexey

__________________________________________
Isode M-Box Message Store developer
http://www.isode.com/products/m-box.html

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html

Personal Home Page: http://www.melnikov.ca
__________________________________________

---

From: Internet-Drafts at ietf.org ([email-masked])
Date: Fri Aug 19 09:46:45 2005

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-calsify-rfc2447bis-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-calsify-rfc2447bis-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-calsify-rfc2447bis-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
-------------- next part --------------
Skipped content of type multipart/alternative

---

From: Doug at Royer.com (Doug Royer)
Date: Fri Aug 19 11:45:52 2005

Skipped content of type multipart/mixed-------------- 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/20050819/1c3a12d2/smime.bin

---

From: Robert_Ransdell at notesdev.ibm.com ([email-masked])
Date: Fri Aug 19 12:55:31 2005

An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050819/680d6528/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Doug.vcf
Type: application/octet-stream
Size: 390 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050819/680d6528/Doug.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/octet-stream
Size: 4696 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050819/680d6528/smime.obj

---

From: Doug at Royer.com (Doug Royer)
Date: Fri Aug 19 13:28:12 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050819/968b4465/smime.bin

---

From: alexey.melnikov at isode.com (Alexey Melnikov)
Date: Sun Aug 21 07:48:04 2005

Doug Royer wrote:

> Alexey Melnikov wrote:
>> After rereading the sentence several times I am not entirely sure 
>> what it means.
> It does not override making the default for 2822 MIME objects UTF-8.
> Just set the transfer-encoding to UTF-8 in the MIME header for
> text/calendar objects or encode the iCal object.
>
> 2445 says that the default for iCal objects is UTF-8.

I see now, so the sentence is trying to say:

 Note that according to RFC 2445 the default character set for iCalendar 
objects is UTF-8.

That certainly makes more sense.

> As you can't always declare them as US-ASCII (Unless that just happen
> to be from that subset), so you must set the transfer encoding
> or some how encode the iCal object.
>
> That is also true.
>> Once again I was not entirely sure what this sentence was trying to 
>> say. Is it trying to say that unless you use 8bit safe transport, you 
>> should use content transfer encodings like quoted-printable or base64?
>
> US-ASCII is a subset of UTF-8. So if your iCal object is 100% US-ASCII,
> then you do not have to set the transfer-encoding to UTF-8 or encode
> anything.
>
> If your iCal object contains more than US-ASCII characters, you have
> to do the right MIME thing - what ever that is.

Then I don't understand why RFC 2447 uses SHOULD, instead of MUST here.
Use of content transfer encodings for non-ascii text parts is required 
by MIME. Is the quoted sentence just repeating one of MIME requirements, 
or is it trying to say something extra?

> And the preferred iCal object is in UTF-8, however it can be any
> charset, just make the MIME headers match what you are sending.

Aside: that is certainly true, but for interoperability we need to pick 
one charset.