Subject: Re: CAP: why do we need GENERATEUID?

From: [email-masked]
Date: Tue, 6 Nov 2001 13:34:59 -0500

Doug wrote on 11/05/2001 03:49:37 PM:
> > Not true of IMAP.  The IMAP server must be able to understand the 
structure
> > of the entire MIME stream so that it can deal with IMAP clients that 
want to
> > query the messages structure, etc.  They can also care about the 
contents in
> > some cases such as statistics generation, attachment scanning (for 
virsues,
> > confidentail info, etc) and other assorted 'administrative' tasks.
> 
> Not for encrypted MIME body parts. That's the point of encrypting them.

Thats the problem w/using both signing and encryption in the same thread; 
its hard to always distinguish between a signed only case and an 
encryption only case (or the signed AND encrypted case). 

The IMAP server needs to understand the MIME hierarchy of an encrypted 
only msg in that it must be able to at least parse out the encrypted 
block(s) from the rest so that it can build the MIME hierarchy properly so 
that it can be properly represented to the IMAP client.  It does NOT have 
to parse into and grok the encrypted data (I never claimed that).  It must 
be able to at least grok what body parts are encrypted and 'do the best it 
can' w/them but deal properly w/the other non-encrypted body parts that 
occur before/after the encrypted stuff (in the worse case scenario of only 
encrypted some body parts, NOT all of them).

In any case, the citation of IMAP/POP3 has been streteched beyond the 
intended discussion use.  Time to get back to the original topic.  I think 
we are in agreement about keeping GENERATEUID so persuing this under the 
current title is a digression.  (We can persue it under its own heading 
later...)

> Yes there is such a restriction. If the CS can not parse the object,
> it is not a valid object. Look at the restriction tables. If the CS
> does not know if there is a UID, SUMMARY, DTSTART, ..., then it
> is not a valid object. 

This gets back to the unresolved issue about the requirements of CAP and 
not relevant to GENERATEUID.  We can take this up (again) under its own 
thread.

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Doug Royer <[email-masked]>
Date: Wed, 07 Nov 2001 14:30:53 -0700

> its hard to always distinguish between a signed only case and an encryption
> only case (or the signed AND encrypted case).

Okay, now I understand (I think).

Are you saying that you want a CAP server to be able to get
a MIME object, some of which could be encrypted (some BODY PARTS),
and you want the CAP server to be able to pull out the non-encrypted
body-parts that are CAP/iCal object (not encrypted)?

Or in other words ar you saying(?):

	A CAP server MUST BE able to process a MIME object of
	type MULTIPART/<whatever> and correctly extract out the iCalendar
	object and ignore the non-iCalendar body-parts?

If so, I agree. And I think that is one of the things that Frank
kept promising to get into iCalendar-next. I Think that CAP used
to say that, however it is not in the current draft - a TODO?

I think the problem came up when everyone (except Microsoft), could
handle multipart/<whatever> with text/calendar MIME objects.
The current wording in CAP does not say this. I am sure it was
added at some point, but it is not in cap now.

Did someone remove it? If so why?

-Doug

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Thu, 8 Nov 2001 15:09:59 +0100

Here is the URL to the paper I am giving in a session together with Libby
Miller at XML2001 in Orlando.

The aim of the paper is to formalize a logical and mnemonic model for the
representation of Temporal information.

The model, which we are calling Orlando, is evolved from the iCal RFC2445
datetime and datetime reoccurrence rules.

In our migration from mime-directory to XML and RDF, it is important that we
identify the incongruities discovered in the RFC2445 reoccurrence rules and
make sure that we just don't pass these problems on unsolved.

Other problems addressed are:

Unambiguous identification of end-inclusive/end-exclusive interval
representation.

Unambiguous identification of periods.  Are they duration specific ( the
exact amount of days of seconds) or are they calendar specific (landing on
some exact point on a wall clock or calendar?

Any comments are appreciated and serious goofs unearthed will earn you a
beer at the next IETF.

the link is:

http://skical.org/orlando/

Greg

---

From: "Shannon J. Clark" <[email-masked]>
Date: Thu, 8 Nov 2001 13:51:18 -0600

Doug,

Just a thought along these lines:

1 - are we discussing a MULTIPART composed of iCalendar related objects?
(some encrypted, some not perhaps?)

or

2 - are we discussing a MULTIPART composed of a text or text/html object +
an iCalendar object?

Also - if the iCalendar object has say an Attachment - are we considering
allowing that ATTACHMENT to be bundled as part of the MULTIPART message,
and/or for that ATTACHMENT to be encrypted in some manner?

Shannon

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Doug Royer
Sent: Wednesday, November 07, 2001 3:31 PM
To: [email-masked]
Subject: Re: MIME Multiple body parts (Was Re: uid...)

> its hard to always distinguish between a signed only case and an
encryption

-Doug

---

From: Doug Royer <[email-masked]>
Date: Fri, 09 Nov 2001 15:21:35 -0700

> (some encrypted, some not perhaps?)

YES

> 2 - are we discussing a MULTIPART composed of a text or text/html object +

AND
YES

> and/or for that ATTACHMENT to be encrypted in some manner?

We allow attachments (AKA body parts) because we allow CID's and MID's
as URL's in the vCalendar object. That means that one MIME message as
MULTIPART/RELATED can have N-number of body parts, one of which
is the vCalendar object (text/calendar).

A CID is a CONTENT-ID, and means that one URL in the text/calendar
body part refers to the contents of another body part in the same MIME
message. Example:

	URL:cid:body-part-2

(note: I may not have correctly shown a CID or MID url, but
 you'll get the idea).

A MID is a MESSAGE-ID to a MIME body part. That means that
a text/calendar body part can refer to any body part in any other
MIME message. Example:

	URL:mid:royer.com/~doug/message-3/body-part-3

Also, the WG agreed that MULTIPART/ALTERNATE was expected to
be allowed. (one part text/calendar, others any other representation
of the object text/plain, text/html, ...). Example:

	MIME-header ... MULTIPART/ALTERNATE

	<body-body-part-one ... text/calendar>
		BEGIN:VCALENDAR
		...
		END:VCALENDAR
	<end-body-part-one>
	<body-body-part-two ... text/plain>

	You have been invited to a party 
	Starts at: ....
	Ends at: ...
	...

	<end-body-part-two>

This DOES NOT mean that a CUA or a CS MUST implement the code
to process these. It mean that we agreed not to limit ourselves
and allow CID/MID's.

NOTE: MULTIPART/<whatever> may be combined/mixed and contain
other MULTIPART/<whatever>

Again we are not mandating that a CUA or CS MUST do this, we
are simply not restricting them from using all of MIME.

-Doug