Subject: [Ietf-calsify] Event class

From: camerost at exchange.microsoft.com (Cameron Stillion)
Date: Tue Aug 31 09:33:48 2004

Remember that we have declared iCal not only a transport format for
calendar information but also a storage format for applications.  The
implication here is that though transporting this prop does not
necessarily tell you anything interesting, and importers should be
careful NOT to assume its value is set by the user importing it - it has
value as a simple serialized property of the calendar.  The fact that
several implementations actually use it seems to indicate that there is
a reasonable justification for its existence.

In fact, I would expect that when a calendar is published or sent via
e-mail, my client had better exclude the events marked as PRIVATE or
CONFIDENTIAL (modulo some sort of override...)  It would be unacceptable
to include them and simply mark them as such.  Perhaps this is another
case of a property that should almost never be sent, but that may be
stored.

cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Doug Royer
Sent: Monday, August 30, 2004 10:40 PM
To: [email-masked]
Subject: Re: [Ietf-calsify] Event class

>
> And "CONFIDENTIAL" is defined as "user's trusted circle". We can leave

> the notion of who exactly is in that trusted circle out. For one thing

> nothing says that this  circle of trust won't change during the 
> meeting's life and really, who am I to tell anyone how to decide who 
> they should trust or where should that list live.
> __________________

It is not defined at all in rfc-244[567].

Even if we were to define it to mean that, how can it have any meaning
outside of the organizers opinion without being able to transfer who is
in that list? If you trust me and send me A CONFIDENTIAL VEVENT, I do
not have access to your trusted list. I can only interpret it to mean
my-trusteed list, and I forward it to someone I trust, that is not in
your trusted list.  
It has
no meaning outside of ACLs (VCARs).

It has no meaning in a REQUEST and other iMIP messages.
It only has context in CAP (or caldav) that contain VCARs.

In CAP you can define a VCAR called " user's trusted circle ", but it
has no meaning to an iMIP message if the VCAR is not transferred with
it.

So outside CAP or some kind of ACL's, there is no way to enforce who
gets access.

And at this time PRIVATE and CONFIDENTIAL are not defined, so any
existing implementation can not interoperate with certainty. It is
busted.

With CAP I could define a VCAR that said that UPN's UPN-A, UPN-B, and
UPN-C were in the VCAR named "user's trusted circle" and define that any
VEVENT with CLASS:CONFIDENTIAL uses that VCAR.
So when a CS/CUA reads the VEVENT and makes the iMIP message it could
decide if you can send it to that UPN, but after I get it, I still have
no clue who is in your trusted circle.

-- 

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: Tue Aug 31 10:07:24 2004

>...

I agree with both points. And the fact that  it is undefined and the
implementation specifics are disputed is the point. Patrice's explanation
is not consistent with yours. So would his CUA accessing your CS
give away your CONFIDENTIAL data?  It looks like yes as long
as who he wanted to iMIP it to, was in his trusted list.

Is the idea of CLASS useful - yes.
Is their consistent and interoperable usage of the CLASS property - no.

CLASS needs to be re-done in a way that new CUA's and CS's know
exactly what is expected, which (CUA or CS) is to enforce the access
control. And when to set it, forward it, or deny access to it.

-- 

-------------- 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/20040831/2b3e59b4/smime-0001.bin

Date: Tue, 31 Aug 2004 11:07:08 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Event class
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Tue, 31 Aug 2004 17:07:20 -0000

This is a cryptographically signed message in MIME format.

--------------ms070003020700070107050508
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

>...

I agree with both points. And the fact that  it is undefined and the
implementation specifics are disputed is the point. Patrice's explanation
is not consistent with yours. So would his CUA accessing your CS
give away your CONFIDENTIAL data?  It looks like yes as long
as who he wanted to iMIP it to, was in his trusted list.

Is the idea of CLASS useful - yes.
Is their consistent and interoperable usage of the CLASS property - no.

CLASS needs to be re-done in a way that new CUA's and CS's know
exactly what is expected, which (CUA or CS) is to enforce the access
control. And when to set it, forward it, or deny access to it.

-- 

--------------ms070003020700070107050508
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms070003020700070107050508--

Content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify] Event class
Date: Tue, 31 Aug 2004 09:33:45 -0700
From: "Cameron Stillion" <[email-masked]>
To: <[email-masked]>

cameron

-----Original Message-----

-- 

Date: Mon, 30 Aug 2004 23:39:31 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Event class
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Tue, 31 Aug 2004 05:39:43 -0000

This is a cryptographically signed message in MIME format.

--------------ms090607010707020703060708
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Even if we were to define it to mean that, how can it have any meaning 
outside
of the organizers opinion without being able to transfer who is in that 
list? If
you trust me and send me A CONFIDENTIAL VEVENT, I do not have
access to your trusted list. I can only interpret it to mean my-trusteed 
list,
and I forward it to someone I trust, that is not in your trusted list.  
It has
no meaning outside of ACLs (VCARs).

In CAP you can define a VCAR called " user's trusted circle ", but it
has no meaning to an iMIP message if the VCAR is not transferred with it.

So outside CAP or some kind of ACL's, there is no way to enforce
who gets access.

And at this time PRIVATE and CONFIDENTIAL are not defined, so
any existing implementation can not interoperate with certainty. It is 
busted.

With CAP I could define a VCAR that said that UPN's UPN-A, UPN-B, and
UPN-C were in the VCAR named "user's trusted circle" and define
that any VEVENT with CLASS:CONFIDENTIAL uses that VCAR.
So when a CS/CUA reads the VEVENT and makes the iMIP message
it could decide if you can send it to that UPN, but after I get it, I still
have no clue who is in your trusted circle.

-- 

--------------ms090607010707020703060708
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms090607010707020703060708--

Date: Mon, 30 Aug 2004 23:31:18 -0400
From: Patrice Scattolin <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Event class

Nathaniel Borenstein wrote:

> It is certainly reasonable to expect that a calendar user should be 
> able to tell a calendar store what privacy constraints it wants the 
> server to obey, but only if it's going to work no matter what brand of 
> server is on the other end.  I am not sure what the right solution is, 
> but my mantra remains:  when in doubt, simplify.  If we can't think of 
> a clearer way to define these terms, perhaps we should back off to an 
> unstructured text field and let vendors use X-values until we *can* 
> agree on definitions.

Well we could wait for an industry standard to emerge first and then 
standardised it. This has been the approached used in many other areas 
before.

Furthermore, as good a mantra as it is, it runs straight into the 
current ICal definition which is used and implented in various places. 
While there might be a place for "ICal-Lite", plain old heavy ICal is 
going to exist and be supported for a while. So if you simply by 
removing some items, maybe that's workable since it's essentially 
backwards compatible with the existing software but if you are going to 
go in a different direction you will only increase the clutter in this 
problem space to say nothing of the users of old ICal will then need to 
add these new construct to be able to support the new special semantics 
of ICal-Lite. Especially with unstructured textfield. While it's 
plausible that not all vendors can agree on specific semantics ahead of 
time for all possible values of the CLASS they will be close whereas 
interpreting unstructured fields is an exercise in reverse 
engineering/patching once the products are relased which is far worst.

> Other ideas?  Access lists are a fairly large problem, and I really 
> don't want to try to solve them in the iCal group, but neither do I 
> want to perpetuate an ill-defined "poor man's access list" if we can 
> help it.  Really, in my mind this all comes down to the lack of 
> clarity between PRIVATE and CONFIDENTIAL.  I could live with "PUBLIC," 
> "PRIVATE," and user-defined or to-be-defined values, I suppose, 
> because the distinction between "the user" and "everyone else" is an 
> easy, clean definition.  

From: Nathaniel Borenstein <[email-masked]>
Subject: Re: [Ietf-calsify] VALARM
Date: Mon, 30 Aug 2004 11:26:49 -0400
To: Bernard Desruisseaux <[email-masked]>
Cc: [email-masked]

It's starting to sound to me like the transport format should be a 
*subset* of the interactive access format.  Is that a useful thing to 
consider in simplifying the documents?  -- Nathaniel

On Aug 29, 2004, at 10:47 PM, Bernard Desruisseaux wrote:

> Cameron Stillion wrote:
>
>> I would like to suggest the removal of VALARM from the iCal spec.
>>  I have yet to hear or come up with a good scenario that includes 
>> sending
>> alarm information from one client to another.
>
> Cameron,
>
> Here's a good scenario:
>
> 1- I'm invited to a meeting.
>
> 2- I synchronize my SyncML device.
>
> 3- Since the calendar server knows that I want reminders
>    with a 10 minutes lead time, the VEVENT uploaded to
>    my SyncML device will contain a VALARM specifying an
>    alarm 10 minutes prior the VEVENT start time.
>
> Don't ask me for a good scenario in the context of iTIP.
> In my opinion, VALARM should not be used in the context
> of iTIP. If you receive an iTIP message with a VALARM
> just ignore it.
>
> Cheers,
> Bernard
>
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
>

From: Nathaniel Borenstein <[email-masked]>
Subject: Re: [Ietf-calsify] Event class
Date: Mon, 30 Aug 2004 11:25:26 -0400
To: Bernard Desruisseaux <[email-masked]>
Cc: [email-masked]

> - I create a confidential meeting on my SyncML device.
>
> - I synchronize my device with Oracle Calendar Server.
>
> - Thanks to the CLASS property, Oracle Calendar Server
>   will enforce the access control that applies to my
>   confidential meetings when people will try to access
>   this new meeting on the server.

The only problem I have with this example is that it's a special case.  
  What if it's someone else's calendar server, but the same client?  
We're designing open protocols, right?  How can we justify having this 
capability in the language if we can't explain what it means in a 
precise, interoperable way?  The definitions of things like "SENSITIVE" 
might be customer-specific, but they oughtn't to be vendor-specific if 
we can avoid it!

> You receive a document from an IBM colleague stamped with
> the words "TOP SECRET" on the first page. As an IBM employee
> you know what "TOP SECRET" means per IBM's policies.
>
> If I send you an Oracle document stamped with the word
> "CONFIDENTIAL" on the first page you won't exactly know
> what "CONFIDENTIAL" means because you are not an Oracle
> employee.

But the CLASS property doesn't carry all the necessary context.  I know 
what to do with "IBM Confidential" because I have the word "IBM" in 
addition to the word "Confidential".  Similarly, I also understand that 
if I pay you a million dollars (Canadian, of course) for a document 
marked "Oracle Confidential" I don't really have as precise a knowledge 
of what "Confidential" means in this context -- for all I know it could 
be the very lowest of a ten-tier secrecy system that defines concentric 
circles around Larry Ellison, and I could be overpaying heavily for the 
document.  But with CLASS, all I get is "Confidential" -- I don't even 
know *whose* confidential, which could lead to some seriously violated 
user expectations in trying  to interchange data heterogeneously.

It is certainly reasonable to expect that a calendar user should be 
able to tell a calendar store what privacy constraints it wants the 
server to obey, but only if it's going to work no matter what brand of 
server is on the other end.  I am not sure what the right solution is, 
but my mantra remains:  when in doubt, simplify.  If we can't think of 
a clearer way to define these terms, perhaps we should back off to an 
unstructured text field and let vendors use X-values until we *can* 
agree on definitions.

Thinking about the "right" way to do this leads me into more complex 
ideas such as letting it be an explicitly organizationally defined 
field, as in

	CLASS:  [email-masked]

where (somewhere, somehow) ibm.com has defined a list of values and 
their meanings, and one of them means "only show this to IBM people who 
have signed a confidentiality agreement with Oracle corporation that is 
effective in 2005."   Big companies have to draw internal lines like 
that all the time.  it still looks like an access list to me.  If 
access lists are what we need, we should just leave a hook in the 
standard and go to work on access lists when we're done with calendars. 
  :-)

> In some cases the originator and recipients
> of iTIP messages will share the semantic of the CLASS
> property and in other cases they won't.

In essence, I think, you are saying that the meaning of CLASS is 
determined according to the (out-of-spec) interpretation of 
"consenting" software.  I say that this is a recipe for confusion.  I 
think if we're going to define a field to be interchanged between 
heterogeneous software, we should either define what it means or make 
it an uninterpreted, unstructured field, i.e. a "privacy label".

Other ideas?  Access lists are a fairly large problem, and I really 
don't want to try to solve them in the iCal group, but neither do I 
want to perpetuate an ill-defined "poor man's access list" if we can 
help it.  Really, in my mind this all comes down to the lack of clarity 
between PRIVATE and CONFIDENTIAL.  I could live with "PUBLIC," 
"PRIVATE," and user-defined or to-be-defined values, I suppose, because 
the distinction between "the user" and "everyone else" is an easy, 
clean definition.  -- Nathaniel

Date: Sun, 29 Aug 2004 22:47:10 -0400
From: Bernard Desruisseaux <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] VALARM

Cameron Stillion wrote:

> I would like to suggest the removal of VALARM from the iCal spec.
>  
> I have yet to hear or come up with a good scenario that includes sending
> alarm information from one client to another.

Cameron,

Here's a good scenario:

1- I'm invited to a meeting.

2- I synchronize my SyncML device.

3- Since the calendar server knows that I want reminders
    with a 10 minutes lead time, the VEVENT uploaded to
    my SyncML device will contain a VALARM specifying an
    alarm 10 minutes prior the VEVENT start time.

Don't ask me for a good scenario in the context of iTIP.
In my opinion, VALARM should not be used in the context
of iTIP. If you receive an iTIP message with a VALARM
just ignore it.

Cheers,
Bernard

Date: Sun, 29 Aug 2004 22:33:14 -0400
From: Bernard Desruisseaux <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Event class

Nathaniel,

Here's a use case:

- I create a confidential meeting on my SyncML device.

- I synchronize my device with Oracle Calendar Server.

- Thanks to the CLASS property, Oracle Calendar Server
   will enforce the access control that applies to my
   confidential meetings when people will try to access
   this new meeting on the server.

Was the CLASS property used for access control?  No.

Was the CLASS property useful? Yes, it allowed me to
set the access classification of a new meeting from my
SyncML device.

Who cares what Bernard's access classification "confidential"
means?  Only Bernard and his calendar store.

Now you are going to ask me: « What about iTIP? » (Right? :-))

Answer #1: iCalendar is not only meant for iTIP.

Answer #2: Let me try this analogy:

You receive a document from an IBM colleague stamped with
the words "TOP SECRET" on the first page. As an IBM employee
you know what "TOP SECRET" means per IBM's policies.

If I send you an Oracle document stamped with the word
"CONFIDENTIAL" on the first page you won't exactly know
what "CONFIDENTIAL" means because you are not an Oracle
employee.

Same with iTIP. In some cases the originator and recipients
of iTIP messages will share the semantic of the CLASS
property and in other cases they won't.

Cheers,
Bernard

Nathaniel Borenstein wrote:

> On Aug 26, 2004, at 2:18 PM, Bernard Desruisseaux wrote:
> 
>> Here's an example for modify:
>>
>> - User B (my assistant) is allowed to modify my PUBLIC and CONFIDENTIAL
>>   calendar objects.
>>
>> - User B (my assistant) is not allowed to modify my PRIVATE calendar
>>   objects.
> 
> 
> This is a wonderfully clear example.  Unfortunately, I can't find this 
> interpretation anywhere in RFC 2445.  Have I missed it, or is it simply 
> one possible interpretation of the difference between PRIVATE and 
> CONFIDENTIAL?  At the very least, this needs to be clarified, but I'm 
> not yet convinced it shouldn't simply be eliminated.
> 
> I think we are facing a classic tradeoff, insufficiently analyzed.  
> There is a very large general problem, which is access lists.  There is 
> a very specific application, format and protocol, calendaring, which has 
> its own specific access control needs.  The current values of CLASS 
> reflect an attempt to follow the 80/20 rule and cover most use cases 
> without overly generalized complexity.  The question is, did it work?  
> If you can convince me that PUBLIC/PRIVATE/CONFIDENTIAL covers 80% or 
> more of the use cases, I will stop objecting to CLASS.  However, I fear 
> that most users' environments are sufficiently complex that the coverage 
> is probably more like 20% than 80%, in which case CLASS complicates the 
> standard for (IMHO) inadequate value.
> 
> I don't suppose anyone has anything as useful as ethnographic data to 
> help us tell what percentage of the use cases we are actually covering? 
>  -- Nathaniel
> 
> PS -- As I've been suggesting for other topics... since the CLASS 
> property is both informational-only (as per RFC 2445) and arguably 
> representationally inadequate, it might be a better idea to remove it 
> from the base spec and then (if someone is sufficiently motivated) write 
> an additional spec on access control in iCal, which might even define a 
> somewhat richer approach that is backwards-compatible with RFC 2445's 
> CLASS property.  -- NB
> 

Date: Sun, 29 Aug 2004 16:23:34 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] VALARM
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
Cc: [email-masked]
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Sun, 29 Aug 2004 22:23:53 -0000

This is a cryptographically signed message in MIME format.

--------------ms080206040206070903020009
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

(On the CALSIFY mailing list we are talking about the next rev of 244[567].)

Nathaniel Borenstein wrote:

> ....
>
> I have nothing against VALARM per se, but I am skeptical of including 
> anything in the base standard that isn't needed for data interchange 
> between heterogeneous systems, because such transport is the most 
> important problem we are trying to solve.  In the case of VALARM, the 
> thin client CalDav example is fairly compelling, but even there I see 
> it as belonging in a separate spec that describes user-side concepts.

It is needed so CUA from vendor A can set an alarm in CS vendor B product.
MANY implementations discard objects they do not know. Without
a standardized VALARM, you can't set one. Your talking about access control
on the VALARM objects. And it is needed so that CUA from vendor A can see an
alarm in the CS.

> (Personally, I want to be able to set an alarm for myself, but I don't 
> want anyone else to set an alarm for *me*.)  -- Nathaniel

Without VALARM - how would you set a VALARM in a CS were both
the CUA and CS were not the same vendor, unless there was a standard
way to set the alarm?

Your talking about access control on the VALARM objects.

I do not care if VALARM is a separate draft from the others or not.
I do think many implementations will break if there is not a 
standardized alarm.

-- 

--------------ms080206040206070903020009
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms080206040206070903020009--

From: Nathaniel Borenstein <[email-masked]>
Subject: Re: [Ietf-calsify] Aiding the process (I hope)
Date: Sat, 28 Aug 2004 13:10:39 -0400
To: [email-masked]
Cc: [email-masked]

--Apple-Mail-18--558277328
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

On Aug 26, 2004, at 12:22 AM, [email-masked] wrote:

> In an effort to get a handle on things, I've built this file 
> (attached) to document the major elements of RCF2445/6/7 and CAP-13. 
> It's in XML, because....

Although Tim's reasons for xml make sense, naturally the first thing I 
did was convert it to an HTML table.  So I thought I'd share that with 
anyone who hasn't actually tried to read the file yet...

--Apple-Mail-18--558277328
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	x-unix-mode=0644;
	name="elements.html"
Content-Disposition: attachment;
	filename=elements.html

<html>=0D
<table border=3D1>=0D
=
<tr><td>ElementName</td><td>Description</td><td>RFC</td><td>Section</td></=
TR>=0D
=0D
<tr><Td type=3D"Command"> ABORT</Td><td>ABORT =
Command</td><td>CAP13</td><td>10.2</td></tr>=0D
<tr><Td type=3D"Command"> CONTINUE</Td><td>CONTINUE =
Command</td><td>CAP13</td><td>10.3</td></tr>=0D
<tr><Td type=3D"Command"> CREATE</Td><td>CREATE =
Command</td><td>CAP13</td><td>10.4</td></tr>=0D
<tr><Td type=3D"Command"> DELETE</Td><td>DELETE =
Command</td><td>CAP13</td><td>10.5</td></tr>=0D
<tr><Td type=3D"Command"> GENERATE-UID</Td><td>GENERATE-UID =
Command</td><td>CAP13</td><td>10.6</td></tr>=0D
<tr><Td type=3D"Command"> GET-CAPABILITY</Td><td>GET-CAPABILITY =
Command</td><td>CAP13</td><td>10.7</td></tr>=0D
<tr><Td type=3D"Command"> IDENTIFY</Td><td>IDENTIFY =
Command</td><td>CAP13</td><td>10.8</td></tr>=0D
<tr><Td type=3D"Command"> MODIFY</Td><td>MODIFY =
Command</td><td>CAP13</td><td>10.9</td></tr>=0D
<tr><Td type=3D"Command"> MOVE</Td><td>MOVE =
Command</td><td>CAP13</td><td>10.10</td></tr>=0D
<tr><Td type=3D"Command"> REPLY</Td><td>REPLY Response to a =
Command</td><td>CAP13</td><td>10.11</td></tr>=0D
<tr><Td type=3D"Command"> SEARCH</Td><td>SEARCH =
Command</td><td>CAP13</td><td>10.12</td></tr>=0D
<tr><Td type=3D"Command"> SET-LOCALE</Td><td>SET-LOCALE =
Command</td><td>CAP13</td><td>10.13</td></tr>=0D
<tr><Td type=3D"Command"> TIMEOUT</Td><td>TIMEOUT =
Command</td><td>CAP13</td><td>10.14</td></tr>=0D
<tr><Td type=3D"Component"> VEVENT</Td><td>Event =
Component</td><td>2445</td><td>4.6.1</td></tr>=0D
<tr><Td type=3D"Component"> VTODO</Td><td>To-do =
Component</td><td>2445</td><td>4.6.2</td></tr>=0D
<tr><Td type=3D"Component"> VJOURNAL</Td><td>Journal =
Component</td><td>2445</td><td>4.6.3</td></tr>=0D
<tr><Td type=3D"Component"> VFREEBUSY</Td><td>Free/Busy =
Component</td><td>2445</td><td>4.6.4</td></tr>=0D
<tr><Td type=3D"Component"> VTIMEZONE</Td><td>Time Zone =
Component</td><td>2445</td><td>4.6.5</td></tr>=0D
<tr><Td type=3D"Component"> VALARM</Td><td>Alarm =
Component</td><td>2445</td><td>4.6.6</td></tr>=0D
<tr><Td type=3D"Component"> VAGENDA</Td><td>VAGENDA =
Component</td><td>CAP13</td><td>9.1</td></tr>=0D
<tr><Td type=3D"Component"> VCALSTORE</Td><td>VCALSTORE =
Component</td><td>CAP13</td><td>9.2</td></tr>=0D
<tr><Td type=3D"Component"> VCAR</Td><td>VCAR =
Component</td><td>CAP13</td><td>9.3</td></tr>=0D
<tr><Td type=3D"Component">VRIGHT</Td><td>VRIGHT =
Component</td><td>CAP13</td><td>9.4</td></tr>=0D
<tr><Td type=3D"Component">VREPLY</Td><td>VREPLY =
Component</td><td>CAP13</td><td>9.5</td></tr>=0D
<tr><Td type=3D"Component">VQUERY</Td><td>VQUERY =
Component</td><td>CAP13</td><td>9.6</td></tr>=0D
<tr><Td type=3D"Method">PUBLISH</Td><td>Publish Calendar =
information</td><td>2446</td><td>3.2.1</td></tr>=0D
<tr><Td type=3D"Method">REQUEST</Td><td>Make a scheduling =
request</td><td>2446</td><td>3.2.2</td></tr>=0D
<tr><Td type=3D"Method">REPLY</Td><td>Reply to scheduling =
request</td><td>2446</td><td>3.2.3</td></tr>=0D
<tr><Td type=3D"Method">ADD</Td><td>Add =
instances</td><td>2446</td><td>3.2.4</td></tr>=0D
<tr><Td type=3D"Method">CANCEL</Td><td>Cancel =
instances</td><td>2446</td><td>3.2.5</td></tr>=0D
<tr><Td type=3D"Method">REFRESH</Td><td>Get latest =
version</td><td>2446</td><td>3.2.6</td></tr>=0D
<tr><Td type=3D"Method">COUNTER</Td><td>Negotiate a =
change</td><td>2446</td><td>3.2.7</td></tr>=0D
<tr><Td type=3D"Method">DECLINECOUNTER</Td><td>Decline a =
change</td><td>2446</td><td>3.2.8</td></tr>=0D
<tr><Td type=3D"Parameter"> ACTION</Td><td>ACTION =
Parameter</td><td>CAP13</td><td>7.1</td></tr>=0D
<tr><Td type=3D"Parameter"> ENABLE</Td><td>ENABLE =
Parameter</td><td>CAP13</td><td>7.2</td></tr>=0D
<tr><Td type=3D"Parameter"> ID</Td><td>ID =
Parameter</td><td>CAP13</td><td>7.3</td></tr>=0D
<tr><Td type=3D"Parameter"> LATENCY</Td><td>LATENCY =
Parameter</td><td>CAP13</td><td>7.4</td></tr>=0D
<tr><Td type=3D"Parameter"> LOCAL</Td><td>LOCAL =
Parameter</td><td>CAP13</td><td>7.5</td></tr>=0D
<tr><Td type=3D"Parameter"> LOCALIZE</Td><td>LOCALIZE =
Parameter</td><td>CAP13</td><td>7.6</td></tr>=0D
<tr><Td type=3D"Parameter"> OPTIONS</Td><td>OPTIONS =
Parameter</td><td>CAP13</td><td>7.7</td></tr>=0D
<tr><Td type=3D"Parameter"> ALTREP</Td><td>Alternate Text =
Representation</td><td>2445</td><td>4.2.1</td></tr>=0D
<tr><Td type=3D"Parameter"> CN</Td><td>Common =
Name</td><td>2445</td><td>4.2.2</td></tr>=0D
<tr><Td type=3D"Parameter"> CUTYPE</Td><td>Calendar User =
Type</td><td>2445</td><td>4.2.3</td></tr>=0D
<tr><Td type=3D"Parameter"> =
DELEGATED-FROM</Td><td>Delegators</td><td>2445</td><td>4.2.4</td></tr>=0D=

<tr><Td type=3D"Parameter"> =
DELEGATED-TO</Td><td>Delegatees</td><td>2445</td><td>4.2.5</td></tr>=0D
<tr><Td type=3D"Parameter"> DIR</Td><td>Directory Entry =
Reference</td><td>2445</td><td>4.2.6</td></tr>=0D
<tr><Td type=3D"Parameter"> ENCODING</Td><td>Inline =
Encoding</td><td>2445</td><td>4.2.7</td></tr>=0D
<tr><Td type=3D"Parameter"> FMTTYPE</Td><td>Format =
Type</td><td>2445</td><td>4.2.8</td></tr>=0D
<tr><Td type=3D"Parameter"> FBTYPE</Td><td>Free/Busy Time =
Type</td><td>2445</td><td>4.2.9</td></tr>=0D
<tr><Td type=3D"Parameter"> =
LANGUAGE</Td><td>Language</td><td>2445</td><td>4.2.10</td></tr>=0D
<tr><Td type=3D"Parameter"> MEMBER</Td><td>Group or List =
Membership</td><td>2445</td><td>4.2.11</td></tr>=0D
<tr><Td type=3D"Parameter"> PARTSTAT</Td><td>Participation =
Status</td><td>2445</td><td>4.2.12</td></tr>=0D
<tr><Td type=3D"Parameter"> RANGE</Td><td>Recurrence Identifier =
Range</td><td>2445</td><td>4.2.13</td></tr>=0D
<tr><Td type=3D"Parameter"> RELATED</Td><td>Alarm Trigger =
Relationship</td><td>2445</td><td>4.2.14</td></tr>=0D
<tr><Td type=3D"Parameter"> RELTYPE</Td><td>Relationship =
Type</td><td>2445</td><td>4.2.15</td></tr>=0D
<tr><Td type=3D"Parameter"> ROLE</Td><td>Participation =
Role</td><td>2445</td><td>4.2.16</td></tr>=0D
<tr><Td type=3D"Parameter"> RSVP</Td><td>RSVP =
Expectation</td><td>2445</td><td>4.2.17</td></tr>=0D
<tr><Td type=3D"Parameter"> SENT-BY</Td><td>Sent =
By</td><td>2445</td><td>4.2.18</td></tr>=0D
<tr><Td type=3D"Parameter"> TZID</Td><td>Time Zone =
Identifier</td><td>2445</td><td>4.2.19</td></tr>=0D
<tr><Td type=3D"Parameter"> VALUE</Td><td>Value Data =
Types</td><td>2445</td><td>4.2.20</td></tr>=0D
<tr><Td type=3D"Property"> ALLOW-CONFLICT</Td><td>ALLOW-CONFLICT =
Property</td><td>CAP13</td><td>8.1</td></tr>=0D
<tr><Td type=3D"Property"> ATT-COUNTER</Td><td>ATT-COUNTER =
Property</td><td>CAP13</td><td>8.2</td></tr>=0D
<tr><Td type=3D"Property"> CALID</Td><td>CALID =
Property</td><td>CAP13</td><td>8.3</td></tr>=0D
<tr><Td type=3D"Property"> CALMASTER</Td><td>CALMASTER =
Property</td><td>CAP13</td><td>8.4</td></tr>=0D
<tr><Td type=3D"Property"> CAP-VERSION</Td><td>CAP-VERSION =
Property</td><td>CAP13</td><td>8.5</td></tr>=0D
<tr><Td type=3D"Property"> CARID</Td><td>CARID =
Property</td><td>CAP13</td><td>8.6</td></tr>=0D
<tr><Td type=3D"Property"> CAR-LEVEL</Td><td>CAR-LEVEL =
Property</td><td>CAP13</td><td>8.7</td></tr>=0D
<tr><Td type=3D"Property"> COMPONENTS</Td><td>COMPONENTS =
Property</td><td>CAP13</td><td>8.8</td></tr>=0D
<tr><Td type=3D"Property"> CSID</Td><td>CSID =
Property</td><td>CAP13</td><td>8.9</td></tr>=0D
<tr><Td type=3D"Property"> DECREED</Td><td>DECREED =
Property</td><td>CAP13</td><td>8.10</td></tr>=0D
<tr><Td type=3D"Property"> DEFAULT-CHARSET</Td><td>DEFAULT-CHARSET =
Property</td><td>CAP13</td><td>8.11</td></tr>=0D
<tr><Td type=3D"Property"> DEFAULT-LOCALE</Td><td>DEFAULT-LOCALE =
Property</td><td>CAP13</td><td>8.12</td></tr>=0D
<tr><Td type=3D"Property"> DEFAULT-TZID</Td><td>DEFAULT-TZID =
Property</td><td>CAP13</td><td>8.13</td></tr>=0D
<tr><Td type=3D"Property"> DEFAULT-VCARS</Td><td>DEFAULT-VCARS =
Property</td><td>CAP13</td><td>8.14</td></tr>=0D
<tr><Td type=3D"Property"> DENY</Td><td>DENY =
Property</td><td>CAP13</td><td>8.15</td></tr>=0D
<tr><Td type=3D"Property"> EXPAND</Td><td>EXPAND =
property</td><td>CAP13</td><td>8.16</td></tr>=0D
<tr><Td type=3D"Property"> GRANT</Td><td>GRANT =
Property</td><td>CAP13</td><td>8.17</td></tr>=0D
<tr><Td type=3D"Property"> ITIP-VERSION</Td><td>ITIP-VERSION =
Property</td><td>CAP13</td><td>8.18</td></tr>=0D
<tr><Td type=3D"Property"> MAX-COMP-SIZE</Td><td>MAX-COMP-SIZE =
Property</td><td>CAP13</td><td>8.19</td></tr>=0D
<tr><Td type=3D"Property"> MAXDATE</Td><td>MAXDATE =
Property</td><td>CAP13</td><td>8.20</td></tr>=0D
<tr><Td type=3D"Property"> MINDATE</Td><td>MINDATE =
Property</td><td>CAP13</td><td>8.21</td></tr>=0D
<tr><Td type=3D"Property"> MULTIPART</Td><td>MULTIPART =
Property</td><td>CAP13</td><td>8.22</td></tr>=0D
<tr><Td type=3D"Property"> NAME</Td><td>NAME =
Property</td><td>CAP13</td><td>8.23</td></tr>=0D
<tr><Td type=3D"Property"> OWNER</Td><td>OWNER =
Property</td><td>CAP13</td><td>8.24</td></tr>=0D
<tr><Td type=3D"Property"> PERMISSION</Td><td>PERMISSION =
Property</td><td>CAP13</td><td>8.25</td></tr>=0D
<tr><Td type=3D"Property"> QUERY</Td><td>QUERY =
property</td><td>CAP13</td><td>8.26</td></tr>=0D
<tr><Td type=3D"Property"> QUERYID</Td><td>QUERYID =
property</td><td>CAP13</td><td>8.27</td></tr>=0D
<tr><Td type=3D"Property"> REQUEST-STATUS</Td><td>REQUEST-STATUS =
property</td><td>CAP13</td><td>8.28</td></tr>=0D
<tr><Td type=3D"Property"> QUERY-LEVEL</Td><td>QUERY-LEVEL =
Property</td><td>CAP13</td><td>8.29</td></tr>=0D
<tr><Td type=3D"Property"> RECUR-ACCEPTED</Td><td>RECUR-ACCEPTED =
Property</td><td>CAP13</td><td>8.30</td></tr>=0D
<tr><Td type=3D"Property"> RECUR-LIMIT</Td><td>RECUR-LIMIT =
Property</td><td>CAP13</td><td>8.31</td></tr>=0D
<tr><Td type=3D"Property"> RECUR-EXPAND</Td><td>RECUR-EXPAND =
Property</td><td>CAP13</td><td>8.32</td></tr>=0D
<tr><Td type=3D"Property"> RESTRICTION</Td><td>RESTRICTION =
Property</td><td>CAP13</td><td>8.33</td></tr>=0D
<tr><Td type=3D"Property"> SCOPE</Td><td>SCOPE =
Property</td><td>CAP13</td><td>8.34</td></tr>=0D
<tr><Td type=3D"Property"> STORES-EXPANDED</Td><td>STORES-EXPANDED =
Property</td><td>CAP13</td><td>8.35</td></tr>=0D
<tr><Td type=3D"Property"> TARGET</Td><td>TARGET =
Property</td><td>CAP13</td><td>8.36</td></tr>=0D
<tr><Td type=3D"Property"> TRANSP</Td><td>TRANSP =
Property</td><td>CAP13</td><td>8.37</td></tr>=0D
<tr><Td type=3D"Property"> CMD</Td><td>CAP Commands =
(CMD)</td><td>CAP13</td><td>10.1</td></tr>=0D
<tr><Td type=3D"Property"> CALSCALE</Td><td>Calendar =
Scale</td><td>2445</td><td>4.7.1</td></tr>=0D
<tr><Td type=3D"Property"> =
METHOD</Td><td>Method</td><td>2445</td><td>4.7.2</td></tr>=0D
<tr><Td type=3D"Property"> PRODID</Td><td>Product =
Identifier</td><td>2445</td><td>4.7.3</td></tr>=0D
<tr><Td type=3D"Property"> =
VERSION</Td><td>Version</td><td>2445</td><td>4.7.4</td></tr>=0D
<tr><Td type=3D"Property"> =
ATTACH</Td><td>Attachment</td><td>2445</td><td>4.8.1.1</td></tr>=0D
<tr><Td type=3D"Property"> =
CATEGORIES</Td><td>Categories</td><td>2445</td><td>4.8.1.2</td></tr>=0D
<tr><Td type=3D"Property"> =
CLASS</Td><td>Classification</td><td>2445</td><td>4.8.1.3</td></tr>=0D
<tr><Td type=3D"Property"> =
COMMENT</Td><td>Comment</td><td>2445</td><td>4.8.1.4</td></tr>=0D
<tr><Td type=3D"Property"> =
TDRIPTION</Td><td>Tdription</td><td>2445</td><td>4.8.1.5</td></tr>=0D
<tr><Td type=3D"Property"> GEO</Td><td>Geographic =
Position</td><td>2445</td><td>4.8.1.6</td></tr>=0D
<tr><Td type=3D"Property"> =
LOCATION</Td><td>Location</td><td>2445</td><td>4.8.1.7</td></tr>=0D
<tr><Td type=3D"Property"> PERCENT-COMPLETE</Td><td>Percent =
Complete</td><td>2445</td><td>4.8.1.8</td></tr>=0D
<tr><Td type=3D"Property"> =
PRIORITY</Td><td>Priority</td><td>2445</td><td>4.8.1.9</td></tr>=0D
<tr><Td type=3D"Property"> =
RESOURCES</Td><td>Resources</td><td>2445</td><td>4.8.1.10</td></tr>=0D
<tr><Td type=3D"Property"> =
STATUS</Td><td>Status</td><td>2445</td><td>4.8.1.11</td></tr>=0D
<tr><Td type=3D"Property"> =
SUMMARY</Td><td>Summary</td><td>2445</td><td>4.8.1.12</td></tr>=0D
<tr><Td type=3D"Property"> COMPLETED</Td><td>Date/Time =
Completed</td><td>2445</td><td>4.8.2.1</td></tr>=0D
<tr><Td type=3D"Property"> DTEND</Td><td>Date/Time =
End</td><td>2445</td><td>4.8.2.2</td></tr>=0D
<tr><Td type=3D"Property"> DUE</Td><td>Date/Time =
Due</td><td>2445</td><td>4.8.2.3</td></tr>=0D
<tr><Td type=3D"Property"> DTSTART</Td><td>Date/Time =
Start</td><td>2445</td><td>4.8.2.4</td></tr>=0D
<tr><Td type=3D"Property"> =
DURATION</Td><td>Duration</td><td>2445</td><td>4.8.2.5</td></tr>=0D
<tr><Td type=3D"Property"> FREEBUSY</Td><td>Free/Busy =
Time</td><td>2445</td><td>4.8.2.6</td></tr>=0D
<tr><Td type=3D"Property"> TRANSP</Td><td>Time =
Transparency</td><td>2445</td><td>4.8.2.7</td></tr>=0D
<tr><Td type=3D"Property"> TZID</Td><td>Time Zone =
Identifier</td><td>2445</td><td>4.8.3.1</td></tr>=0D
<tr><Td type=3D"Property"> TZNAME</Td><td>Time Zone =
Name</td><td>2445</td><td>4.8.3.2</td></tr>=0D
<tr><Td type=3D"Property"> TZOFFSETFROM</Td><td>Time Zone Offset =
From</td><td>2445</td><td>4.8.3.3</td></tr>=0D
<tr><Td type=3D"Property"> TZOFFSETTO</Td><td>Time Zone Offset =
To</td><td>2445</td><td>4.8.3.4</td></tr>=0D
<tr><Td type=3D"Property"> TZURL</Td><td>Time Zone =
URL</td><td>2445</td><td>4.8.3.5</td></tr>=0D
<tr><Td type=3D"Property"> =
ATTENDEE</Td><td>Attendee</td><td>2445</td><td>4.8.4.1</td></tr>=0D
<tr><Td type=3D"Property"> =
CONTACT</Td><td>Contact</td><td>2445</td><td>4.8.4.2</td></tr>=0D
<tr><Td type=3D"Property"> =
ORGANIZER</Td><td>Organizer</td><td>2445</td><td>4.8.4.3</td></tr>=0D
<tr><Td type=3D"Property"> RECURRENCE-ID</Td><td>Recurrence =
ID</td><td>2445</td><td>4.8.4.4</td></tr>=0D
<tr><Td type=3D"Property"> RELATED-TO</Td><td>Related =
To</td><td>2445</td><td>4.8.4.5</td></tr>=0D
<tr><Td type=3D"Property"> URL</Td><td>Uniform Resource =
Locator</td><td>2445</td><td>4.8.4.6</td></tr>=0D
<tr><Td type=3D"Property"> UID</Td><td>Unique =
Identifier</td><td>2445</td><td>4.8.4.7</td></tr>=0D
<tr><Td type=3D"Property"> EXDATE</Td><td>Exception =
Date/Times</td><td>2445</td><td>4.8.5.1</td></tr>=0D
<tr><Td type=3D"Property"> EXRULE</Td><td>Exception =
Rule</td><td>2445</td><td>4.8.5.2</td></tr>=0D
<tr><Td type=3D"Property"> RDATE</Td><td>Recurrence =
Date/Times</td><td>2445</td><td>4.8.5.3</td></tr>=0D
<tr><Td type=3D"Property"> RRULE</Td><td>Recurrence =
Rule</td><td>2445</td><td>4.8.5.4</td></tr>=0D
<tr><Td type=3D"Property"> REPEAT</Td><td>Repeat =
Count</td><td>2445</td><td>4.8.6.2</td></tr>=0D
<tr><Td type=3D"Property"> =
ACTION</Td><td>Action</td><td>2445</td><td>4.8.6.1</td></tr>=0D
<tr><Td type=3D"Property"> =
TRIGGER</Td><td>Trigger</td><td>2445</td><td>4.8.6.3</td></tr>=0D
<tr><Td type=3D"Property"> CREATED</Td><td>Date/Time =
Created</td><td>2445</td><td>4.8.7.1</td></tr>=0D
<tr><Td type=3D"Property"> DTSTAMP</Td><td>Date/Time =
Stamp</td><td>2445</td><td>4.8.7.2</td></tr>=0D
<tr><Td type=3D"Property"> LAST-MODIFIED</Td><td>Last =
Modified</td><td>2445</td><td>4.8.7.3</td></tr>=0D
<tr><Td type=3D"Property"> SEQUENCE</Td><td>Sequence =
Number</td><td>2445</td><td>4.8.7.4</td></tr>=0D
<tr><Td type=3D"Property"> Any property name with a "X-" =
prefix</Td><td>Non-standard =
Properties</td><td>2445</td><td>4.8.8.1</td></tr>=0D
<tr><Td type=3D"Property"> REQUEST-STATUS</Td><td>Request =
Status</td><td>2445</td><td>4.8.8.2</td></tr>=0D
<tr><Td type=3D"Value"> =
BINARY</Td><td>Binary</td><td>2445</td><td>4.3.1</td></tr>=0D
<tr><Td type=3D"Value"> =
BOOLEAN</Td><td>Boolean</td><td>2445</td><td>4.3.2</td></tr>=0D
<tr><Td type=3D"Value"> CAL-ADDRESS</Td><td>Calendar User =
Address</td><td>2445</td><td>4.3.3</td></tr>=0D
<tr><Td type=3D"Value"> =
DATE</Td><td>Date</td><td>2445</td><td>4.3.4</td></tr>=0D
<tr><Td type=3D"Value"> =
DATE-TIME</Td><td>Date-Time</td><td>2445</td><td>4.3.5</td></tr>=0D
<tr><Td type=3D"Value"> =
DURATION</Td><td>Duration</td><td>2445</td><td>4.3.6</td></tr>=0D
<tr><Td type=3D"Value"> =
FLOAT</Td><td>Float</td><td>2445</td><td>4.3.7</td></tr>=0D
<tr><Td =
type=3D"Value">INTEGER</Td><td>Integer</td><td>2445</td><td>4.3.8</td></tr=
>=0D
<tr><Td type=3D"Value"> PERIOD</Td><td>Period of =
Time</td><td>2445</td><td>4.3.9</td></tr>=0D
<tr><Td type=3D"Value"> RECUR</Td><td>Recurrence =
Rule</td><td>2445</td><td>4.3.10</td></tr>=0D
<tr><Td type=3D"Value"> =
TEXT</Td><td>Text</td><td>2445</td><td>4.3.11</td></tr>=0D
<tr><Td type=3D"Value"> =
TIME</Td><td>Time</td><td>2445</td><td>4.3.12</td></tr>=0D
<tr><Td type=3D"Value"> =
URI</Td><td>URI</td><td>2445</td><td>4.3.13</td></tr>=0D
<tr><Td type=3D"Value"> UTC-OFFSET</Td><td>UTC =
Offset</td><td>2445</td><td>4.3.14</td></tr>=0D
<tr><Td type=3D"Value"> CAL-QUERY</Td><td>CAL-QUERY Value =
Type</td><td>CAP13</td><td>6.1.1</td></tr>=0D
<tr><Td type=3D"Value"> UPN</Td><td>UPN Value =
Type</td><td>CAP13</td><td>6.1.2</td></tr>=0D
<tr><Td type=3D"Value"> UPN-FILTER</Td><td>UPN-FILTER =
Value</td><td>CAP13</td><td>6.1.3</td></tr>=0D
</table>=0D
=0D

--Apple-Mail-18--558277328
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

Thanks, Tim.  -- Nathaniel

--Apple-Mail-18--558277328--

From: Nathaniel Borenstein <[email-masked]>
Subject: Re: [Ietf-calsify] Event class
Date: Sat, 28 Aug 2004 13:01:13 -0400
To: Bernard Desruisseaux <[email-masked]>
Cc: [email-masked]

On Aug 26, 2004, at 2:18 PM, Bernard Desruisseaux wrote:

> Here's an example for modify:
>
> - User B (my assistant) is allowed to modify my PUBLIC and CONFIDENTIAL
>   calendar objects.
>
> - User B (my assistant) is not allowed to modify my PRIVATE calendar
>   objects.

This is a wonderfully clear example.  Unfortunately, I can't find this 
interpretation anywhere in RFC 2445.  Have I missed it, or is it simply 
one possible interpretation of the difference between PRIVATE and 
CONFIDENTIAL?  At the very least, this needs to be clarified, but I'm 
not yet convinced it shouldn't simply be eliminated.

I think we are facing a classic tradeoff, insufficiently analyzed.  
There is a very large general problem, which is access lists.  There is 
a very specific application, format and protocol, calendaring, which 
has its own specific access control needs.  The current values of CLASS 
reflect an attempt to follow the 80/20 rule and cover most use cases 
without overly generalized complexity.  The question is, did it work?  
If you can convince me that PUBLIC/PRIVATE/CONFIDENTIAL covers 80% or 
more of the use cases, I will stop objecting to CLASS.  However, I fear 
that most users' environments are sufficiently complex that the 
coverage is probably more like 20% than 80%, in which case CLASS 
complicates the standard for (IMHO) inadequate value.

I don't suppose anyone has anything as useful as ethnographic data to 
help us tell what percentage of the use cases we are actually covering? 
  -- Nathaniel

PS -- As I've been suggesting for other topics... since the CLASS 
property is both informational-only (as per RFC 2445) and arguably 
representationally inadequate, it might be a better idea to remove it 
from the base spec and then (if someone is sufficiently motivated) 
write an additional spec on access control in iCal, which might even 
define a somewhat richer approach that is backwards-compatible with RFC 
2445's CLASS property.  -- NB

Date: Fri, 27 Aug 2004 08:18:41 -0600
From: "Preston Stephenson" <[email-masked]>
To: <[email-masked]>
Subject: RE: [Ietf-calsify] Event class

We map the PRIVATE to an internal status and control the access to the
item.
Do we need to come up with the concept of certain properties being
reserved words?
New implementations would not need to support them, but must pass them
on if they receive an iCal object with the property.
I don't think we want to mark them as deprecated, though.
Preston

>>> "Cameron Stillion" <[email-masked]> 08/26/04 4:00
PM >>>

The answer is yes, our implementation of Private actually limits
access
to users with ACLs to the item.  The private bit is used to filter in
views, printing, free/busy extraction and rendering, etc.  All of
these
are really just Application Rendering functionality, I suppose, but it
implies functionality as well.  If I can't see your private items, I
also can't move them, even if I have read/write access to your
calendar.

Of course, exporting this information (into an iCal format)
potentially
exposes private items in a way that is unenforcable outside the
client.
This is a matter of giving the user prominent notice and allowing them
to decide what they really want.  Currently, when the data leaves the
client, all bets are off, and the privacy is unenforceable.  But that
only happens when the user asks for it.

We have, in other contexts, asserted that iCal is a native storage
format as well as a transport schema.  In the guise of a native
storage
format, we should absolutely support the notion of CLASS so that
clients
(especially current implementations) can apply the notions they have,
and continue to support the features they perform.  In the guise of a
transport format, CLASS is somewhat interesting to clients with
similar
notions, but the user should understand that fidelity and
functionality
tend to wane in translation.

There is perhaps room for more clarification surrounding what we
propose
good clients ought to do with the critical values of PRIVATE and
PUBLIC,
but I'd avoid requiring anything special, especially of thin clients.
Supporting other values seems very reasonable, considering the
client-specific behavior we presume in the first place.

Cameron

-----Original Message-----
From: [email-masked] 
[mailto:[email-masked]] On Behalf Of Cyrus
Daboo
Sent: Thursday, August 26, 2004 1:23 PM
To: [email-masked]; [email-masked] 
Subject: RE: [Ietf-calsify] Event class

Hi [email-masked],

--On Thursday, August 26, 2004 3:28 PM -0400
[email-masked] wrote:

> The property is currently being used by several iCalendar
implementations.

Do any of those implementations actually do anything with that
property
other than display it to the user? e.g. do they prevent users from
storing the event in a public calendar if its marked as PRIVATE? If
they
do not do that then I think all we need to do is clarify the current
text for the property to explicitly state it is only for informational
purposes and CUAs should not attempt to process the value themselves
beyond alerting the user.

The alternative is to specify exactly what is expected to happen when
a
CUA receives a component with a class property. e.g. if its set to
PRIVATE then the CUA MUST ensure that only the recipient can access
the
event when it is saved to the local/remote calendar store. That means
clearly specifying the meaning of PUBLIC/PRIVATE/CONFIDENTIAL etc.

Perhaps people can explain exactly what there implementations
currently
do with CLASS. Maybe its come up in interops?

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

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

Content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify] Event class
Date: Thu, 26 Aug 2004 15:00:58 -0700
From: "Cameron Stillion" <[email-masked]>
To: "Cyrus Daboo" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: 

The answer is yes, our implementation of Private actually limits access
to users with ACLs to the item.  The private bit is used to filter in
views, printing, free/busy extraction and rendering, etc.  All of these
are really just Application Rendering functionality, I suppose, but it
implies functionality as well.  If I can't see your private items, I
also can't move them, even if I have read/write access to your calendar.

Of course, exporting this information (into an iCal format) potentially
exposes private items in a way that is unenforcable outside the client.
This is a matter of giving the user prominent notice and allowing them
to decide what they really want.  Currently, when the data leaves the
client, all bets are off, and the privacy is unenforceable.  But that
only happens when the user asks for it.

We have, in other contexts, asserted that iCal is a native storage
format as well as a transport schema.  In the guise of a native storage
format, we should absolutely support the notion of CLASS so that clients
(especially current implementations) can apply the notions they have,
and continue to support the features they perform.  In the guise of a
transport format, CLASS is somewhat interesting to clients with similar
notions, but the user should understand that fidelity and functionality
tend to wane in translation.

There is perhaps room for more clarification surrounding what we propose
good clients ought to do with the critical values of PRIVATE and PUBLIC,
but I'd avoid requiring anything special, especially of thin clients.
Supporting other values seems very reasonable, considering the
client-specific behavior we presume in the first place.

Cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Cyrus Daboo
Sent: Thursday, August 26, 2004 1:23 PM
To: [email-masked]; [email-masked]
Subject: RE: [Ietf-calsify] Event class

Hi [email-masked],

--On Thursday, August 26, 2004 3:28 PM -0400
[email-masked] wrote:

> The property is currently being used by several iCalendar
implementations.

Do any of those implementations actually do anything with that property
other than display it to the user? e.g. do they prevent users from
storing the event in a public calendar if its marked as PRIVATE? If they
do not do that then I think all we need to do is clarify the current
text for the property to explicitly state it is only for informational
purposes and CUAs should not attempt to process the value themselves
beyond alerting the user.

The alternative is to specify exactly what is expected to happen when a
CUA receives a component with a class property. e.g. if its set to
PRIVATE then the CUA MUST ensure that only the recipient can access the
event when it is saved to the local/remote calendar store. That means
clearly specifying the meaning of PUBLIC/PRIVATE/CONFIDENTIAL etc.

Perhaps people can explain exactly what there implementations currently
do with CLASS. Maybe its come up in interops?

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

Date: Thu, 26 Aug 2004 23:16:13 +0200 (CEST)
From: =?iso-8859-1?q?drkm?= <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] Subscribe the list to the Gmane Usenet gateway ?

  Hello

  While the sister ietf-caldav mailing list is registered at Gmane, I
can't find ietf-calsify there.

  For those not already knowing Gmane, it is a kind of gateway between
mailing lists and Usenet.  It freely provides a Usenet server.  All we
need to do is subscribing the list at

    <URL:http://gmane.org/subscribe.php>

  I'd like to follow the discussions here for a while, and I think it's
more easy the Usenet way.  If you want, I can subscribe the list, but I
don't know the list already, so I think it's better someone else do it.

  Thanks,

--drkm

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Date: Thu, 26 Aug 2004 16:23:13 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: [Ietf-calsify] Event class
Cc: 

Hi [email-masked],

--On Thursday, August 26, 2004 3:28 PM -0400 
[email-masked] wrote:

> The property is currently being used by several iCalendar implementations.

Do any of those implementations actually do anything with that property 
other than display it to the user? e.g. do they prevent users from storing 
the event in a public calendar if its marked as PRIVATE? If they do not do 
that then I think all we need to do is clarify the current text for the 
property to explicitly state it is only for informational purposes and CUAs 
should not attempt to process the value themselves beyond alerting the user.

The alternative is to specify exactly what is expected to happen when a CUA 
receives a component with a class property. e.g. if its set to PRIVATE then 
the CUA MUST ensure that only the recipient can access the event when it is 
saved to the local/remote calendar store. That means clearly specifying the 
meaning of PUBLIC/PRIVATE/CONFIDENTIAL etc.

Perhaps people can explain exactly what there implementations currently do 
with CLASS. Maybe its come up in interops?

-- 
Cyrus Daboo

To: [email-masked]
Subject: RE: [Ietf-calsify] Event class
From: [email-masked]
Date: Thu, 26 Aug 2004 15:28:19 -0400

This is a multi-part message in MIME format...

--=_alternative 006AD86F85256EFC_=
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

I still disagree. 
The property is currently being used by several iCalendar implementations.
It has nothing to do with general access rights on recipients calendar 
store.
The Class of private says the sender prefers this information to remain 
private.  If information is not sent than receiver has no option of 
complying.

Satya Vempati <[email-masked]> 
Sent by: [email-masked]
08/26/2004 02:26 PM

To
Bernard Desruisseaux <[email-masked]>, 
[email-masked]
cc

Subject
RE: [Ietf-calsify] Event class

If we cannot clearly define the semantics of CLASS, or deem it to be 
merely informative, it may be best to remove it from the spec.

-----Original Message-----
From: [email-masked] 
[mailto:[email-masked]] On Behalf Of Bernard 
Desruisseaux
Sent: Thursday, August 26, 2004 8:24 AM
To: [email-masked]
Subject: Re: [Ietf-calsify] Event class

Satya Vempati wrote:

> Another area in need of simplification/better explanation is the event 
> class: PUBLIC/PRIVATE/CONFIDENTIAL.
> 
> The spec does not clearly define what each value means.

I don't think iCalendar needs to define the semantic of the different 
_access classifications_.

Remember that iCalendar doesn't define an _access control_ model.

iCalendar allow users to specify the access classification of their 
calendar objects. The semantic of the different access classifications 
could either be defined system wide on a calendar store, or on a per user 
basis (better).

For instance, a calendar store could allow me, through its access control 
model, to specify which users are allowed to view/modify which properties 
of calendar objects based on their classification.
Example:

  - User A is allowed to view all the properties of my PUBLIC
    calendar objects.

  - User A is allowed to view the DTSTART and DTEND of my
    CONFIDENTIAL calendar objects.

  - User A is not allowed to view my PRIVATE calendar objects.

I do understand that if you receive an iTIP message with the CLASS 
property set you can't do much about it. But then, is that an issue? It's 
questionable whether the originator should set this property. At best, the 
recipient should view the CLASS property as informative.

So far, no interoperability issue have been raised with the CLASS 
property. How could it be? There is no semantic defined! :-)

Cheers,
Bernard

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

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

--=_alternative 006AD86F85256EFC_=--

Date: Thu, 26 Aug 2004 11:26:45 -0700
From: Satya Vempati <[email-masked]>
Subject: RE: [Ietf-calsify] Event class
To: Bernard Desruisseaux <[email-masked]>, [email-masked]
Cc: 

If we cannot clearly define the semantics of CLASS, or deem it to be merely informative, it may be best to remove it from the spec.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Desruisseaux
Sent: Thursday, August 26, 2004 8:24 AM
To: [email-masked]
Subject: Re: [Ietf-calsify] Event class

Satya Vempati wrote:

> Another area in need of simplification/better explanation is the event 
> class: PUBLIC/PRIVATE/CONFIDENTIAL.
> 
> The spec does not clearly define what each value means.

I don't think iCalendar needs to define the semantic of the different _access classifications_.

Remember that iCalendar doesn't define an _access control_ model.

iCalendar allow users to specify the access classification of their calendar objects. The semantic of the different access classifications could either be defined system wide on a calendar store, or on a per user basis (better).

For instance, a calendar store could allow me, through its access control model, to specify which users are allowed to view/modify which properties of calendar objects based on their classification.
Example:

  - User A is allowed to view all the properties of my PUBLIC
    calendar objects.

  - User A is allowed to view the DTSTART and DTEND of my
    CONFIDENTIAL calendar objects.

  - User A is not allowed to view my PRIVATE calendar objects.

I do understand that if you receive an iTIP message with the CLASS property set you can't do much about it. But then, is that an issue? It's questionable whether the originator should set this property. At best, the recipient should view the CLASS property as informative.

So far, no interoperability issue have been raised with the CLASS property. How could it be? There is no semantic defined! :-)

Cheers,
Bernard

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

Date: Thu, 26 Aug 2004 14:18:01 -0400
From: Bernard Desruisseaux <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Event class

Harrie Hazewinkel wrote:

> Bernard Desruisseaux wrote:
> 
>> Remember that iCalendar doesn't define an _access control_ model.
> 
> 
> True, but it has the CLASS-property. So the statement of
> "doesn't" is not completely right. It depends on how you define it.
> Only CLASS is a very rough ACM.

iCalendar specifies a data representation. It doesn't say anything
about "accessing" data, let alone about "controlling" its access.

An access control model should allow you to specify "who" is
granted or denied which "privilege" on "what". CLASS is only
useful for the "what".

> We (here at I.Net) have implemented a CAP server with ACL for
> as well inidvidual users as with groups.
> Your example speaks only of 'viewing' data, but how about modifying
> and/or replying(accepting) an invitation. The client needs to know some
> information about that. Of course, you may say that is a CAP only issue,
> but then again the information must be conveyed in combination with
> the VEVENT.

Here's an example for modify:

- User B (my assistant) is allowed to modify my PUBLIC and CONFIDENTIAL
   calendar objects.

- User B (my assistant) is not allowed to modify my PRIVATE calendar
   objects.

About replying:

I think you should always have the right to reply to an invitation! :-)
Whether somebody else is granted the right to reply to an invitation on
your behalf is indeed more tricky. Would you base the ACE that grant or
deny the right to reply to invitation on the value of the CLASS property
set by the originator (i.e., organizer)?  Hummm... It would probably be
safer to discard the received CLASS and to specify an ACE for
unspecified CLASS (e.g., deny when in doubt).

> 
> In the end we have custom properties for this, since we are also in the
> luck we have the client side. On top of that our CAP server makes sure 
> that every user receiving a VEVENT gets only those properties he/she may
> view. For instance, if a user may only see DTSTART/DTEND it only sends
> those properties (you should not trust the final client to filter them).

Would you mind sharing your custom properties?

> 
> The class property is only a mean to provide a 'rough' access control by 
> the originator.

Sorry to insist but CLASS specifies classification not control.

Cheers,
Bernard

Date: Thu, 26 Aug 2004 17:52:27 +0200
From: Harrie Hazewinkel <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>
Subject: Re: [Ietf-calsify] Event class
Cc: [email-masked]

Bernard Desruisseaux wrote:
> Satya Vempati wrote:
> 
>> Another area in need of simplification/better explanation is the
>> event class: PUBLIC/PRIVATE/CONFIDENTIAL.
>>
>> The spec does not clearly define what each value means.
> 
> 
> I don't think iCalendar needs to define the semantic of the different
> _access classifications_.
> 
> Remember that iCalendar doesn't define an _access control_ model.

True, but it has the CLASS-property. So the statement of
"doesn't" is not completely right. It depends on how you define it.
Only CLASS is a very rough ACM.

> 
> iCalendar allow users to specify the access classification of their
> calendar objects. The semantic of the different access classifications
> could either be defined system wide on a calendar store, or on a per
> user basis (better).
> 
> For instance, a calendar store could allow me, through its access
> control model, to specify which users are allowed to view/modify
> which properties of calendar objects based on their classification.
> Example:
> 
>  - User A is allowed to view all the properties of my PUBLIC
>    calendar objects.
> 
>  - User A is allowed to view the DTSTART and DTEND of my
>    CONFIDENTIAL calendar objects.
> 
>  - User A is not allowed to view my PRIVATE calendar objects.
> 
> I do understand that if you receive an iTIP message with the CLASS
> property set you can't do much about it. But then, is that an issue?
> It's questionable whether the originator should set this property.
> At best, the recipient should view the CLASS property as informative.

We (here at I.Net) have implemented a CAP server with ACL for
as well inidvidual users as with groups.
Your example speaks only of 'viewing' data, but how about modifying
and/or replying(accepting) an invitation. The client needs to know some
information about that. Of course, you may say that is a CAP only issue,
but then again the information must be conveyed in combination with
the VEVENT.

In the end we have custom properties for this, since we are also in the
luck we have the client side. On top of that our CAP server makes sure 
that every user receiving a VEVENT gets only those properties he/she may
view. For instance, if a user may only see DTSTART/DTEND it only sends
those properties (you should not trust the final client to filter them).

The class property is only a mean to provide a 'rough' access control by 
the originator.

> 
> So far, no interoperability issue have been raised with the CLASS
> property. How could it be? There is no semantic defined! :-)

Or every one just accepts the CLASS property as informative or
ignores it in the application/client.

Harrie

Date: Thu, 26 Aug 2004 11:23:46 -0400
From: Bernard Desruisseaux <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Event class

Satya Vempati wrote:

> Another area in need of simplification/better explanation is the
> event class: PUBLIC/PRIVATE/CONFIDENTIAL.
> 
> The spec does not clearly define what each value means.

I don't think iCalendar needs to define the semantic of the different
_access classifications_.

Remember that iCalendar doesn't define an _access control_ model.

iCalendar allow users to specify the access classification of their
calendar objects. The semantic of the different access classifications
could either be defined system wide on a calendar store, or on a per
user basis (better).

For instance, a calendar store could allow me, through its access
control model, to specify which users are allowed to view/modify
which properties of calendar objects based on their classification.
Example:

  - User A is allowed to view all the properties of my PUBLIC
    calendar objects.

  - User A is allowed to view the DTSTART and DTEND of my
    CONFIDENTIAL calendar objects.

  - User A is not allowed to view my PRIVATE calendar objects.

I do understand that if you receive an iTIP message with the CLASS
property set you can't do much about it. But then, is that an issue?
It's questionable whether the originator should set this property.
At best, the recipient should view the CLASS property as informative.

So far, no interoperability issue have been raised with the CLASS
property. How could it be? There is no semantic defined! :-)

Cheers,
Bernard

To: [email-masked]
Subject: Re: [Ietf-calsify] Event class
From: [email-masked]
Date: Thu, 26 Aug 2004 10:50:31 -0400

This is a multi-part message in MIME format...

--=_alternative 0051697E85256EFC_=
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

This should be sent as an if program can honor than do it.  If you don't 
send the info than there is no possibility of honoring this information.

Cyrus Daboo <[email-masked]> 
Sent by: [email-masked]
08/25/2004 07:16 PM

To
Nathaniel Borenstein <[email-masked]>, [email-masked]
cc

Subject
Re: [Ietf-calsify] Event class

Hi Nathaniel,

--On Wednesday, August 25, 2004 6:21 PM -0400 Nathaniel Borenstein 
<[email-masked]> wrote:

> Cameron's valiant attempt to define the PRIVATE/CONFIDENTIAL divide made
> me wonder if we aren't trying to standardize the snowflake.  The
> definitions of such categories (and the number of categories needed)
> could be as unique as our users.
>
> Or to put it another way, defining a tripartite value of
> PRIVATE/CONFIDENTIAL/PUBLIC is ultimately just a [lame] attempt to
> provide access control.  A pointer towards an access list (and a
> default/fallback semantics of PUBLIC) might be both simpler and more
> useful.  -- Nathaniel

One choice here might be to remove all concept of access control from the 
data model (iCal) and instead only have that in the access protocol. That 
avoids the need to invent properties to express arbitrary access control 
and trust relationships which cannot be rigorously enforced.

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

--=_alternative 0051697E85256EFC_=--

Date: Thu, 26 Aug 2004 00:22:33 -0400
To: [email-masked]
From: [email-masked]
Subject: [Ietf-calsify] Aiding the process (I hope)

--=====================_235337315==_
Content-Type: text/plain; charset="us-ascii"; format=flowed

In an effort to get a handle on things, I've built this file (attached) to 
document the major elements of RCF2445/6/7 and CAP-13. It's in XML, because 
I thought A) that I might be able to do things with it later, and B) people 
who are more adept at XML than I might find ways to work with it.
Each line in the file contains an "Element", with a name,  the type, a 
description of sorts, the "rfc" where it is found (or CAP13), and the 
section of that document (the file is more descriptive than I am being at 
this late hour!).  The description is not detailed - the RFCs exist for 
that. This file is to help get an idea of what pieces are there, to guide 
the simplification process.

I'm about to be out of touch for ten days after Friday,  it ought to be 
interesting to read the mail when I get back.

Tim Hare
Interested Bystander, Non-Inc. 
--=====================_235337315==_
Content-Type: application/xml; name="elements.xml"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="elements.xml"

--=====================_235337315==_--

Content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify] iMip and Mixing content
Date: Wed, 25 Aug 2004 17:36:57 -0700
From: "Cameron Stillion" <[email-masked]>
To: "Nathaniel Borenstein" <[email-masked]>
Cc: [email-masked]

Good point.  I was not suggesting that we could or should avoid
arbitrary MIME structures.  Attachments in general will be structured in
whatever way the client will choose.  

Perhaps I am pushing iMip beyond it's intended purpose, but most clients
that send/receive calendars will want to attribute meaning to certain
MIME structures - and association to a particular user action and
intended behavior.  

For example: 
	User sends a "Meeting Request".
	User sends a "Meeting Update".
	User sends a "Meeting Request Accept or Decline".
	User sends a packaged calendar representing their free/busy.
	User sends a packaged calendar representing their entire
personal calendar.

Each of these VERY COMMON scenarios in calendaring applications should
have a fairly recognizable MIME structure that the mail client can
identify and then "do the right thing".  At least, that's what I was
hoping iMip would help us define.

Thoughts?

Cameron

-----Original Message-----
From: Nathaniel Borenstein [mailto:[email-masked]] 
Sent: Wednesday, August 25, 2004 3:27 PM
To: Cameron Stillion
Cc: [email-masked]
Subject: Re: [Ietf-calsify] iMip and Mixing content

On Aug 21, 2004, at 11:42 AM, Cameron Stillion wrote:

> 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?

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

Content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify] Event class
Date: Wed, 25 Aug 2004 17:36:09 -0700
From: "Cameron Stillion" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: 

Chris has the right idea - and that also brings us closer to standard,
in my opinion.  We can simply depracate confidential and support custom
values. There are applications that currently use private and public
(Outlook in particular) and maintaining that notion will bolster
compatability.

cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Wednesday, August 25, 2004 3:18 PM
To: [email-masked]; [email-masked]
Subject: Re: [Ietf-calsify] Event class

Or maybe only define PRIVATE/PUBLIC and allow extensions to this using
X-PROPS?  This way we cover the baseline that we think everyone is
likely to want to try to use (and send) but there's still the
possibility of going beyond that...
-CS

[email-masked] wrote on 08/25/2004 06:21:55 PM:

> Cameron's valiant attempt to define the PRIVATE/CONFIDENTIAL divide 
> made me wonder if we aren't trying to standardize the snowflake.  The 
> definitions of such categories (and the number of categories needed) 
> could be as unique as our users.
>
> Or to put it another way, defining a tripartite value of 
> PRIVATE/CONFIDENTIAL/PUBLIC is ultimately just a [lame] attempt to 
> provide access control.  A pointer towards an access list (and a 
> default/fallback semantics of PUBLIC) might be both simpler and more 
> useful.  -- Nathaniel
>
> On Aug 23, 2004, at 12:55 PM, Doug Royer wrote:
>
> >
> >
> > [email-masked] wrote:
> >
> >> I believe the original intent was that a private meeting can only 
> >> be seen by the owner of the mail store.  Not by an assistant who 
> >> has access to your mail store.
> >>
> > Yes, I remember discussions where PRIVATE  were not  to be handed 
> > out to non-owners.
> >
> > The current webDav calendars have almost no access control at all. 
> > You can in many cases do an HTTP get and get the entire calendar. In

> > that model CLASS has almost no meaning and less privacy.
> >
> > However in CAP (and CalDav I hope) there is more security and the 
> > ability to enforce the better defined values.
> >
> >
> > --
> >
> > _______________________________________________
> > Ietf-calsify mailing list
> > [email-masked]
> > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

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

Date: Wed, 25 Aug 2004 17:26:38 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Event class
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Wed, 25 Aug 2004 23:26:50 -0000

This is a cryptographically signed message in MIME format.

--------------ms020609060403090400040600
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Lets add:

    7) Access control.

Nathaniel Borenstein wrote:

>
> For my part, if I have an assistant with access to my calendar, I 
> doubt that I'm *ever* going to put anything into that calendar that I 
> don't want my assistant to see, no matter how it gets labeled.  
> Without real access control, paranoia is only prudent.   :-)  -- 
> Nathaniel
>  

-- 

--------------ms020609060403090400040600
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms020609060403090400040600--

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-calsify] Event class
Date: Thu, 26 Aug 2004 01:23:17 +0200
To: [email-masked]

On Aug 26, 2004, at 1:16, Cyrus Daboo wrote:
> One choice here might be to remove all concept of access control from 
> the data model (iCal) and instead only have that in the access 
> protocol. That avoids the need to invent properties to express 
> arbitrary access control and trust relationships which cannot be 
> rigorously enforced.

I've always thought that this property is intended as an informational 
marker, not as a strict access control setting. Like a paper which has 
CONFIDENTIAL in large red letters on the background (you can still read 
it if you got it, but you know that you are not supposed to pass it to 
the competitors sales guy ...).
Personally I find it pretty useful to let the consumer know how he is 
supposed to deal with the information item he received.

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

Date: Wed, 25 Aug 2004 19:16:54 -0400
From: Cyrus Daboo <[email-masked]>
To: Nathaniel Borenstein <[email-masked]>, [email-masked]
Subject: Re: [Ietf-calsify] Event class
Cc: 

Hi Nathaniel,

--On Wednesday, August 25, 2004 6:21 PM -0400 Nathaniel Borenstein 
<[email-masked]> wrote:

> Cameron's valiant attempt to define the PRIVATE/CONFIDENTIAL divide made
> me wonder if we aren't trying to standardize the snowflake.  The
> definitions of such categories (and the number of categories needed)
> could be as unique as our users.
>
> Or to put it another way, defining a tripartite value of
> PRIVATE/CONFIDENTIAL/PUBLIC is ultimately just a [lame] attempt to
> provide access control.  A pointer towards an access list (and a
> default/fallback semantics of PUBLIC) might be both simpler and more
> useful.  -- Nathaniel

One choice here might be to remove all concept of access control from the 
data model (iCal) and instead only have that in the access protocol. That 
avoids the need to invent properties to express arbitrary access control 
and trust relationships which cannot be rigorously enforced.

-- 
Cyrus Daboo

From: Nathaniel Borenstein <[email-masked]>
Subject: Re: [Ietf-calsify] Event class
Date: Wed, 25 Aug 2004 19:09:02 -0400
To: [email-masked]
Cc: [email-masked]

So if I understand correctly you are arguing for the importance of a 
particular special case, in which the roles you envision are a single 
actor and his assistant.  I have no doubt that this is a very common 
use case, but is it so overwhelmingly predominant that it is the only 
use case that is relevant for describing access control, and thus 
deserving of "special treatment" in the standard?

For my part, if I have an assistant with access to my calendar, I doubt 
that I'm *ever* going to put anything into that calendar that I don't 
want my assistant to see, no matter how it gets labeled.  Without real 
access control, paranoia is only prudent.   :-)  -- Nathaniel

On Aug 25, 2004, at 6:40 PM, [email-masked] wrote:

> I disagree.  When this appointment is private between sender and 
> invitee
> we need to create to calendar store object to reflect this.  The 
> assistant
> should not be able to see just those items created in this fashion.  
> The
> access of assistant to calendar in general is a diffent issue.
>
>
>
>
> Nathaniel Borenstein <[email-masked]>
> Sent by: [email-masked]
> 08/25/2004 06:21 PM
>
> To
> [email-masked]
> cc
>
> Subject
> Re: [Ietf-calsify] Event class
>
>
>
>
>
>
> Cameron's valiant attempt to define the PRIVATE/CONFIDENTIAL divide
> made me wonder if we aren't trying to standardize the snowflake.  The
> definitions of such categories (and the number of categories needed)
> could be as unique as our users.
>
> Or to put it another way, defining a tripartite value of
> PRIVATE/CONFIDENTIAL/PUBLIC is ultimately just a [lame] attempt to
> provide access control.  A pointer towards an access list (and a
> default/fallback semantics of PUBLIC) might be both simpler and more
> useful.  -- Nathaniel
>
> On Aug 23, 2004, at 12:55 PM, Doug Royer wrote:
>
>>
>>
>> [email-masked] wrote:
>>
>>> I believe the original intent was that a private meeting can only be
>>> seen by the owner of the mail store.  Not by an assistant who has
>>> access to your mail store.
>>>
>> Yes, I remember discussions where PRIVATE  were not  to be handed out
>> to
>> non-owners.
>>
>> The current webDav calendars have almost no access control at all. You
>> can in many cases do an HTTP get and get the entire calendar. In that
>> model CLASS has almost no meaning and less privacy.
>>
>> However in CAP (and CalDav I hope) there is more security and
>> the ability to enforce the better defined values.
>>
>>
>> -- 
>>
>> _______________________________________________
>> Ietf-calsify mailing list
>> [email-masked]
>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-calsify] Event class
Date: Wed, 25 Aug 2004 16:06:39 -0700
To: [email-masked]
Cc: [email-masked]

If the use case involves the calendar store, then the discussion may be 
more relevant on the CalDAV or CAP discussion lists, than on iCalendar.

lisa

On Aug 25, 2004, at 3:40 PM, [email-masked] wrote:

> I disagree.  When this appointment is private between sender and 
> invitee
> we need to create to calendar store object to reflect this.  The 
> assistant
> should not be able to see just those items created in this fashion.  
> The
> access of assistant to calendar in general is a diffent issue.
>
>
>
>
> Nathaniel Borenstein <[email-masked]>
> Sent by: [email-masked]
> 08/25/2004 06:21 PM
>
> To
> [email-masked]
> cc
>
> Subject
> Re: [Ietf-calsify] Event class
>
>
>
>
>
>
> Cameron's valiant attempt to define the PRIVATE/CONFIDENTIAL divide
> made me wonder if we aren't trying to standardize the snowflake.  The
> definitions of such categories (and the number of categories needed)
> could be as unique as our users.
>
> Or to put it another way, defining a tripartite value of
> PRIVATE/CONFIDENTIAL/PUBLIC is ultimately just a [lame] attempt to
> provide access control.  A pointer towards an access list (and a
> default/fallback semantics of PUBLIC) might be both simpler and more
> useful.  -- Nathaniel
>
> On Aug 23, 2004, at 12:55 PM, Doug Royer wrote:
>
>>
>>
>> [email-masked] wrote:
>>
>>> I believe the original intent was that a private meeting can only be
>>> seen by the owner of the mail store.  Not by an assistant who has
>>> access to your mail store.
>>>
>> Yes, I remember discussions where PRIVATE  were not  to be handed out
>> to
>> non-owners.
>>
>> The current webDav calendars have almost no access control at all. You
>> can in many cases do an HTTP get and get the entire calendar. In that
>> model CLASS has almost no meaning and less privacy.
>>
>> However in CAP (and CalDav I hope) there is more security and
>> the ability to enforce the better defined values.
>>
>>
>> -- 
>>
>> _______________________________________________
>> Ietf-calsify mailing list
>> [email-masked]
>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-calsify] Simplification/levels/mandatory sets, etcetera
Date: Wed, 25 Aug 2004 16:05:19 -0700
To: Nathaniel Borenstein <[email-masked]>
Cc: [email-masked]

Having support levels is not at all like MUST vs SHOULD -- instead it's 
different groupings of MUST.  With levels defined,  there would be text 
like "A client advertising support for Level 1 MUST support VTODOs... A 
client supporting Level 2 MUST handle blah blah blah ..."  It makes for 
a limited set of different capability support selections, rather than  
unlimited variability among implementations.

The problem with levels, in iCalendar, is really that there's no way of 
finding out what level an agent supports - so there's nothing about the 
levels that helps other agents interoperate.

Lisa

On Aug 25, 2004, at 3:31 PM, Nathaniel Borenstein wrote:

> I like this way of thinking about it, but I also wonder if some of 
> this is just the difference between a MUST and a MAY...
>
> I like the idea of restructuring the documents, but I'm not sure I 
> know what they should look like.  It would be awfully nice if the 
> document set started with a 20-30 page overview document that one 
> could read first and really understand how the other parts fit 
> together.  In fact, I would posit that if we could write that first, 
> the others would be a lot easier to write.  -- Nathaniel
>
> On Aug 23, 2004, at 8:10 AM, [email-masked] wrote:
>
>>
>>
>> Would it be profitable to take the existing specs for 2445/2446/2447 
>> and have some discussion about "levels" into which various parts 
>> would go? For example (I am _not_ definitevly advocating these, this 
>> is an example off the top of my head):
>>
>> Level 0 - mandatory for simplest implementations. VEVENTS (but not 
>> all properties?), METHOD. no CAP support?, no recurrence rules. If 
>> One query supported (if any) - GET-CAPABILITY, to which it replies "I 
>> don't know nuthin' about interoperation, leave me alone".  A 
>> standalone calendaring system for one user, basically?
>>
>> Level 1 - adds VTODOs, perhaps other METHODs, iTIP/iMIP?  Exchanges 
>> lists of dates instead of recurrence rules.
>>
>> Level 2 - Adds CAP support, GET-CAPABILITY check for recurrence 
>> languages ala Nathaniel's suggestion, recurrence set exchange?
>>
>> I'm sure the levels need quite a bit of refining, but I think it 
>> might be worthwhile to sort the RFCs and their contents into bins in 
>> this way.
>>
>>
>> Tim Hare
>> Interested Bystander, Non-Inc.
>>
>>
>>
>
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

To: Nathaniel Borenstein <[email-masked]>
Subject: Re: [Ietf-calsify] iMip and Mixing content
From: [email-masked]
Date: Wed, 25 Aug 2004 18:45:23 -0400
Cc: Cameron Stillion <[email-masked]>, [email-masked], [email-masked]

This is a multi-part message in MIME format...

--=_alternative 007CE64685256EFB_=
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

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

On Aug 21, 2004, at 11:42 AM, Cameron Stillion wrote:

> 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?

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

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

--=_alternative 007CE64685256EFB_=--

Date: Wed, 25 Aug 2004 16:44:39 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: RE : [Ietf-calsify] Simplification
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Wed, 25 Aug 2004 22:44:51 -0000

This is a cryptographically signed message in MIME format.

--------------ms080206070506080108060802
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Yes. I think the way to go is to split into several drafts (I do not 
care about the
order or priority at this time):

   1)  iCAL + VEVENT + VALARM
   2) VTODO
   3) VJOURNAL
   4) Time Zones
   5) iMIP
   6) Scheduling

Nathaniel Borenstein wrote:

> We're in violent agreement.  In particular, I haven't heard *anyone* 
> say that the iCal model or format is hopeless, but I've heard just 
> about *everyone* say that it's overly complex.  Hence my (consciously 
> extreme) default position, which is that we should get rid of every 
> feature and option that we can live without, and add nothing unless it 
> enables a larger simplification.  -- Nathaniel

-- 

--------------ms080206070506080108060802
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms080206070506080108060802--

To: [email-masked]
Subject: Re: [Ietf-calsify] Event class
From: [email-masked]
Date: Wed, 25 Aug 2004 18:40:05 -0400

This is a multi-part message in MIME format...

--=_alternative 007C69ED85256EFB_=
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

I disagree.  When this appointment is private between sender and invitee 
we need to create to calendar store object to reflect this.  The assistant 
should not be able to see just those items created in this fashion.  The 
access of assistant to calendar in general is a diffent issue.

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

To
[email-masked]
cc

Subject
Re: [Ietf-calsify] Event class

Cameron's valiant attempt to define the PRIVATE/CONFIDENTIAL divide 
made me wonder if we aren't trying to standardize the snowflake.  The 
definitions of such categories (and the number of categories needed) 
could be as unique as our users.

Or to put it another way, defining a tripartite value of 
PRIVATE/CONFIDENTIAL/PUBLIC is ultimately just a [lame] attempt to 
provide access control.  A pointer towards an access list (and a 
default/fallback semantics of PUBLIC) might be both simpler and more 
useful.  -- Nathaniel

On Aug 23, 2004, at 12:55 PM, Doug Royer wrote:

>
>
> [email-masked] wrote:
>
>> I believe the original intent was that a private meeting can only be 
>> seen by the owner of the mail store.  Not by an assistant who has 
>> access to your mail store.
>>
> Yes, I remember discussions where PRIVATE  were not  to be handed out 
> to
> non-owners.
>
> The current webDav calendars have almost no access control at all. You
> can in many cases do an HTTP get and get the entire calendar. In that
> model CLASS has almost no meaning and less privacy.
>
> However in CAP (and CalDav I hope) there is more security and
> the ability to enforce the better defined values.
>
>
> -- 
>
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

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

--=_alternative 007C69ED85256EFB_=--

From: Nathaniel Borenstein <[email-masked]>
Subject: Re: [Ietf-calsify] Simplification/levels/mandatory sets, etcetera
Date: Wed, 25 Aug 2004 18:31:21 -0400
To: [email-masked]
Cc: [email-masked]

I like this way of thinking about it, but I also wonder if some of this 
is just the difference between a MUST and a MAY...

I like the idea of restructuring the documents, but I'm not sure I know 
what they should look like.  It would be awfully nice if the document 
set started with a 20-30 page overview document that one could read 
first and really understand how the other parts fit together.  In fact, 
I would posit that if we could write that first, the others would be a 
lot easier to write.  -- Nathaniel

On Aug 23, 2004, at 8:10 AM, [email-masked] wrote:

>
>
> Would it be profitable to take the existing specs for 2445/2446/2447 
> and have some discussion about "levels" into which various parts would 
> go? For example (I am _not_ definitevly advocating these, this is an 
> example off the top of my head):
>
> Level 0 - mandatory for simplest implementations. VEVENTS (but not all 
> properties?), METHOD. no CAP support?, no recurrence rules. If One 
> query supported (if any) - GET-CAPABILITY, to which it replies "I 
> don't know nuthin' about interoperation, leave me alone".  A 
> standalone calendaring system for one user, basically?
>
> Level 1 - adds VTODOs, perhaps other METHODs, iTIP/iMIP?  Exchanges 
> lists of dates instead of recurrence rules.
>
> Level 2 - Adds CAP support, GET-CAPABILITY check for recurrence 
> languages ala Nathaniel's suggestion, recurrence set exchange?
>
> I'm sure the levels need quite a bit of refining, but I think it might 
> be worthwhile to sort the RFCs and their contents into bins in this 
> way.
>
>
> Tim Hare
> Interested Bystander, Non-Inc.
>
>
>

From: Nathaniel Borenstein <[email-masked]>
Subject: Re: [Ietf-calsify] iMip and Mixing content
Date: Wed, 25 Aug 2004 18:26:32 -0400
To: "Cameron Stillion" <[email-masked]>
Cc: [email-masked]

On Aug 21, 2004, at 11:42 AM, Cameron Stillion wrote:

> 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?

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

Subject: Re: [Ietf-calsify] Event class
To: [email-masked], [email-masked]
From: [email-masked]
Date: Wed, 25 Aug 2004 18:17:49 -0400
Cc: 

Or maybe only define PRIVATE/PUBLIC and allow extensions to this using
X-PROPS?  This way we cover the baseline that we think everyone is likely
to want to try to use (and send) but there's still the possibility of going
beyond that...
-CS

[email-masked] wrote on 08/25/2004 06:21:55 PM:

> Cameron's valiant attempt to define the PRIVATE/CONFIDENTIAL divide
> made me wonder if we aren't trying to standardize the snowflake.  The
> definitions of such categories (and the number of categories needed)
> could be as unique as our users.
>
> Or to put it another way, defining a tripartite value of
> PRIVATE/CONFIDENTIAL/PUBLIC is ultimately just a [lame] attempt to
> provide access control.  A pointer towards an access list (and a
> default/fallback semantics of PUBLIC) might be both simpler and more
> useful.  -- Nathaniel
>
> On Aug 23, 2004, at 12:55 PM, Doug Royer wrote:
>
> >
> >
> > [email-masked] wrote:
> >
> >> I believe the original intent was that a private meeting can only be
> >> seen by the owner of the mail store.  Not by an assistant who has
> >> access to your mail store.
> >>
> > Yes, I remember discussions where PRIVATE  were not  to be handed out
> > to
> > non-owners.
> >
> > The current webDav calendars have almost no access control at all. You
> > can in many cases do an HTTP get and get the entire calendar. In that
> > model CLASS has almost no meaning and less privacy.
> >
> > However in CAP (and CalDav I hope) there is more security and
> > the ability to enforce the better defined values.
> >
> >
> > --
> >
> > _______________________________________________
> > Ietf-calsify mailing list
> > [email-masked]
> > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

From: Nathaniel Borenstein <[email-masked]>
Subject: Re: [Ietf-calsify] Event class
Date: Wed, 25 Aug 2004 18:21:55 -0400
To: [email-masked]

Cameron's valiant attempt to define the PRIVATE/CONFIDENTIAL divide 
made me wonder if we aren't trying to standardize the snowflake.  The 
definitions of such categories (and the number of categories needed) 
could be as unique as our users.

Or to put it another way, defining a tripartite value of 
PRIVATE/CONFIDENTIAL/PUBLIC is ultimately just a [lame] attempt to 
provide access control.  A pointer towards an access list (and a 
default/fallback semantics of PUBLIC) might be both simpler and more 
useful.  -- Nathaniel

On Aug 23, 2004, at 12:55 PM, Doug Royer wrote:

>
>
> [email-masked] wrote:
>
>> I believe the original intent was that a private meeting can only be 
>> seen by the owner of the mail store.  Not by an assistant who has 
>> access to your mail store.
>>
> Yes, I remember discussions where PRIVATE  were not  to be handed out 
> to
> non-owners.
>
> The current webDav calendars have almost no access control at all. You
> can in many cases do an HTTP get and get the entire calendar. In that
> model CLASS has almost no meaning and less privacy.
>
> However in CAP (and CalDav I hope) there is more security and
> the ability to enforce the better defined values.
>
>
> -- 
>
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

From: Nathaniel Borenstein <[email-masked]>
Subject: Re: RE : [Ietf-calsify] Simplification
Date: Wed, 25 Aug 2004 18:11:43 -0400
To: "Cameron Stillion" <[email-masked]>
Cc: Libby Miller <[email-masked]>, [email-masked], [email-masked]

We're in violent agreement.  In particular, I haven't heard *anyone* 
say that the iCal model or format is hopeless, but I've heard just 
about *everyone* say that it's overly complex.  Hence my (consciously 
extreme) default position, which is that we should get rid of every 
feature and option that we can live without, and add nothing unless it 
enables a larger simplification.  -- Nathaniel

On Aug 23, 2004, at 10:08 PM, Cameron Stillion wrote:

>
> This is great.  We should definitely use the interop results to gauge 
> areas in need of clarification.
>
> I will say that the discussions that have ensued on this alias seem 
> (to me) to be very focused on specific schema elements and though we 
> have questioned their value and clarity, I have not seen any general 
> devaluing of the spec as a whole.  I believe everyone here values iCal 
> and wants to see it reach standard.  Hence the need to "cut the fat" 
> off of the current document.
>
> As Nathaniel has stated, the excitement surrounding this is a positive 
> thing, and indicative of the desire we all share to bring this 
> document out of obscurity, and into the sparkling light of "published 
> standard".
>
> cameron
>
>
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Monday, August 23, 2004 12:09 PM
> To: Libby Miller
> Cc: [email-masked]; 
> [email-masked]
> Subject: Re: RE : [Ietf-calsify] Simplification
>
> Past history can be found at both www.calsch.org and at 
> www.calconnect.org.  I will be posting the results of the recent 
> interop along with a summary of what worked and what basically is not 
> supported by any vendor.  while only two vendors were at the most 
> recent interop, several have partipated at other interops and there 
> are indeed several things that do work in iCalendar, iMIP and iTIP.  
> Therefore, we don't want to through away what is working.  If the spec 
> was not working, I would not be able to accept and reply to the 
> calandar invites I am receiving today from another vendor's products.  
> Those invites are indeed working and working well.  So, that means 
> some of the spec is working as designed.  At this last interop, I went 
> one step further and went through each and every MUST/SHOULD/MAY and 
> the NOTs as well and flagged what worked/did not work.
>  My plan to to post this detail along with past results in a summary 
> document that hopefully other vendors will reply to and say  - yes, we 
> support that and no we don't support this... etc.  That should provide 
> a foundation on which to build the simplified spec.  I expect to have 
> this document done by 9/3.  I'll put a note here on the list as to 
> where the file resides.  It will probably be a link off of 
> www.calconnect.org.
>
> [email-masked] wrote on 08/23/2004 14:19:23:
>
>>
>> On Mon, 23 Aug 2004, Arnaud Quillaud wrote:
>>
>>> Do we have the results of the latest (and previous) ical interop
>> meetings published somewhere ?
>>> If those are detailed enough, couldn't we use them as a basis to
>> determine what is working/not working, implemented/not implemented in
>> the ical/itip/imip specs ?
>>> After reading all the messages on this list, one may start to
>> think that there is nothing worth keeping in the old specs which is
>> probably quite unfair. A summary of the interop meeting might help us
>> decide how far we want to go while rewritting the calendar rfcs.
>>
>> I'd be extremely interested in this. We've done some work on testcases
>> for RDF iCalendar[1] by collecting iCalendar outputs from different
>> producers (Apple iCal, Evolution, Mozilla etc) and then converting
>> them to RDF. Any more testcases that are available that might help us
>> work out if a subset of iCalendar is in common use would be
>> tremendously useful (we often get this as a request, because our work
>> roundtrips to iCalendar from the RDF version).
>>
>> Libby
>>
>> [1] http://www.w3.org/2002/12/cal/test/
>>
>>>
>>>> -----Message d'origine-----
>>>> De : [email-masked] [mailto:ietf-calsify-
>>>> [email-masked]] De la part de Nathaniel Borenstein
>>>> Envoyé : samedi 21 août 2004 16:10 À : [email-masked] Cc :
>>>> [email-masked] Objet : Re: [Ietf-calsify]
>>>> Simplification
>>>>
>>>> Boy, you get 5 days behind and the party starts without you....
>>>> over 70 messages already!
>>>>
>>>> I have a couple of comments on this week's discussion, and I'll try
> to
>>>> separate them into the right threads for continuity.  I'll start
>>>> with my take on Tim Hare's excellent questions:
>>>>
>>>> On Aug 16, 2004, at 8:47 PM, [email-masked] wrote:
>>>>
>>>>> I'd like to start off this list by asking questions regarding
> calendar
>>>>> "simplification".
>>>>>
>>>>> 1. Is the intent to re-examine RCF2445/6/7?
>>>>
>>>> Yes.  In the light of six years of implementation experience, I
> believe
>>>> that it is time to rewrite those RFC's, simplifying and correcting
>>>> them, and clarifying the requirements for a "minimal" or 
>>>> "conformant"
>>>> ical implementation.
>>>>
>>>> In particular, I think that in addition to the substantive changes
>>>> we have been and are discussing, the RFC's should be restructured,
>>>> with optional features described in separate documents wherever 
>>>> possible.
>>>>
>>>>> 2. Is the intent to make implementation simpler?
>>>>
>>>> Yes, certainly at least the "minimum implementation" can be
> simplified
>>>> greatly.  I am going into this -- as I would encourage everyone to
>>>> do
>>>> -- with the hypothesis that there is nothing wrong with iCal that
> can't
>>>> be fixed by making it simpler.  That may be proved wrong, but let's
>>>> make adding features a last resort.  Once the base specs work, we
>>>> can add optional features till the cows come home.  As a (partially
> baked)
>>>> example of how we might do this, see my upcoming message on
> "Mandatory
>>>> Sets, Optional Rules".
>>>>
>>>>> 3. Is the intent to make use simpler (may conflict with #2).
>>>>
>>>> Yes.  While I agree that it may conflict, I suspect that it rarely
>>>> will.  (For an example of this, see my upcoming message about Sets
>>>> &
>>>> Rules.)
>>>>
>>>>> 4. Is the intent to make implementation more wide-spread?
>>>>
>>>> Oh, yes.  But indirectly -- that is, we're clearly working on the
>>>> implicit hypothesis that problems with the spec have been a major
>>>> barrier to adoption.  So we're here to fix the spec, not to
>>>> generate
> PR
>>>> to encourage implementation.
>>>>
>>>>> 5. Is the intent to make inter-operation better?
>>>>
>>>> The intent, in my mind, is to make inter-operation *possible*
>>>> beyond
> a
>>>> few rather simple cases.
>>>>
>>>>> 6. What are the perceived issues with the current RFCs?
>>>>
>>>> There's probably need for me to answer this one, as the discussion
>>>> is well under way.  But the following are my primary issues:
>>>>
>>>> -- The specs are too complex for most implementors.
>>>>
>>>> -- The specs include many features that have been ignored and are 
>>>> therefore untested.
>>>>
>>>> -- The specs retain several ambiguities, particularly around
> recurrence
>>>> rules.
>>>>
>>>> I'm really gratified to see the enthusiasm with which this
>>>> discussion has begun.  Now let's try to simplify some more.  --
>>>> Nathaniel
>>>>
>>>> _______________________________________________
>>>> Ietf-calsify mailing list
>>>> [email-masked]
>>>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>>>
>>>
>>> _______________________________________________
>>> Ietf-calsify mailing list
>>> [email-masked]
>>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>>> _______________________________________________
>> Ietf-calsify mailing list
>> [email-masked]
>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
>

Content-class: urn:content-classes:message
Subject: RE: RE : [Ietf-calsify] Simplification
Date: Mon, 23 Aug 2004 19:08:29 -0700
From: "Cameron Stillion" <[email-masked]>
To: <[email-masked]>, "Libby Miller" <[email-masked]>
Cc: [email-masked], [email-masked]

This is great.  We should definitely use the interop results to gauge areas in need of clarification.

I will say that the discussions that have ensued on this alias seem (to me) to be very focused on specific schema elements and though we have questioned their value and clarity, I have not seen any general devaluing of the spec as a whole.  I believe everyone here values iCal and wants to see it reach standard.  Hence the need to "cut the fat" off of the current document.

As Nathaniel has stated, the excitement surrounding this is a positive thing, and indicative of the desire we all share to bring this document out of obscurity, and into the sparkling light of "published standard". 

cameron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, August 23, 2004 12:09 PM
To: Libby Miller
Cc: [email-masked]; [email-masked]
Subject: Re: RE : [Ietf-calsify] Simplification

Past history can be found at both www.calsch.org and at www.calconnect.org.  I will be posting the results of the recent interop along with a summary of what worked and what basically is not supported by any vendor.  while only two vendors were at the most recent interop, several have partipated at other interops and there are indeed several things that do work in iCalendar, iMIP and iTIP.  Therefore, we don't want to through away what is working.  If the spec was not working, I would not be able to accept and reply to the calandar invites I am receiving today from another vendor's products.  Those invites are indeed working and working well.  So, that means some of the spec is working as designed.  At this last interop, I went one step further and went through each and every MUST/SHOULD/MAY and the NOTs as well and flagged what worked/did not work. 
 My plan to to post this detail along with past results in a summary document that hopefully other vendors will reply to and say  - yes, we support that and no we don't support this... etc.  That should provide a foundation on which to build the simplified spec.  I expect to have this document done by 9/3.  I'll put a note here on the list as to where the file resides.  It will probably be a link off of www.calconnect.org.

[email-masked] wrote on 08/23/2004 14:19:23:

> 
> On Mon, 23 Aug 2004, Arnaud Quillaud wrote:
> 
> > Do we have the results of the latest (and previous) ical interop
> meetings published somewhere ?
> > If those are detailed enough, couldn't we use them as a basis to
> determine what is working/not working, implemented/not implemented in 
> the ical/itip/imip specs ?
> > After reading all the messages on this list, one may start to
> think that there is nothing worth keeping in the old specs which is 
> probably quite unfair. A summary of the interop meeting might help us 
> decide how far we want to go while rewritting the calendar rfcs.
> 
> I'd be extremely interested in this. We've done some work on testcases 
> for RDF iCalendar[1] by collecting iCalendar outputs from different 
> producers (Apple iCal, Evolution, Mozilla etc) and then converting 
> them to RDF. Any more testcases that are available that might help us 
> work out if a subset of iCalendar is in common use would be 
> tremendously useful (we often get this as a request, because our work 
> roundtrips to iCalendar from the RDF version).
> 
> Libby
> 
> [1] http://www.w3.org/2002/12/cal/test/
> 
> >
> >> -----Message d'origine-----
> >> De : [email-masked] [mailto:ietf-calsify- 
> >> [email-masked]] De la part de Nathaniel Borenstein 
> >> Envoyé : samedi 21 août 2004 16:10 À : [email-masked] Cc : 
> >> [email-masked] Objet : Re: [Ietf-calsify] 
> >> Simplification
> >>
> >> Boy, you get 5 days behind and the party starts without you....  
> >> over 70 messages already!
> >>
> >> I have a couple of comments on this week's discussion, and I'll try
to
> >> separate them into the right threads for continuity.  I'll start 
> >> with my take on Tim Hare's excellent questions:
> >>
> >> On Aug 16, 2004, at 8:47 PM, [email-masked] wrote:
> >>
> >>> I'd like to start off this list by asking questions regarding
calendar
> >>> "simplification".
> >>>
> >>> 1. Is the intent to re-examine RCF2445/6/7?
> >>
> >> Yes.  In the light of six years of implementation experience, I
believe
> >> that it is time to rewrite those RFC's, simplifying and correcting 
> >> them, and clarifying the requirements for a "minimal" or "conformant"
> >> ical implementation.
> >>
> >> In particular, I think that in addition to the substantive changes 
> >> we have been and are discussing, the RFC's should be restructured, 
> >> with optional features described in separate documents wherever possible.
> >>
> >>> 2. Is the intent to make implementation simpler?
> >>
> >> Yes, certainly at least the "minimum implementation" can be
simplified
> >> greatly.  I am going into this -- as I would encourage everyone to 
> >> do
> >> -- with the hypothesis that there is nothing wrong with iCal that
can't
> >> be fixed by making it simpler.  That may be proved wrong, but let's 
> >> make adding features a last resort.  Once the base specs work, we 
> >> can add optional features till the cows come home.  As a (partially
baked)
> >> example of how we might do this, see my upcoming message on
"Mandatory
> >> Sets, Optional Rules".
> >>
> >>> 3. Is the intent to make use simpler (may conflict with #2).
> >>
> >> Yes.  While I agree that it may conflict, I suspect that it rarely 
> >> will.  (For an example of this, see my upcoming message about Sets 
> >> &
> >> Rules.)
> >>
> >>> 4. Is the intent to make implementation more wide-spread?
> >>
> >> Oh, yes.  But indirectly -- that is, we're clearly working on the 
> >> implicit hypothesis that problems with the spec have been a major 
> >> barrier to adoption.  So we're here to fix the spec, not to 
> >> generate
PR
> >> to encourage implementation.
> >>
> >>> 5. Is the intent to make inter-operation better?
> >>
> >> The intent, in my mind, is to make inter-operation *possible* 
> >> beyond
a
> >> few rather simple cases.
> >>
> >>> 6. What are the perceived issues with the current RFCs?
> >>
> >> There's probably need for me to answer this one, as the discussion 
> >> is well under way.  But the following are my primary issues:
> >>
> >> -- The specs are too complex for most implementors.
> >>
> >> -- The specs include many features that have been ignored and are 
> >> therefore untested.
> >>
> >> -- The specs retain several ambiguities, particularly around
recurrence
> >> rules.
> >>
> >> I'm really gratified to see the enthusiasm with which this 
> >> discussion has begun.  Now let's try to simplify some more.  -- 
> >> Nathaniel
> >>
> >> _______________________________________________
> >> Ietf-calsify mailing list
> >> [email-masked]
> >> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> >
> >
> > _______________________________________________
> > Ietf-calsify mailing list
> > [email-masked]
> > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> >_______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

To: Libby Miller <[email-masked]>
Subject: Re: RE : [Ietf-calsify] Simplification
From: [email-masked]
Date: Mon, 23 Aug 2004 15:08:53 -0400
Cc: [email-masked], [email-masked]

This is a multi-part message in MIME format...

--=_alternative 00692F4485256EF9_=
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Past history can be found at both www.calsch.org and at=20
www.calconnect.org.  I will be posting the results of the recent interop=20
along with a summary of what worked and what basically is not supported by=
=20
any vendor.  while only two vendors were at the most recent interop,=20
several have partipated at other interops and there are indeed several=20
things that do work in iCalendar, iMIP and iTIP.  Therefore, we don't want=
=20
to through away what is working.  If the spec was not working, I would not=
=20
be able to accept and reply to the calandar invites I am receiving today=20
from another vendor's products.  Those invites are indeed working and=20
working well.  So, that means some of the spec is working as designed.  At=
=20
this last interop, I went one step further and went through each and every=
=20
MUST/SHOULD/MAY and the NOTs as well and flagged what worked/did not work.=
=20
 My plan to to post this detail along with past results in a summary=20
document that hopefully other vendors will reply to and say  - yes, we=20
support that and no we don't support this... etc.  That should provide a=20
foundation on which to build the simplified spec.  I expect to have this=20
document done by 9/3.  I'll put a note here on the list as to where the=20
file resides.  It will probably be a link off of www.calconnect.org.

[email-masked] wrote on 08/23/2004 14:19:23:

>=20
> On Mon, 23 Aug 2004, Arnaud Quillaud wrote:
>=20
> > Do we have the results of the latest (and previous) ical interop=20
> meetings published somewhere ?
> > If those are detailed enough, couldn't we use them as a basis to=20
> determine what is working/not working, implemented/not implemented=20
> in the ical/itip/imip specs ?
> > After reading all the messages on this list, one may start to=20
> think that there is nothing worth keeping in the old specs which is=20
> probably quite unfair. A summary of the interop meeting might help=20
> us decide how far we want to go while rewritting the calendar rfcs.
>=20
> I'd be extremely interested in this. We've done some work on testcases=20
> for RDF iCalendar[1] by collecting iCalendar outputs from different=20
> producers (Apple iCal, Evolution, Mozilla etc) and then converting them=
=20
> to RDF. Any more testcases that are available that might help us work=20
> out if a subset of iCalendar is in common use would be tremendously=20
> useful (we often get this as a request, because our work roundtrips to=20
> iCalendar from the RDF version).
>=20
> Libby
>=20
> [1] http://www.w3.org/2002/12/cal/test/
>=20
> >
> >> -----Message d'origine-----
> >> De : [email-masked] [mailto:ietf-calsify-
> >> [email-masked]] De la part de Nathaniel Borenstein
> >> Envoy=E9 : samedi 21 ao=FBt 2004 16:10
> >> =C0 : [email-masked]
> >> Cc : [email-masked]
> >> Objet : Re: [Ietf-calsify] Simplification
> >>
> >> Boy, you get 5 days behind and the party starts without you....  over
> >> 70 messages already!
> >>
> >> I have a couple of comments on this week's discussion, and I'll try=20
to
> >> separate them into the right threads for continuity.  I'll start with
> >> my take on Tim Hare's excellent questions:
> >>
> >> On Aug 16, 2004, at 8:47 PM, [email-masked] wrote:
> >>
> >>> I'd like to start off this list by asking questions regarding=20
calendar
> >>> "simplification".
> >>>
> >>> 1. Is the intent to re-examine RCF2445/6/7?
> >>
> >> Yes.  In the light of six years of implementation experience, I=20
believe
> >> that it is time to rewrite those RFC's, simplifying and correcting
> >> them, and clarifying the requirements for a "minimal" or "conformant"
> >> ical implementation.
> >>
> >> In particular, I think that in addition to the substantive changes we
> >> have been and are discussing, the RFC's should be restructured, with
> >> optional features described in separate documents wherever possible.
> >>
> >>> 2. Is the intent to make implementation simpler?
> >>
> >> Yes, certainly at least the "minimum implementation" can be=20
simplified
> >> greatly.  I am going into this -- as I would encourage everyone to do
> >> -- with the hypothesis that there is nothing wrong with iCal that=20
can't
> >> be fixed by making it simpler.  That may be proved wrong, but let's
> >> make adding features a last resort.  Once the base specs work, we can
> >> add optional features till the cows come home.  As a (partially=20
baked)
> >> example of how we might do this, see my upcoming message on=20
"Mandatory
> >> Sets, Optional Rules".
> >>
> >>> 3. Is the intent to make use simpler (may conflict with #2).
> >>
> >> Yes.  While I agree that it may conflict, I suspect that it rarely
> >> will.  (For an example of this, see my upcoming message about Sets &
> >> Rules.)
> >>
> >>> 4. Is the intent to make implementation more wide-spread?
> >>
> >> Oh, yes.  But indirectly -- that is, we're clearly working on the
> >> implicit hypothesis that problems with the spec have been a major
> >> barrier to adoption.  So we're here to fix the spec, not to generate=
=20
PR
> >> to encourage implementation.
> >>
> >>> 5. Is the intent to make inter-operation better?
> >>
> >> The intent, in my mind, is to make inter-operation *possible* beyond=
=20
a
> >> few rather simple cases.
> >>
> >>> 6. What are the perceived issues with the current RFCs?
> >>
> >> There's probably need for me to answer this one, as the discussion is
> >> well under way.  But the following are my primary issues:
> >>
> >> -- The specs are too complex for most implementors.
> >>
> >> -- The specs include many features that have been ignored and are
> >> therefore untested.
> >>
> >> -- The specs retain several ambiguities, particularly around=20
recurrence
> >> rules.
> >>
> >> I'm really gratified to see the enthusiasm with which this discussion
> >> has begun.  Now let's try to simplify some more.  -- Nathaniel
> >>
> >> _______________________________________________
> >> Ietf-calsify mailing list
> >> [email-masked]
> >> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> >
> >
> > _______________________________________________
> > Ietf-calsify mailing list
> > [email-masked]
> > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> >_______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

--=_alternative 00692F4485256EF9_=--

Date: Mon, 23 Aug 2004 19:23:26 +0100 (BST)
From: Libby Miller <[email-masked]>
To: "David C. Thewlis" <[email-masked]>
Subject: Re: RE : [Ietf-calsify] Simplification
Sender: Libby Miller <[email-masked]>
Cc: [email-masked], Pat R Egen <[email-masked]>

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---559023410-684387517-1093285406=:8267
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Mon, 23 Aug 2004, David C. Thewlis wrote:

> The results of the previous interops are on the Calconnect.org website --
> go to *Past Interops*.  Results from the just-completed Interop on 29-30
> July should be available shortly -- we're waiting for some final
> information from the testers.  It will be submitted to the IETF and poste=
d
> on the Calconnect.org website as soon as it is complete, probably not thi=
s
> week but hopefully next week.  I would agree that thinking there was
> "nothing worth keeping in the old specs" would be quite unfair, to say
> nothing of terribly disruptive.
>
> Dave Thewlis
>

Thanks for this.
For us, rather than a summary, public versions of any iCalendar data=20
files would be really really useful as we're interested in which bits of=20
VEVENT (say) are supported, for example.

best wishes,

Libby

> *********** REPLY SEPARATOR  ***********
>
> On 8/23/2004 at 11:02 Arnaud Quillaud wrote:
>
>> Do we have the results of the latest (and previous) ical interop meeting=
s
>> published somewhere ?
>> If those are detailed enough, couldn't we use them as a basis to determi=
ne
>> what is working/not working, implemented/not implemented in the
>> ical/itip/imip specs ?
>> After reading all the messages on this list, one may start to think that
>> there is nothing worth keeping in the old specs which is probably quite
>> unfair. A summary of the interop meeting might help us decide how far we
>> want to go while rewritting the calendar rfcs.
>>
>> Arnaud
>>
>>> -----Message d'origine-----
>>> De=A0: [email-masked] [mailto:ietf-calsify-
>>> [email-masked]] De la part de Nathaniel Borenstein
>>> Envoy=E9=A0: samedi 21 ao=FBt 2004 16:10
>>> =C0=A0: [email-masked]
>>> Cc=A0: [email-masked]
>>> Objet=A0: Re: [Ietf-calsify] Simplification
>>>
>>> Boy, you get 5 days behind and the party starts without you....  over
>>> 70 messages already!
>>>
>>> I have a couple of comments on this week's discussion, and I'll try to
>>> separate them into the right threads for continuity.  I'll start with
>>> my take on Tim Hare's excellent questions:
>>>
>>> On Aug 16, 2004, at 8:47 PM, [email-masked] wrote:
>>>
>>>> I'd like to start off this list by asking questions regarding calendar
>>>> "simplification".
>>>>
>>>> 1. Is the intent to re-examine RCF2445/6/7?
>>>
>>> Yes.  In the light of six years of implementation experience, I believe
>>> that it is time to rewrite those RFC's, simplifying and correcting
>>> them, and clarifying the requirements for a "minimal" or "conformant"
>>> ical implementation.
>>>
>>> In particular, I think that in addition to the substantive changes we
>>> have been and are discussing, the RFC's should be restructured, with
>>> optional features described in separate documents wherever possible.
>>>
>>>> 2. Is the intent to make implementation simpler?
>>>
>>> Yes, certainly at least the "minimum implementation" can be simplified
>>> greatly.  I am going into this -- as I would encourage everyone to do
>>> -- with the hypothesis that there is nothing wrong with iCal that can't
>>> be fixed by making it simpler.  That may be proved wrong, but let's
>>> make adding features a last resort.  Once the base specs work, we can
>>> add optional features till the cows come home.  As a (partially baked)
>>> example of how we might do this, see my upcoming message on "Mandatory
>>> Sets, Optional Rules".
>>>
>>>> 3. Is the intent to make use simpler (may conflict with #2).
>>>
>>> Yes.  While I agree that it may conflict, I suspect that it rarely
>>> will.  (For an example of this, see my upcoming message about Sets &
>>> Rules.)
>>>
>>>> 4. Is the intent to make implementation more wide-spread?
>>>
>>> Oh, yes.  But indirectly -- that is, we're clearly working on the
>>> implicit hypothesis that problems with the spec have been a major
>>> barrier to adoption.  So we're here to fix the spec, not to generate PR
>>> to encourage implementation.
>>>
>>>> 5. Is the intent to make inter-operation better?
>>>
>>> The intent, in my mind, is to make inter-operation *possible* beyond a
>>> few rather simple cases.
>>>
>>>> 6. What are the perceived issues with the current RFCs?
>>>
>>> There's probably need for me to answer this one, as the discussion is
>>> well under way.  But the following are my primary issues:
>>>
>>> -- The specs are too complex for most implementors.
>>>
>>> -- The specs include many features that have been ignored and are
>>> therefore untested.
>>>
>>> -- The specs retain several ambiguities, particularly around recurrence
>>> rules.
>>>
>>> I'm really gratified to see the enthusiasm with which this discussion
>>> has begun.  Now let's try to simplify some more.  -- Nathaniel
>>>
>>> _______________________________________________
>>> Ietf-calsify mailing list
>>> [email-masked]
>>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>>
>>
>> _______________________________________________
>> Ietf-calsify mailing list
>> [email-masked]
>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
>
>
>
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
---559023410-684387517-1093285406=:8267--

Date: Mon, 23 Aug 2004 19:19:23 +0100 (BST)
From: Libby Miller <[email-masked]>
To: Arnaud Quillaud <[email-masked]>
Subject: Re: RE : [Ietf-calsify] Simplification
Sender: Libby Miller <[email-masked]>
Cc: [email-masked]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---559023410-959030623-1093285163=:8267
Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Mon, 23 Aug 2004, Arnaud Quillaud wrote:

> Do we have the results of the latest (and previous) ical interop meetings=
 published somewhere ?
> If those are detailed enough, couldn't we use them as a basis to determin=
e what is working/not working, implemented/not implemented in the ical/itip=
/imip specs ?
> After reading all the messages on this list, one may start to think that =
there is nothing worth keeping in the old specs which is probably quite unf=
air. A summary of the interop meeting might help us decide how far we want =
to go while rewritting the calendar rfcs.

I'd be extremely interested in this. We've done some work on testcases=20
for RDF iCalendar[1] by collecting iCalendar outputs from different=20
producers (Apple iCal, Evolution, Mozilla etc) and then converting them=20
to RDF. Any more testcases that are available that might help us work=20
out if a subset of iCalendar is in common use would be tremendously=20
useful (we often get this as a request, because our work roundtrips to=20
iCalendar from the RDF version).

Libby

[1] http://www.w3.org/2002/12/cal/test/

>
>> -----Message d'origine-----
>> De=A0: [email-masked] [mailto:ietf-calsify-
>> [email-masked]] De la part de Nathaniel Borenstein
>> Envoy=E9=A0: samedi 21 ao=FBt 2004 16:10
>> =C0=A0: [email-masked]
>> Cc=A0: [email-masked]
>> Objet=A0: Re: [Ietf-calsify] Simplification
>>
>> Boy, you get 5 days behind and the party starts without you....  over
>> 70 messages already!
>>
>> I have a couple of comments on this week's discussion, and I'll try to
>> separate them into the right threads for continuity.  I'll start with
>> my take on Tim Hare's excellent questions:
>>
>> On Aug 16, 2004, at 8:47 PM, [email-masked] wrote:
>>
>>> I'd like to start off this list by asking questions regarding calendar
>>> "simplification".
>>>
>>> 1. Is the intent to re-examine RCF2445/6/7?
>>
>> Yes.  In the light of six years of implementation experience, I believe
>> that it is time to rewrite those RFC's, simplifying and correcting
>> them, and clarifying the requirements for a "minimal" or "conformant"
>> ical implementation.
>>
>> In particular, I think that in addition to the substantive changes we
>> have been and are discussing, the RFC's should be restructured, with
>> optional features described in separate documents wherever possible.
>>
>>> 2. Is the intent to make implementation simpler?
>>
>> Yes, certainly at least the "minimum implementation" can be simplified
>> greatly.  I am going into this -- as I would encourage everyone to do
>> -- with the hypothesis that there is nothing wrong with iCal that can't
>> be fixed by making it simpler.  That may be proved wrong, but let's
>> make adding features a last resort.  Once the base specs work, we can
>> add optional features till the cows come home.  As a (partially baked)
>> example of how we might do this, see my upcoming message on "Mandatory
>> Sets, Optional Rules".
>>
>>> 3. Is the intent to make use simpler (may conflict with #2).
>>
>> Yes.  While I agree that it may conflict, I suspect that it rarely
>> will.  (For an example of this, see my upcoming message about Sets &
>> Rules.)
>>
>>> 4. Is the intent to make implementation more wide-spread?
>>
>> Oh, yes.  But indirectly -- that is, we're clearly working on the
>> implicit hypothesis that problems with the spec have been a major
>> barrier to adoption.  So we're here to fix the spec, not to generate PR
>> to encourage implementation.
>>
>>> 5. Is the intent to make inter-operation better?
>>
>> The intent, in my mind, is to make inter-operation *possible* beyond a
>> few rather simple cases.
>>
>>> 6. What are the perceived issues with the current RFCs?
>>
>> There's probably need for me to answer this one, as the discussion is
>> well under way.  But the following are my primary issues:
>>
>> -- The specs are too complex for most implementors.
>>
>> -- The specs include many features that have been ignored and are
>> therefore untested.
>>
>> -- The specs retain several ambiguities, particularly around recurrence
>> rules.
>>
>> I'm really gratified to see the enthusiasm with which this discussion
>> has begun.  Now let's try to simplify some more.  -- Nathaniel
>>
>> _______________________________________________
>> Ietf-calsify mailing list
>> [email-masked]
>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
>
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
---559023410-959030623-1093285163=:8267--

Date: Mon, 23 Aug 2004 11:16:34 -0700
From: "David C. Thewlis" <[email-masked]>
To: "Arnaud Quillaud" <[email-masked]>, "Nathaniel Borenstein" <[email-masked]>, "Tim Hare" <[email-masked]>
Subject: Re: RE : [Ietf-calsify] Simplification
Cc: [email-masked], Pat R Egen <[email-masked]>
Reply-To: [email-masked]

The results of the previous interops are on the Calconnect.org website --
go to *Past Interops*.  Results from the just-completed Interop on 29-30
July should be available shortly -- we're waiting for some final
information from the testers.  It will be submitted to the IETF and posted
on the Calconnect.org website as soon as it is complete, probably not this
week but hopefully next week.  I would agree that thinking there was
"nothing worth keeping in the old specs" would be quite unfair, to say
nothing of terribly disruptive.

Dave Thewlis

*********** REPLY SEPARATOR  ***********

On 8/23/2004 at 11:02 Arnaud Quillaud wrote:

>Do we have the results of the latest (and previous) ical interop meetings
>published somewhere ?
>If those are detailed enough, couldn't we use them as a basis to determine
>what is working/not working, implemented/not implemented in the
>ical/itip/imip specs ?
>After reading all the messages on this list, one may start to think that
>there is nothing worth keeping in the old specs which is probably quite
>unfair. A summary of the interop meeting might help us decide how far we
>want to go while rewritting the calendar rfcs.
>
>Arnaud
>
>> -----Message d'origine-----
>> De : [email-masked] [mailto:ietf-calsify-
>> [email-masked]] De la part de Nathaniel Borenstein
>> Envoyé : samedi 21 août 2004 16:10
>> À : [email-masked]
>> Cc : [email-masked]
>> Objet : Re: [Ietf-calsify] Simplification
>> 
>> Boy, you get 5 days behind and the party starts without you....  over
>> 70 messages already!
>> 
>> I have a couple of comments on this week's discussion, and I'll try to
>> separate them into the right threads for continuity.  I'll start with
>> my take on Tim Hare's excellent questions:
>> 
>> On Aug 16, 2004, at 8:47 PM, [email-masked] wrote:
>> 
>> > I'd like to start off this list by asking questions regarding calendar
>> > "simplification".
>> >
>> > 1. Is the intent to re-examine RCF2445/6/7?
>> 
>> Yes.  In the light of six years of implementation experience, I believe
>> that it is time to rewrite those RFC's, simplifying and correcting
>> them, and clarifying the requirements for a "minimal" or "conformant"
>> ical implementation.
>> 
>> In particular, I think that in addition to the substantive changes we
>> have been and are discussing, the RFC's should be restructured, with
>> optional features described in separate documents wherever possible.
>> 
>> > 2. Is the intent to make implementation simpler?
>> 
>> Yes, certainly at least the "minimum implementation" can be simplified
>> greatly.  I am going into this -- as I would encourage everyone to do
>> -- with the hypothesis that there is nothing wrong with iCal that can't
>> be fixed by making it simpler.  That may be proved wrong, but let's
>> make adding features a last resort.  Once the base specs work, we can
>> add optional features till the cows come home.  As a (partially baked)
>> example of how we might do this, see my upcoming message on "Mandatory
>> Sets, Optional Rules".
>> 
>> > 3. Is the intent to make use simpler (may conflict with #2).
>> 
>> Yes.  While I agree that it may conflict, I suspect that it rarely
>> will.  (For an example of this, see my upcoming message about Sets &
>> Rules.)
>> 
>> > 4. Is the intent to make implementation more wide-spread?
>> 
>> Oh, yes.  But indirectly -- that is, we're clearly working on the
>> implicit hypothesis that problems with the spec have been a major
>> barrier to adoption.  So we're here to fix the spec, not to generate PR
>> to encourage implementation.
>> 
>> > 5. Is the intent to make inter-operation better?
>> 
>> The intent, in my mind, is to make inter-operation *possible* beyond a
>> few rather simple cases.
>> 
>> > 6. What are the perceived issues with the current RFCs?
>> 
>> There's probably need for me to answer this one, as the discussion is
>> well under way.  But the following are my primary issues:
>> 
>> -- The specs are too complex for most implementors.
>> 
>> -- The specs include many features that have been ignored and are
>> therefore untested.
>> 
>> -- The specs retain several ambiguities, particularly around recurrence
>> rules.
>> 
>> I'm really gratified to see the enthusiasm with which this discussion
>> has begun.  Now let's try to simplify some more.  -- Nathaniel
>> 
>> _______________________________________________
>> Ietf-calsify mailing list
>> [email-masked]
>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
>
>_______________________________________________
>Ietf-calsify mailing list
>[email-masked]
>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Date: Mon, 23 Aug 2004 11:02:42 -0700
From: Arnaud Quillaud <[email-masked]>
Subject: RE : [Ietf-calsify] Simplification
To: Nathaniel Borenstein <[email-masked]>, [email-masked]
Cc: [email-masked]

Do we have the results of the latest (and previous) ical interop meetings published somewhere ?
If those are detailed enough, couldn't we use them as a basis to determine what is working/not working, implemented/not implemented in the ical/itip/imip specs ?
After reading all the messages on this list, one may start to think that there is nothing worth keeping in the old specs which is probably quite unfair. A summary of the interop meeting might help us decide how far we want to go while rewritting the calendar rfcs.

Arnaud

> -----Message d'origine-----
> De : [email-masked] [mailto:ietf-calsify-
> [email-masked]] De la part de Nathaniel Borenstein
> Envoyé : samedi 21 août 2004 16:10
> À : [email-masked]
> Cc : [email-masked]
> Objet : Re: [Ietf-calsify] Simplification
> 
> Boy, you get 5 days behind and the party starts without you....  over
> 70 messages already!
> 
> I have a couple of comments on this week's discussion, and I'll try to
> separate them into the right threads for continuity.  I'll start with
> my take on Tim Hare's excellent questions:
> 
> On Aug 16, 2004, at 8:47 PM, [email-masked] wrote:
> 
> > I'd like to start off this list by asking questions regarding calendar
> > "simplification".
> >
> > 1. Is the intent to re-examine RCF2445/6/7?
> 
> Yes.  In the light of six years of implementation experience, I believe
> that it is time to rewrite those RFC's, simplifying and correcting
> them, and clarifying the requirements for a "minimal" or "conformant"
> ical implementation.
> 
> In particular, I think that in addition to the substantive changes we
> have been and are discussing, the RFC's should be restructured, with
> optional features described in separate documents wherever possible.
> 
> > 2. Is the intent to make implementation simpler?
> 
> Yes, certainly at least the "minimum implementation" can be simplified
> greatly.  I am going into this -- as I would encourage everyone to do
> -- with the hypothesis that there is nothing wrong with iCal that can't
> be fixed by making it simpler.  That may be proved wrong, but let's
> make adding features a last resort.  Once the base specs work, we can
> add optional features till the cows come home.  As a (partially baked)
> example of how we might do this, see my upcoming message on "Mandatory
> Sets, Optional Rules".
> 
> > 3. Is the intent to make use simpler (may conflict with #2).
> 
> Yes.  While I agree that it may conflict, I suspect that it rarely
> will.  (For an example of this, see my upcoming message about Sets &
> Rules.)
> 
> > 4. Is the intent to make implementation more wide-spread?
> 
> Oh, yes.  But indirectly -- that is, we're clearly working on the
> implicit hypothesis that problems with the spec have been a major
> barrier to adoption.  So we're here to fix the spec, not to generate PR
> to encourage implementation.
> 
> > 5. Is the intent to make inter-operation better?
> 
> The intent, in my mind, is to make inter-operation *possible* beyond a
> few rather simple cases.
> 
> > 6. What are the perceived issues with the current RFCs?
> 
> There's probably need for me to answer this one, as the discussion is
> well under way.  But the following are my primary issues:
> 
> -- The specs are too complex for most implementors.
> 
> -- The specs include many features that have been ignored and are
> therefore untested.
> 
> -- The specs retain several ambiguities, particularly around recurrence
> rules.
> 
> I'm really gratified to see the enthusiasm with which this discussion
> has begun.  Now let's try to simplify some more.  -- Nathaniel
> 
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Date: Mon, 23 Aug 2004 10:55:44 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Event class
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Mon, 23 Aug 2004 16:55:56 -0000

This is a cryptographically signed message in MIME format.

--------------ms070702020002040702000809
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

[email-masked] wrote:

>I believe the original intent was that a private meeting can only be seen 
>by the owner of the mail store.  Not by an assistant who has access to 
>your mail store.
>  
>
Yes, I remember discussions where PRIVATE  were not  to be handed out to
non-owners.

The current webDav calendars have almost no access control at all. You
can in many cases do an HTTP get and get the entire calendar. In that
model CLASS has almost no meaning and less privacy.

However in CAP (and CalDav I hope) there is more security and
the ability to enforce the better defined values.

-- 

--------------ms070702020002040702000809
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms070702020002040702000809--

Date: Mon, 23 Aug 2004 12:07:43 -0400
From: Cyrus Daboo <[email-masked]>
To: Calsify <[email-masked]>
Subject: Re: [Ietf-calsify] PIM Data Types

Hi Cameron,

--On Wednesday, August 18, 2004 5:27 AM +0000 Cameron Stillion 
<[email-masked]> wrote:

> <aside: I would welcome an
> effort similar to CALCIFY for contact data once we've brought
> calendaring to a standard that we all feel pretty good about.../>

As a further aside I would also welcome a similar effort to caldav for 
vCard. i.e. being able to support personal address books (and shared 
address books) stored in webdav. This would be a replacement for IMSP and 
the (failed) ACAP protocols that we currently use for this.

-- 
Cyrus Daboo

To: [email-masked]
Subject: Re: [Ietf-calsify] Event class
From: [email-masked]
Date: Mon, 23 Aug 2004 11:03:47 -0400

This is a multi-part message in MIME format...

--=_alternative 0052A3A285256EF9_=
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

I believe the original intent was that a private meeting can only be seen 
by the owner of the mail store.  Not by an assistant who has access to 
your mail store.

Nathaniel Borenstein <[email-masked]> 
Sent by: [email-masked]
08/21/2004 07:10 PM

To
Satya Vempati <[email-masked]>
cc
[email-masked]
Subject
Re: [Ietf-calsify] Event class

On Aug 17, 2004, at 5:14 PM, Satya Vempati wrote:

> Another area in need of simplification/better explanation is the event 
> class: PUBLIC/PRIVATE/CONFIDENTIAL.
>
> The spec does not clearly define what each value means.

Yes, I'm puzzled on two levels.  First, what on Earth might have been 
intended by the difference between PRIVATE and CONFIDENTIAL -- I 
honestly don't even have a guess from reading the spec.  Second, what 
are we really asserting when we mark something PRIVATE and then send it 
around in an unencrypted email message?  The spec is actually 
explicitly ambiguous:  "Hence, the semantics of the individual access 
classifications cannot be completely defined by this memo alone."  What 
the heck *can* define them?

This isn't just a pedantic question, because presumably any 
implementation that differentiates between PUBLIC and PRIVATE is giving 
the user some kind of indication/choice about the nature of the 
message, and I rather doubt that the user expectations that might come 
from choosing "PRIVATE" are satisfied by the typical implementation, 
let alone by the results of interoperating between multiple systems.

In short, I question whether this distinction has any value at all, and 
would be interested in knowing what it really means in implementations 
that use it.  -- Nathaniel

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

--=_alternative 0052A3A285256EF9_=--

Date: Mon, 23 Aug 2004 08:10:02 -0400
To: Nathaniel Borenstein <[email-masked]>
From: [email-masked]
Subject: Re: [Ietf-calsify] Simplification/levels/mandatory sets, etcetera
Cc: [email-masked]

Would it be profitable to take the existing specs for 2445/2446/2447 and 
have some discussion about "levels" into which various parts would go? For 
example (I am _not_ definitevly advocating these, this is an example off 
the top of my head):

Level 0 - mandatory for simplest implementations. VEVENTS (but not all 
properties?), METHOD. no CAP support?, no recurrence rules. If One query 
supported (if any) - GET-CAPABILITY, to which it replies "I don't know 
nuthin' about interoperation, leave me alone".  A standalone calendaring 
system for one user, basically?

Level 1 - adds VTODOs, perhaps other METHODs, iTIP/iMIP?  Exchanges lists 
of dates instead of recurrence rules.

Level 2 - Adds CAP support, GET-CAPABILITY check for recurrence languages 
ala Nathaniel's suggestion, recurrence set exchange?

I'm sure the levels need quite a bit of refining, but I think it might be 
worthwhile to sort the RFCs and their contents into bins in this way.

Tim Hare
Interested Bystander, Non-Inc. 

Content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify] Event class
Date: Sun, 22 Aug 2004 07:58:02 -0700
From: "Cameron Stillion" <[email-masked]>
To: "Nathaniel Borenstein" <[email-masked]>, "Satya Vempati" <[email-masked]>
Cc: [email-masked]

Nathaniel,

In case you missed my reply on the subject, I suggested a definition for
each of these TYPEs.  In that message, I agreed with your conclusion
that confidential and private seem to mean the same thing.  My only
guess is that one represented personal confidentiality and the other
represented business-related confidentiality, and that the two flavors
might be filtered differently based on sophisticated ACLing.

I do think that the difference between public and private is somewhat
more clear - Outlook uses this notion to filter details of calendar
information, though it is not enforced as an access-level restriction.
It is purely client-implemented.

I do not think that this property has any real security surrounding it
in most applications.  In practice it is, as the RFC states, merely a
representation of the user's *intention*.  Correctly solving this
(privacy) concern requires digital signatures, encryption, and a
reliable PKI, not to mention some rather sophisticated semantics for
ACLing sub-schemas of the standard in question.

I think it is valuable to leave the details of this problem outside the
definition of the iCal format.  Clients and systems *can* require
cryptographically secure operations to transport iCalendars.  The fact
that they currently don't - is not necessarily a limitation of this
standard. S/MIME exists, therefore anything that can be expressed in
MIME can be transported with proper security controls applied and
transported without breaking the user's intention.

Regards,
cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Nathaniel
Borenstein
Sent: Saturday, August 21, 2004 4:11 PM
To: Satya Vempati
Cc: [email-masked]
Subject: Re: [Ietf-calsify] Event class

On Aug 17, 2004, at 5:14 PM, Satya Vempati wrote:

> Another area in need of simplification/better explanation is the event
> class: PUBLIC/PRIVATE/CONFIDENTIAL.
>
> The spec does not clearly define what each value means.

Yes, I'm puzzled on two levels.  First, what on Earth might have been
intended by the difference between PRIVATE and CONFIDENTIAL -- I
honestly don't even have a guess from reading the spec.  Second, what
are we really asserting when we mark something PRIVATE and then send it
around in an unencrypted email message?  The spec is actually explicitly
ambiguous:  "Hence, the semantics of the individual access
classifications cannot be completely defined by this memo alone."  What
the heck *can* define them?

This isn't just a pedantic question, because presumably any
implementation that differentiates between PUBLIC and PRIVATE is giving
the user some kind of indication/choice about the nature of the message,
and I rather doubt that the user expectations that might come from
choosing "PRIVATE" are satisfied by the typical implementation, let
alone by the results of interoperating between multiple systems.

In short, I question whether this distinction has any value at all, and
would be interested in knowing what it really means in implementations
that use it.  -- Nathaniel

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

From: Nathaniel Borenstein <[email-masked]>
Subject: Re: [Ietf-calsify] Event class
Date: Sat, 21 Aug 2004 19:10:47 -0400
To: Satya Vempati <[email-masked]>
Cc: [email-masked]

On Aug 17, 2004, at 5:14 PM, Satya Vempati wrote:

> Another area in need of simplification/better explanation is the event 
> class: PUBLIC/PRIVATE/CONFIDENTIAL.
>
> The spec does not clearly define what each value means.

Yes, I'm puzzled on two levels.  First, what on Earth might have been 
intended by the difference between PRIVATE and CONFIDENTIAL -- I 
honestly don't even have a guess from reading the spec.  Second, what 
are we really asserting when we mark something PRIVATE and then send it 
around in an unencrypted email message?  The spec is actually 
explicitly ambiguous:  "Hence, the semantics of the individual access 
classifications cannot be completely defined by this memo alone."  What 
the heck *can* define them?

This isn't just a pedantic question, because presumably any 
implementation that differentiates between PUBLIC and PRIVATE is giving 
the user some kind of indication/choice about the nature of the 
message, and I rather doubt that the user expectations that might come 
from choosing "PRIVATE" are satisfied by the typical implementation, 
let alone by the results of interoperating between multiple systems.

In short, I question whether this distinction has any value at all, and 
would be interested in knowing what it really means in implementations 
that use it.  -- Nathaniel

From: Nathaniel Borenstein <[email-masked]>
Subject: Re: [Ietf-calsify] Time Zones
Date: Sat, 21 Aug 2004 19:10:43 -0400
To: [email-masked]
Cc: [email-masked]

On Aug 18, 2004, at 2:16 PM, [email-masked] wrote:

> The driving issue for timezones was for repeating meetings that cross
> daylight/standard date.  The date that daylight/standard switch occurs 
> on,
> depends on the timezone of chair not the timezone of invitee.  Because 
> of
> this just sending offsets causes problems.

Note that if we took the approach I describe in my "Mandatory Sets, 
Optional Rules" message, you could do the time zone "correction" on the 
sender end, where you presumably had the right time zone information, 
and you could describe it in a "rule description language" that made 
use of time zones, thus making time zones an entirely optional feature 
for the simplest implementations.

From: Nathaniel Borenstein <[email-masked]>
Subject: Mandatory Sets, optional rules? (Was Re: [Ietf-calsify] Thoughts on some of the simplification thoughts so far)
Date: Sat, 21 Aug 2004 19:10:39 -0400
To: [email-masked]

I'd like to suggest a somewhat more nuanced view of the role of 
recurrence rules.

I suspect at this point we might all agree that the current recurrence 
rules have two rather different kinds of problems -- problems that stem 
from the recurrence rules being "too complex" (as one gets into complex 
exceptions, etc.) and problems that stem from the recurrence rules 
being "too simple" (for expressing ever-more sophisticated types of 
recurrences, including recurrences in other calendar systems).

The fact that there are problems in both directions suggests to me that 
we are dealing with two rather different kinds of requirements, and 
that we'll make better progress if we can identify them and perhaps try 
to separate them.  I think the answer is that the "user to user" 
description of a recurring event can and should be very different than 
the "server to server" representation of that event.

Obviously, in calendaring and scheduling work we often need to describe 
a "recurring" (or "multiple date") event, and we've been trying to 
express all of that with a single language.  But the fact is that we 
need such descriptions in two very different circumstances:  when 
communicating with the  user, and when communicating with other 
calendaring software.  I think our problems begin from trying to use 
the same language for both.  There is a near-infininte number of 
potential user-level abstractions (events that recur on the 
next-to-last Thursday of the month, on the first Tuesday after the 
first Monday, at the full moon, during Lent, on Jewish or Islamic 
holidays, and so on.)  Trying to encode them all in a transport-level 
standard has led us into the current situation, where we have the 
paradox of an event representation format that seems at the same time 
to be overly complex and representationally inadequate.

So lets back up a minute.

As one with a strong "KISS" instinct to completely throw away 
recurrence rules, I am nonetheless taken by an idea that I think 
started with Chris Stoner:  make the rules truly optional.  Fleshing 
the idea out a bit has taken me a while, but...

I would propose that we need to be able to exchange TWO representations 
of a recurring event -- basically sets and rules, with a requirement 
that the set always be provided, at least in asynchronous protocols.  
(A capabilities-exchange might be able to relax this requirement for 
CAP or CALDAV, but let's leave that for another message.)

Thus, when I send you a multiple event representation via email, I will 
*always* send you the event as a set of dates, and I *may* also send 
you a rule-based description of the event.  However, if I send you the 
rule-based description of the event, I *must* also send you a string 
indicating which rule description language I am using.  In other words, 
we can begin to evolve *multiple* rule-description languages.

How does that help?  Well, first of all, it reduces the minimal 
implementation -- on the receiving end, you can always ignore all rules 
if you're so inclined.  Second, it explicitly separates the two aspects 
of the problem mentioned above, and puts all the user-facing variance 
into the rules, which not every implementation needs to understand each 
language for, but still permits "consenting" calendars to preserve 
user-level semantics.  (Thus if your recipient and you both have 
calendar systems that support the "Islamic calendar rules" they can 
provide you with a shared user-level concept of "Ramadan" but if your 
recipient's system lacks that capability, it can still identify the 
days that constitute Ramadan this year.)  By making the rule language 
extensible, we gain a graceful path to gradually widening the circle of 
user-level semantics that we can represent.

Of course, the one thing that we can't properly represent this way is 
an infinitely recurring event.  While I still contend that infinitely 
recurring meetings are bad things, we can still have rule languages 
that describe them, if we augment the specification of a "set" to 
indicate, for example, that this is just the next 5 years of an 
infinite meeting, so that at least set-only implementations will know 
what kind of information they are losing.

Let me make this more tangible:  Consider a meeting that takes place 
every Thursday, forever.  Imagine that the "rule language" that I, as 
an calendar implementor, prefer is called "Unix Cron" -- i.e. you can 
specify recurring events in Unix cron format.  (NOTE:  I do not 
recommend that language, I'm simply choosing it as a very simple 
example with which many people are familiar.)  By encoding the meeting 
as the rule "* * * * 4" in the language "Unix cron" you ensure that any 
other calendar system that understands Unix cron format will get it 
exactly right.  Then you also include, in any data that you send 
(again, at least any data you send asynchronously) a list of all the 
Thursdays for the next 5 years, along with some (to be determined) 
additional syntax that says, in essence "this is an infinite meeting 
that has only been enumerated from 1/1/05 to 1/1/10."  A receiving 
system that didn't understand the "unix cron" language could still make 
a note to itself to look into this (e.g. via CAP/CALDAV/whatever) in 
July of '09.

I know that the idea of a potentially unbounded set of rule description 
languages is daunting, and I would hope the set would remain quite 
small.  But I think that this additional cost in "edge complexity" is 
more than offset by the significant reduction in complexity for a 
minimal implementation.  I look forward to other perspectives -- or in 
other words, fire away!  -- Nathaniel

From: Nathaniel Borenstein <[email-masked]>
Subject: Re: [Ietf-calsify] Simplification
Date: Sat, 21 Aug 2004 19:10:28 -0400
To: [email-masked]
Cc: [email-masked]

Boy, you get 5 days behind and the party starts without you....  over 
70 messages already!

I have a couple of comments on this week's discussion, and I'll try to 
separate them into the right threads for continuity.  I'll start with 
my take on Tim Hare's excellent questions:

On Aug 16, 2004, at 8:47 PM, [email-masked] wrote:

> I'd like to start off this list by asking questions regarding calendar 
> "simplification".
>
> 1. Is the intent to re-examine RCF2445/6/7?

Yes.  In the light of six years of implementation experience, I believe 
that it is time to rewrite those RFC's, simplifying and correcting 
them, and clarifying the requirements for a "minimal" or "conformant" 
ical implementation.

In particular, I think that in addition to the substantive changes we 
have been and are discussing, the RFC's should be restructured, with 
optional features described in separate documents wherever possible.

> 2. Is the intent to make implementation simpler?

Yes, certainly at least the "minimum implementation" can be simplified 
greatly.  I am going into this -- as I would encourage everyone to do 
-- with the hypothesis that there is nothing wrong with iCal that can't 
be fixed by making it simpler.  That may be proved wrong, but let's 
make adding features a last resort.  Once the base specs work, we can 
add optional features till the cows come home.  As a (partially baked) 
example of how we might do this, see my upcoming message on "Mandatory 
Sets, Optional Rules".

> 3. Is the intent to make use simpler (may conflict with #2).

Yes.  While I agree that it may conflict, I suspect that it rarely 
will.  (For an example of this, see my upcoming message about Sets & 
Rules.)

> 4. Is the intent to make implementation more wide-spread?

Oh, yes.  But indirectly -- that is, we're clearly working on the 
implicit hypothesis that problems with the spec have been a major 
barrier to adoption.  So we're here to fix the spec, not to generate PR 
to encourage implementation.

> 5. Is the intent to make inter-operation better?

The intent, in my mind, is to make inter-operation *possible* beyond a 
few rather simple cases.

> 6. What are the perceived issues with the current RFCs?

There's probably need for me to answer this one, as the discussion is 
well under way.  But the following are my primary issues:

-- The specs are too complex for most implementors.

-- The specs include many features that have been ignored and are 
therefore untested.

-- The specs retain several ambiguities, particularly around recurrence 
rules.

I'm really gratified to see the enthusiasm with which this discussion 
has begun.  Now let's try to simplify some more.  -- Nathaniel

Date: Sat, 21 Aug 2004 14:19:30 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] VALARM
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Sat, 21 Aug 2004 20:19:48 -0000

This is a cryptographically signed message in MIME format.

--------------ms050609060607020401030505
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Cameron Stillion wrote:

>I would like to suggest the removal of ALARM from the iCal spec.
> 
>
I disagree.

>I have yet to hear or come up with a good scenario that includes sending
>alarm information from one client to another.  Applications that have
>implemented this end up with features that are annoying and useless.
>Case in point : Mozilla imports a calendar and all of the valarms inside
>of it.  Many of them (all that are in the past) immediately go off after
>import.  The rest of the events are set to cause an alarm.  The user has
>not implied that they want to attend any of these events, but is already
>being bothered about it.
> 
>
Many do implement VALARMS correctly. In addition VALARMs are the
only way for one vendors CUA to set an alarm in another venders CS. I can't
think of how it could be done without VALARMs.

>Sending REQUEST calendars that include valarms makes little sense as
>well.  you may accept my meeting, but it's up to you when you want to be
>notified about its pending approach.  You might need to travel further
>than anyone else I send it to, so the valarm information is inherently
>specific to the client.
>

I would agree that we should specify when you should and should not 
include them.

> 
>While the alarm information is useful to store and to use for a client
>application, it seems pointless to transport.
>
It needs to be transported from the CS to and from the CUA.

> 
>Can anyone express a scenario where sending a valarm from one client to
>another makes sense?
>  
>
Client to client  - no.
Client to and from server - yes.
The ability to mix vendor A CUA with vendor B CS  and use/test/get 
alarms - yes.

-- 

--------------ms050609060607020401030505
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms050609060607020401030505--

Date: Sat, 21 Aug 2004 14:12:25 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] iMip and Mixing content
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Sat, 21 Aug 2004 20:12:39 -0000

This is a cryptographically signed message in MIME format.

--------------ms010701060808090802050003
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Cameron Stillion wrote:

>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?
>  
>
To transfer an entire calendar and scheduling queue.

>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.
>

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

>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.
>  
>
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.

-- 

--------------ms010701060808090802050003
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms010701060808090802050003--

Content-class: urn:content-classes:message
Date: Sat, 21 Aug 2004 09:30:41 -0700
From: "Cameron Stillion" <[email-masked]>
To: <[email-masked]>
Subject: [Ietf-calsify] VALARM

This is a multi-part message in MIME format...

------=_NextPartTM-000-67d7800f-9bdd-4ed5-9fd5-912798f7ede3
Content-Type: multipart/alternative;
	boundary="----------=_1093105859-28996-122"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.411 (Entity 5.404)

This is a multi-part message in MIME format...

------------=_1093105859-28996-122
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I would like to suggest the removal of VALARM from the iCal spec.
=20
I have yet to hear or come up with a good scenario that includes sending
alarm information from one client to another.  Applications that have
implemented this end up with features that are annoying and useless.
Case in point : Mozilla imports a calendar and all of the valarms inside
of it.  Many of them (all that are in the past) immediately go off after
import.  The rest of the events are set to cause an alarm.  The user has
not implied that they want to attend any of these events, but is already
being bothered about it.
=20
Sending REQUEST calendars that include valarms makes little sense as
well.  you may accept my meeting, but it's up to you when you want to be
notified about its pending approach.  You might need to travel further
than anyone else I send it to, so the valarm information is inherently
specific to the client.
=20
While the alarm information is useful to store and to use for a client
application, it seems pointless to transport.
=20
Can anyone express a scenario where sending a valarm from one client to
another makes sense?
=20
cameron

------------=_1093105859-28996-122--

------=_NextPartTM-000-67d7800f-9bdd-4ed5-9fd5-912798f7ede3--

Content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify] Event CLASS
Date: Sat, 21 Aug 2004 09:16:04 -0700
From: "Cameron Stillion" <[email-masked]>
To: "Satya Vempati" <[email-masked]>, <[email-masked]>
Cc: 

I agree.

The RFC seems to indicate (accurately) the limited use of this property
as a means of security, but as a method of indicating the intention of
the user.  I find this likely to be somewhat client-specific, but the
specification of a few clearly-defined and commonly-used values should
be valuable.

Let's take a crack at "clearly-defined" then...

PUBLIC  : visible to anyone with access to your calendar. PUBLIC events
should by default always be included in free/busy information, published
calendars, and any other means of transporting or communicating calendar
information.

PRIVATE : visible only to those you have explicitly given access to this
class of events.  PRIVATE events details are *optionally* included with
free/busy information, published calendars, and other means of
transporting or communicating calendar information. It is recommended
that private events are excluded by default. Clients should allow their
inclusion when the user overrides this behavior.
(I can imagine a client trying to be smart about this, for instance,
when you publish a calendar to someone who you have given access to your
private data... Furthermore, private information is still valuable as
free/busy information for scheduling, but the details of those events
should be considered private)

CONFIDENTIAL : visible only to those you have explicitly given access to
this class of events... 
(I'm stuck here - confidential seems very much like private to me.
Semantically, I would say that confidential feels more like a corporate
policy setting than private, which sounds more like an individual user
setting.  I'm not sure what the intention of the original creators was
here, but this is how I read it.)
Again, free/busy information on confidential events is valuable for
scheduling, but the details of those events should be subject to
whatever client-side security can be applied to 'confidential' objects.

Conceptually, I imagine that confidential access would be given to
people in the same corporate team, while private access might be given
to people in your personal inner circle of close friends and family.
There might be an intersection of the two groups as well, implying that
access to private and access to confidential are distinct and separate
settings.

camerost 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Satya
Vempati
Sent: Tuesday, August 17, 2004 2:14 PM
To: [email-masked]
Subject: [Ietf-calsify] Event class

Another area in need of simplification/better explanation is the event
class: PUBLIC/PRIVATE/CONFIDENTIAL.
 
The spec does not clearly define what each value means.

Content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify] iMip and Mixing content
Date: Sat, 21 Aug 2004 08:42:18 -0700
From: "Cameron Stillion" <[email-masked]>
To: <[email-masked]>

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?
>
>  
>

-- 

Date: Fri, 20 Aug 2004 12:57:27 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] iMip and ALTREP and ATTACH
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Fri, 20 Aug 2004 18:57:40 -0000

This is a cryptographically signed message in MIME format.

--------------ms090800060706000806020100
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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?
>
>  
>

-- 

--------------ms090800060706000806020100
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms090800060706000806020100--

Content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify] iMip and ALTREP and ATTACH
Date: Fri, 20 Aug 2004 10:56:24 -0700
From: "Cameron Stillion" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: 

Ah, I see.  :)  Forgive my impertinence earlier...

I wonder if we should extend this discussion in to the realm of iMip and
iTip, but actually we already have.  Removing the other schema elements
already impacts these standards, I see.

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?

cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Friday, August 20, 2004 9:36 AM
To: [email-masked];
[email-masked]
Subject: RE: [Ietf-calsify] ALTREP and ATTACH

I thought the iMip RFC 2447 did that.
http://www.faqs.org/rfcs/rfc2447.html

The reason I have the multipart/mixed as the outer layer is so that all
the multiplart/alternatives get assess to the attachment.

"Cameron Stillion" <[email-masked]> 
Sent by: [email-masked]
08/20/2004 12:13 PM

To
<[email-masked]>
cc

Subject
RE: [Ietf-calsify] ALTREP and ATTACH

At the very least I think the ALTREP and ATTACH methods should use
similar syntax and have equivalent representation of inline/outline
bodies/attachments. They are so very similar, after all.

Speaking of MIME and transport... Is it just me, or is it strange to mix
the standards for the standalone schema type and the MIME structure that
can be used to transport the format? Perhaps there is precedence for
this method of specification. 

I understand the need to include links to other MIME parts in the
specification for the format, but perhaps this highlights the need to
have another (perhaps informational?) RFC which details the methods used
to transport iCal and its parts via MIME. 

In the crypto world, it seems that things were done this way - one
document specifying the format in great detail, and another document to
describe how the format is transported via MIME.  Interoperability, it
seems to me, will be a serious problem without at least some word on the
MIME structure that should be used.  For example: How many iCal readers
will understand the aforementioned Lotus implementation with its
hierarchy of combined multipart/related and multipart/mixed?  Your
suggestion to use multipart/alternative only highlights the problem.  We
can all think of reasonable and completely different ways to do this. I
cringe at the possible combinations each vendor will invent to do the
same thing.  If indeed iCal is simply the import/export format as you
say, then it seems to me that specifying more formally the MIME
structure to be used in transport is equally important.

Thoughts?

cameron

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

Cameron Stillion wrote:

>The second half of this question concerns attachments.  There is a very

>direct mechanism for inlining content, but only if it is BINARY.  It 
>also has an ENCODING parameter (this time, it's in the spec) and 
>apparently, a way to refer to another "content portion" - again, 
>non-specific if this is referring to a mechanism of referencing sibling

>attachments in a MIME structure, or simply referencing something in the

>iCal itself.  Again, my assumption is that it is related to a MIME 
>structure.  But, does anyone actually generate or read this kind of 
>complex multipart/related content?
>
Yes, and it directly relates to one of your questions about VCARD.  By
referencing a URL. A URL can also be a CID URL or MID URL. They refer to
message content of a MIME message.

So in effect your can send an iCalendar object as an attachment and
include in the email other attachments that are referenced by URL in or
not in the same MIME object.

It is BINARY so that any charset data can be included. Simply decode it
and it is what ever they sent, plain text or UTF-32 or ...

> 
>My gut feeling is that these concepts are closely related and that 
>there should be very similar mechanisms for inlining or outlining 
>content, specifying format, etc. for both attachments and the body of
the event.
>And, am I the only one interested in storing HTML descriptions of 
>events?
> 
>
Why not just send multipart alternate?

iCalendar is an exchange format for exchanging calendar information.
And that format can be saved in an .ICS file. However most
implementations only use that format for import and export. As in you
read in the MIME object (including other related parts of the MIME
message) and store them any way you want. The iCalendar MIME object is
simply the way to transfer the information.

-- 

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

Date: Fri, 20 Aug 2004 10:44:41 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify]	Recommendationsfor	strippingdown	iCaltoa	manageable'standard'
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Fri, 20 Aug 2004 16:44:54 -0000

This is a cryptographically signed message in MIME format.

--------------ms060909050905020409050503
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Yes, CAP has ACLs and some implementations have ACLs that
are independent of CAP.

Cameron Stillion wrote:

>The TRANSP property, in my opinion, is inadequate.  It represents a
>subset of the free/busy states, and does not convey its intended meaning
>appropriately.  The mapping that each of us describe below shows how
>inadequate it is.  I think we are in agreement here.
>
>It does not include a "tentative" value, which would clarify when OPAQUE
>meant 'busy' and when OPAQUE meant 'tentatively busy'.  As you've said,
>clients don't know which to do, because the property is not specific
>enough.
>  
>
I mean the CUA may not know directly, it may be a CU decision.

>I'm not sure what you mean by not having permissions to find if the time
>is OPAQUE or TRANSPARENT.  Are you suggesting there are ACLs on this
>property? 
>
On the calendar, VEVENT, or property - yes it can have them.

>
>Free time does not necessarily convey useless information.  All-day
>events are typically TRANSPARENT (your anniversary does not make you
>busy all day), and often convey very useful information.
>
>The two new additions you describe *-NOCONFLICT don't make a lot of
>sense to me. The names themselves show how they are mixing meaning and
>metaphor, but that's the least of the problem.  TRANSPARENT-NOCONFLICT
>is an oddity - time that is not scheduled or booked, but that no one can
>schedule over? If no one can schedule over that time, it means I've
>booked it for another purpose, right? I don't understand it.
>
A time slot can be booked and TRANSPARENT, so it shows as free in
a VFREEBUSY request. Example: A meeting that goes from 2pm-3pm
and I will not be attending, but I want it on my calendar.
I would return this time as FREE in a VFREEBUSY

And it can be TRANSPARTENT-NOCONFLICT, as in keep the
time available for the 2pm-3pm meeting free in case I change my
mind and want to attend it and do not allow anyone to book that time slot.
I would return this time as BUSY-TENTATIVE in a VFREEBUSY

OPAQUE - Show the time as BUSY. However it may be overlapped booked.
I would return this time as BUSY in a VFREEBUSY

OPAQUE-NOCONFLICT - Show the time as BUSY and only
one VEVENT (or whatever) can use this time spot (a resource
like a conference room for example).
I would return this time as BUSY in a VFREEBUSY

>
>I guess what I'm saying is that Free/Busy information is a subset of an
>entire calendar of information.  The FBSTATE of an event can be used for
>scheduling.  
>
>BUSY: (90% commitment) I've committed my time to it.  I'm going to be
>there.
>TENTATIVE: (50% commitment) I've committed my time potentially, but not
>necessarily - I may not be in attendance, don't plan on me.
>FREE: (0% commitment) I have not committed time to this appointment. I'm
>planning on not going. I know about it, it's on my calendar, but it
>doesn't affect my schedule at all.
>  
>
There are 4 states for FBTYPE:

                    FREE
                    BUSY
                    BUSY-UNAVAILABLE
                    BUSY-TENTATIVE

>
>Currently, this information is available from VFREEBUSY, but NOT from
>events.  TRANSP is trying to be a copy of this information, but it's
>going about it oddly, and ineffectually.  They are the same concept, but
>we are representing them differently.
>  
>
The TRANSP value  is the hint used by calendar programs to generate the 
VFREEBUSY
information.

>If I have your schedule, I'll want to book a meeting with you using that
>information - without having to ask separately for free/busy information
>which is a logical subset of the calendar.  More importantly, I'll want
>to render your calendar, which means I'll need to show where your time
>is committed.  I can't do that reliably without this knowledge.
>  
>
Yes.  And I agree that you do not always need the VFREEBUSY information
with real time access.

However iMIP messages have no such access to your calendar. So they
send a request asking for your VFREEBUSY information. Your CS generates
the information and replies. With that information, then your CUA can
make an informed guess as to when to then send a METHOD:REQUEST to
your calendar.

So far CAP is the only  proposed/expermimental/draft  real time protocol 
for you
to get the schedule at this time. Currently the only  way to get the 
busy time is
to do an iTIP get VFREEBUSY request or with CAP.

-- 

--------------ms060909050905020409050503
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms060909050905020409050503--

To: [email-masked], [email-masked]
Subject: RE: [Ietf-calsify] ALTREP and ATTACH
From: [email-masked]
Date: Fri, 20 Aug 2004 12:35:42 -0400

This is a multi-part message in MIME format...

--=_alternative 005B152A85256EF6_=
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

I thought the iMip RFC 2447 did that.
http://www.faqs.org/rfcs/rfc2447.html

The reason I have the multipart/mixed as the outer layer is so that all 
the multiplart/alternatives get assess to the attachment.

"Cameron Stillion" <[email-masked]> 
Sent by: [email-masked]
08/20/2004 12:13 PM

To
<[email-masked]>
cc

Subject
RE: [Ietf-calsify] ALTREP and ATTACH

At the very least I think the ALTREP and ATTACH methods should use
similar syntax and have equivalent representation of inline/outline
bodies/attachments. They are so very similar, after all.

Speaking of MIME and transport... Is it just me, or is it strange to mix
the standards for the standalone schema type and the MIME structure that
can be used to transport the format? Perhaps there is precedence for
this method of specification. 

I understand the need to include links to other MIME parts in the
specification for the format, but perhaps this highlights the need to
have another (perhaps informational?) RFC which details the methods used
to transport iCal and its parts via MIME. 

In the crypto world, it seems that things were done this way - one
document specifying the format in great detail, and another document to
describe how the format is transported via MIME.  Interoperability, it
seems to me, will be a serious problem without at least some word on the
MIME structure that should be used.  For example: How many iCal readers
will understand the aforementioned Lotus implementation with its
hierarchy of combined multipart/related and multipart/mixed?  Your
suggestion to use multipart/alternative only highlights the problem.  We
can all think of reasonable and completely different ways to do this. I
cringe at the possible combinations each vendor will invent to do the
same thing.  If indeed iCal is simply the import/export format as you
say, then it seems to me that specifying more formally the MIME
structure to be used in transport is equally important.

Thoughts?

cameron

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

Cameron Stillion wrote:

>The second half of this question concerns attachments.  There is a very

>direct mechanism for inlining content, but only if it is BINARY.  It 
>also has an ENCODING parameter (this time, it's in the spec) and 
>apparently, a way to refer to another "content portion" - again, 
>non-specific if this is referring to a mechanism of referencing sibling

>attachments in a MIME structure, or simply referencing something in the

>iCal itself.  Again, my assumption is that it is related to a MIME 
>structure.  But, does anyone actually generate or read this kind of 
>complex multipart/related content?
>
Yes, and it directly relates to one of your questions about VCARD.  By
referencing a URL. A URL can also be a CID URL or MID URL. They refer to
message content of a MIME message.

So in effect your can send an iCalendar object as an attachment and
include in the email other attachments that are referenced by URL in or
not in the same MIME object.

It is BINARY so that any charset data can be included. Simply decode it
and it is what ever they sent, plain text or UTF-32 or ...

> 
>My gut feeling is that these concepts are closely related and that 
>there should be very similar mechanisms for inlining or outlining 
>content, specifying format, etc. for both attachments and the body of
the event.
>And, am I the only one interested in storing HTML descriptions of 
>events?
> 
>
Why not just send multipart alternate?

iCalendar is an exchange format for exchanging calendar information.
And that format can be saved in an .ICS file. However most
implementations only use that format for import and export. As in you
read in the MIME object (including other related parts of the MIME
message) and store them any way you want. The iCalendar MIME object is
simply the way to transfer the information.

-- 

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

--=_alternative 005B152A85256EF6_=--

Content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify] ALTREP and ATTACH
Date: Fri, 20 Aug 2004 09:13:59 -0700
From: "Cameron Stillion" <[email-masked]>
To: <[email-masked]>

At the very least I think the ALTREP and ATTACH methods should use
similar syntax and have equivalent representation of inline/outline
bodies/attachments. They are so very similar, after all.

Speaking of MIME and transport... Is it just me, or is it strange to mix
the standards for the standalone schema type and the MIME structure that
can be used to transport the format? Perhaps there is precedence for
this method of specification.  

I understand the need to include links to other MIME parts in the
specification for the format, but perhaps this highlights the need to
have another (perhaps informational?) RFC which details the methods used
to transport iCal and its parts via MIME.  

In the crypto world, it seems that things were done this way - one
document specifying the format in great detail, and another document to
describe how the format is transported via MIME.  Interoperability, it
seems to me, will be a serious problem without at least some word on the
MIME structure that should be used.  For example: How many iCal readers
will understand the aforementioned Lotus implementation with its
hierarchy of combined multipart/related and multipart/mixed?  Your
suggestion to use multipart/alternative only highlights the problem.  We
can all think of reasonable and completely different ways to do this. I
cringe at the possible combinations each vendor will invent to do the
same thing.  If indeed iCal is simply the import/export format as you
say, then it seems to me that specifying more formally the MIME
structure to be used in transport is equally important.

Thoughts?

cameron

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

Cameron Stillion wrote:

>The second half of this question concerns attachments.  There is a very

>direct mechanism for inlining content, but only if it is BINARY.  It 
>also has an ENCODING parameter (this time, it's in the spec) and 
>apparently, a way to refer to another "content portion" - again, 
>non-specific if this is referring to a mechanism of referencing sibling

>attachments in a MIME structure, or simply referencing something in the

>iCal itself.  Again, my assumption is that it is related to a MIME 
>structure.  But, does anyone actually generate or read this kind of 
>complex multipart/related content?
>
Yes, and it directly relates to one of your questions about VCARD.  By
referencing a URL. A URL can also be a CID URL or MID URL. They refer to
message content of a MIME message.

So in effect your can send an iCalendar object as an attachment and
include in the email other attachments that are referenced by URL in or
not in the same MIME object.

It is BINARY so that any charset data can be included. Simply decode it
and it is what ever they sent, plain text or UTF-32 or ...

> 
>My gut feeling is that these concepts are closely related and that 
>there should be very similar mechanisms for inlining or outlining 
>content, specifying format, etc. for both attachments and the body of
the event.
>And, am I the only one interested in storing HTML descriptions of 
>events?
> 
>
Why not just send multipart alternate?

iCalendar is an exchange format for exchanging calendar information.
And that format can be saved in an .ICS file. However most
implementations only use that format for import and export. As in you
read in the MIME object (including other related parts of the MIME
message) and store them any way you want. The iCalendar MIME object is
simply the way to transfer the information.

-- 

Date: Fri, 20 Aug 2004 09:52:36 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] ALTREP and ATTACH
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Fri, 20 Aug 2004 15:52:51 -0000

This is a cryptographically signed message in MIME format.

--------------ms070601090609040201080201
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Cameron Stillion wrote:

>The second half of this question concerns attachments.  There is a very
>direct mechanism for inlining content, but only if it is BINARY.  It
>also has an ENCODING parameter (this time, it's in the spec) and
>apparently, a way to refer to another "content portion" - again,
>non-specific if this is referring to a mechanism of referencing sibling
>attachments in a MIME structure, or simply referencing something in the
>iCal itself.  Again, my assumption is that it is related to a MIME
>structure.  But, does anyone actually generate or read this kind of
>complex multipart/related content?
>
Yes, and it directly relates to one of your questions about VCARD.  By
referencing a URL. A URL can also be a CID URL or MID URL. They refer
to message content of a MIME message.

So in effect your can send an iCalendar object as an attachment and
include in the email other attachments that are referenced by URL in
or not in the same MIME object.

It is BINARY so that any charset data can be included. Simply decode it
and it is what ever they sent, plain text or UTF-32 or ...

> 
>My gut feeling is that these concepts are closely related and that there
>should be very similar mechanisms for inlining or outlining content,
>specifying format, etc. for both attachments and the body of the event.
>And, am I the only one interested in storing HTML descriptions of
>events?
> 
>
Why not just send multipart alternate?

iCalendar is an exchange format for exchanging calendar information.
And that format can be saved in an .ICS file. However most implementations
only use that format for import and export. As in you read in the MIME 
object
(including other related parts of the MIME message) and store them any way
you want. The iCalendar MIME object is simply the way to transfer the 
information.

-- 

--------------ms070601090609040201080201
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms070601090609040201080201--

To: <[email-masked]>
Subject: RE: [Ietf-calsify] ALTREP and ATTACH
From: [email-masked]
Date: Fri, 20 Aug 2004 11:19:51 -0400

This is a multi-part message in MIME format...

--=_alternative 0054234A85256EF6_=
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

Message-ID: 
<[email-masked]>
From: [email-masked]
Date: Fri, 20 Aug 2004 11:08:32 -0400
Content-Type: multipart/mixed; boundary="=_mixed 005333BD85256EF6_="

--=_mixed 005333BD85256EF6_=
Content-Type: multipart/related; boundary="=_related 005333BF85256EF6_="

--=_related 005333BF85256EF6_=
Content-Type: multipart/alternative; boundary="=_alternative 
005333BF85256EF6_="

--=_alternative 005333BF85256EF6_=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

--=_alternative 005333BF85256EF6_=
Content-Type: text/html; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

(html content removed)

--=_alternative 005333BF85256EF6_=
Content-Type: text/calendar; method="REQUEST"; charset="UTF-8"

BEGIN:VCALENDAR
X-LOTUS-CHARSET:UTF-8
VERSION:2.0
PRODID:-//Lotus Development Corporation//NONSGML Notes 6.0//EN
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:Eastern
BEGIN:STANDARD
DTSTART:19501029T020000
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
RRULE:FREQ=YEARLY;BYMINUTE=0;BYHOUR=2;BYDAY=-1SU;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19500402T020000
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
RRULE:FREQ=YEARLY;BYMINUTE=0;BYHOUR=2;BYDAY=1SU;BYMONTH=4
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID="Eastern":20040829T090000
DTEND;TZID="Eastern":20040829T100000
TRANSP:OPAQUE
DTSTAMP:20040820T150832Z
SEQUENCE:0
ATTACH:CID:1__=[email-masked]
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;CN="bravo bravo/ibm";RSVP=FALSE:
 mailto:[email-masked]
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION
 ;CN="POP3 Testing/ibm";RSVP=TRUE
 :mailto:[email-masked]
CLASS:PUBLIC
DESCRIPTION;ALTREP="CID:<FFFF__=[email-masked]>":t
 here is an image below\n\n\nthere is also a vCard attachment\n
SUMMARY:sample mime structure
ORGANIZER;CN="bravo bravo/ibm"
 :mailto:[email-masked]
UID:63EDEBC01243D46185256EF60052D8F2-Lotus_Notes_Generated
X-LOTUS-BROADCAST:FALSE
X-LOTUS-UPDATE-SEQ:1
X-LOTUS-UPDATE-WISL:$S:1;$L:1;$B:1;$R:1;$E:1
X-LOTUS-NOTESVERSION:2
X-LOTUS-NOTICETYPE:I
X-LOTUS-CHILD_UID:63EDEBC01243D46185256EF60052D8F2
END:VEVENT
END:VCALENDAR

--=_alternative 005333BF85256EF6_=--
--=_related 005333BF85256EF6_=
Content-Type: image/gif; name=ecblank.gif
Content-Disposition: inline; filename=ecblank.gif
Content-ID: <2__=[email-masked]>
Content-Transfer-Encoding: base64

R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7

--=_related 005333BF85256EF6_=
Content-Type: image/gif; name=pic10487.gif
Content-Disposition: inline; filename=pic10487.gif
Content-ID: <3__=[email-masked]>
Content-Transfer-Encoding: base64

R0lGODlh+gABAID/AMDAwAAAACH5BAEAAAAALAAAAAD6AAEAAAINhI+py+0Po5y02ovzLQA7

--=_related 005333BF85256EF6_=
Content-Type: image/jpeg; name=C2822823.jpg
Content-Disposition: inline; filename=C2822823.jpg
Content-ID: <4__=[email-masked]>
Content-Transfer-Encoding: base64

(image content removed)

--=_related 005333BF85256EF6_=
Content-Type: text/html; charset=US-ASCII
Content-Disposition: inline
Content-ID: <FFFF__=[email-masked]>
Content-Transfer-Encoding: quoted-printable

<html><body><font size=3D"2">there is an image below</font><br>
<img src=3D"cid:4__=[email-masked]" width=3D=
"366" height=3D"227"><br>
there is also a vCard attachment<br>
<i>(See attached file: ransdell.vcf)</i></body></html>=

--=_related 005333BF85256EF6_=--
--=_mixed 005333BD85256EF6_=
Content-Type: application/octet-stream; name=ransdell.vcf
Content-Disposition: attachment; filename=ransdell.vcf
Content-ID: <1__=[email-masked]>
Content-Transfer-Encoding: base64

QkVHSU46VkNBUkQNClgtTE9UVVMtQ0hBUlNFVDpVVEYtOA0KVkVSU0lPTjozLjANClBST0RJRDot
Ly9Mb3R1cyBEZXZlbG9wbWVudCBDb3Jwb3JhdGlvbi8vTk9OU0dNTCBOb3RlcyA2LjAvL0VODQpG
TjpSb2JlcnQgVGhvbWFzIFJhbnNkZWxsDQpOOlJhbnNkZWxsO1JvYmVydDtUaG9tYXM7Ow0KRU1B
SUw6cm9iZXJ0X3JhbnNkZWxsQG5vdGVzZGV2LmlibS5jb20NCk9SRzpJQk0NClJFVjoyMDA0MDgy
MFQxNTA3MzhaDQpFTkQ6VkNBUkQNCg==

--=_mixed 005333BD85256EF6_=--

"Cameron Stillion" <[email-masked]> 
Sent by: [email-masked]
08/19/2004 06:41 PM

To
<[email-masked]>, <[email-masked]>
cc

Subject
RE: [Ietf-calsify] ALTREP and ATTACH

This discrepancy seems broken to me, and it seems to be very unclearly
stated in the document.  The MIME structure in particular is left to our
imagination.

Just so that I understand the Notes implementation - is this correct?

multipart/related
 |
 \_text/ical
 |
 \_text/html
 |
 \_multipart/mixed
    |
    \_ image/gif
    |
    etc...

Or am I misunderstanding you?

Cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Thursday, August 19, 2004 3:18 PM
To: [email-masked]
Subject: Re: [Ietf-calsify] ALTREP and ATTACH

Notes has implemented ALTREP  and  ATTACH features.
The ALTREP cid value points to a text/html in the same MIME stream as
the text/calendar but in a multipart/related section.
 In ATTACHMENT cid value points to a attachment in the same MIME stream
but  in a multipart/mix section.

The iCalendar spec allows the ATTACH to be encoded directly into the
iCalendar stream.  Notes code does not use that option.
I don't think the ALTREP parameter has any provisions for inserting the
image within the iCalendar data.

"Cameron Stillion" <[email-masked]> Sent by:
[email-masked]
08/19/2004 06:01 PM

To
<[email-masked]>
cc

Subject
[Ietf-calsify] ALTREP and ATTACH

Section 4.2.1 of RFC2445 contains this example:
 
Example:

     DESCRIPTION;ALTREP="CID:<[email-masked]>":Project
       XYZ Review Meeting will include the following agenda items: (a)
       Market Overview, (b) Finances, (c) Project Management

   The "ALTREP" property parameter value might point to a "text/html"
   content portion.

     Content-Type:text/html
     Content-Id:<[email-masked]>

     <html><body>
     <p><b>Project XYZ Review Meeting</b> will include the following
     agenda items:<ol><li>Market
     Overview</li><li>Finances</li><li>Project Management</li></ol></p>
     </body></html>

I haven't found any clients that actually support this, but if they did
- it isn't clear from the context of this example where the "content
portion" mentioned above actually lives.  possibility #1) Is the .ics
file contained in a multipart/related MIME portion of a message that
also contains this text/html body part?  OR - possibility #2) Is this
"content portion" actually inside of the iCal itself? The example isn't
quite clear, but I'm guessing that #1 is the answer, and the rest of
these details are simply left out.  If I'm reading this correctly, there
doesn't seem to be any means of specifying the format of the DESCRIPTION
text.  Does this mean it is limited to plain text? BioCity seems to
generate DESCRIPTIONS with ENCODING parameter and with actual inline
HTML content. I suppose clients could parse the description, discover
HTML-like tags, guess it's HTML, and do the right thing... but that
seems flimsy to me.  Shouldn't we specify the format if it is not plain
text?  What do other clients do?
 
The second half of this question concerns attachments.  There is a very
direct mechanism for inlining content, but only if it is BINARY.  It
also has an ENCODING parameter (this time, it's in the spec) and
apparently, a way to refer to another "content portion" - again,
non-specific if this is referring to a mechanism of referencing sibling
attachments in a MIME structure, or simply referencing something in the
iCal itself.  Again, my assumption is that it is related to a MIME
structure.  But, does anyone actually generate or read this kind of
complex multipart/related content?
 
My gut feeling is that these concepts are closely related and that there
should be very similar mechanisms for inlining or outlining content,
specifying format, etc. for both attachments and the body of the event.
And, am I the only one interested in storing HTML descriptions of
events?
 
cameron
 
_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

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

--=_alternative 0054234A85256EF6_=--

Content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify]	Recommendationsfor	strippingdown	iCaltoa	manageable'standard'
Date: Thu, 19 Aug 2004 17:52:01 -0700
From: "Cameron Stillion" <[email-masked]>
To: <[email-masked]>

The TRANSP property, in my opinion, is inadequate.  It represents a
subset of the free/busy states, and does not convey its intended meaning
appropriately.  The mapping that each of us describe below shows how
inadequate it is.  I think we are in agreement here.

It does not include a "tentative" value, which would clarify when OPAQUE
meant 'busy' and when OPAQUE meant 'tentatively busy'.  As you've said,
clients don't know which to do, because the property is not specific
enough.

I'm not sure what you mean by not having permissions to find if the time
is OPAQUE or TRANSPARENT.  Are you suggesting there are ACLs on this
property? 

Free time does not necessarily convey useless information.  All-day
events are typically TRANSPARENT (your anniversary does not make you
busy all day), and often convey very useful information.

The two new additions you describe *-NOCONFLICT don't make a lot of
sense to me. The names themselves show how they are mixing meaning and
metaphor, but that's the least of the problem.  TRANSPARENT-NOCONFLICT
is an oddity - time that is not scheduled or booked, but that no one can
schedule over? If no one can schedule over that time, it means I've
booked it for another purpose, right? I don't understand it.

I guess what I'm saying is that Free/Busy information is a subset of an
entire calendar of information.  The FBSTATE of an event can be used for
scheduling.  

BUSY: (90% commitment) I've committed my time to it.  I'm going to be
there.
TENTATIVE: (50% commitment) I've committed my time potentially, but not
necessarily - I may not be in attendance, don't plan on me.
FREE: (0% commitment) I have not committed time to this appointment. I'm
planning on not going. I know about it, it's on my calendar, but it
doesn't affect my schedule at all.

I have heard of other, more detailed states, but they are not quite as
compelling:

BOSS-BUSY : <BUSY++> (100% commitment) meeting with my boss. no other
appointments can trump this one.  I'll be at this meeting unless I'm in
the hospital with a broken leg.
SQUISHY-BUSY : <TENTATIVE--> (10% commitment) I'll attend this meeting
if I don't find anything better to do first.  Feel free to schedule me
over this time if it is useful to you, especially if you happen to be my
boss.

Currently, this information is available from VFREEBUSY, but NOT from
events.  TRANSP is trying to be a copy of this information, but it's
going about it oddly, and ineffectually.  They are the same concept, but
we are representing them differently.

If I have your schedule, I'll want to book a meeting with you using that
information - without having to ask separately for free/busy information
which is a logical subset of the calendar.  More importantly, I'll want
to render your calendar, which means I'll need to show where your time
is committed.  I can't do that reliably without this knowledge.

cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Doug Royer
Sent: Wednesday, August 18, 2004 6:22 PM
To: [email-masked]
Subject: Re: [Ietf-calsify] Recommendationsfor strippingdown iCaltoa
manageable'standard'

Cameron Stillion wrote:

>TRANSP does allow parameters, so perhaps we could use the FBTYPE= param

>on this property, and simply ignore the actual value of TRANSP if it 
>exists.  This allows us to fold these ideas *which are exactly the 
>same* without using two different schema elements.  Existing iCals 
>would not be broken.  New iCals would not break old parsers.  How does
that sound?

What does it add to the functionality? It would be neater, but at what
cost to compatibility? We are talking about computer read data.

>No surprise that two new TRANSP properties are being added... they are 
>communicating the same notion as FBTYPE, only TRANSP incorrectly tries 
>to imply client rendering behavior.  If you prefer using TRANSP to 
>using the (more expressive imho)  FBTYPE, then I suggest we make TRANSP

>values that represent each of these free/busy states.  It's not clear 
>to me that they match up currently:
>
>Free = transparent
>Busy = opaque
>Busy-Tentative = ?
>Busy-Unavailable = OPAQUE-NOCONFLICT
>? = TRANSPARENT-NOCONFLICT
>

Some implementations map their BUSY time to mean BOOKED time (OPAQUE
with TENTATIVE or not)

Some implementations map their BUSY  their to mean OPAQUE and not
TENTATIVE only time.

The real meaning of BUSY is - you can not book this time slot for what
ever reason.
And you might not have access to find if it is TENTATIVE, OPAQUE, or
TRANSPARENT.
Just no.

Free time is useless information as it can mean that nothing is booked. 
It does not
mean that you are allowed to book that time (1am for example).

So, perhaps we need to come up with a VFREEBUSY2 that does clearly
defined things.

>There seeme to be no way to describe tentative, and no way in VFREEBUSY

>to describe the transparent but unschedulable (? Is that any different 
>than a private booked 'busy' appointment?)
>
That's up to the user in some implementations, can not always be
automated.

A CUA that asks for VFREEBUSY information gets it so that there can be a
decision on what time are available for inviting a calendar to an
appointment.

Does it matter why you can not book the time?

>
>It's fine to have an event that takes no time, I don't have a problem 
>with that. But that isn't an all-day event, and we shouldn't assume it 
>is.
>  
>
I agree.

>I'm not trying to argue that all events require a duration - I concede 
>your point there.  Let's be clear though that our assumption in such 
>case should be a zero-time event rather than any other assumption (such

>as an all-day event)
Yes.

-- 

Content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify] ALTREP and ATTACH
Date: Thu, 19 Aug 2004 15:41:03 -0700
From: "Cameron Stillion" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: 

This discrepancy seems broken to me, and it seems to be very unclearly
stated in the document.  The MIME structure in particular is left to our
imagination.

Just so that I understand the Notes implementation - is this correct?

multipart/related
 |
 \_text/ical
 |
 \_text/html
 |
 \_multipart/mixed
    |
    \_ image/gif
    |
    etc...

Or am I misunderstanding you?

Cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Thursday, August 19, 2004 3:18 PM
To: [email-masked]
Subject: Re: [Ietf-calsify] ALTREP and ATTACH

Notes has implemented ALTREP  and  ATTACH features.
The ALTREP cid value points to a text/html in the same MIME stream as
the text/calendar but in a multipart/related section.
 In ATTACHMENT cid value points to a attachment in the same MIME stream
but  in a multipart/mix section.

The iCalendar spec allows the ATTACH to be encoded directly into the
iCalendar stream.  Notes code does not use that option.
I don't think the ALTREP parameter has any provisions for inserting the
image within the iCalendar data.

"Cameron Stillion" <[email-masked]> Sent by:
[email-masked]
08/19/2004 06:01 PM

To
<[email-masked]>
cc

Subject
[Ietf-calsify] ALTREP and ATTACH

Section 4.2.1 of RFC2445 contains this example:
 
Example:

     DESCRIPTION;ALTREP="CID:<[email-masked]>":Project
       XYZ Review Meeting will include the following agenda items: (a)
       Market Overview, (b) Finances, (c) Project Management

   The "ALTREP" property parameter value might point to a "text/html"
   content portion.

     Content-Type:text/html
     Content-Id:<[email-masked]>

     <html><body>
     <p><b>Project XYZ Review Meeting</b> will include the following
     agenda items:<ol><li>Market
     Overview</li><li>Finances</li><li>Project Management</li></ol></p>
     </body></html>

I haven't found any clients that actually support this, but if they did
- it isn't clear from the context of this example where the "content
portion" mentioned above actually lives.  possibility #1) Is the .ics
file contained in a multipart/related MIME portion of a message that
also contains this text/html body part?  OR - possibility #2) Is this
"content portion" actually inside of the iCal itself? The example isn't
quite clear, but I'm guessing that #1 is the answer, and the rest of
these details are simply left out.  If I'm reading this correctly, there
doesn't seem to be any means of specifying the format of the DESCRIPTION
text.  Does this mean it is limited to plain text? BioCity seems to
generate DESCRIPTIONS with ENCODING parameter and with actual inline
HTML content. I suppose clients could parse the description, discover
HTML-like tags, guess it's HTML, and do the right thing... but that
seems flimsy to me.  Shouldn't we specify the format if it is not plain
text?  What do other clients do?
 
The second half of this question concerns attachments.  There is a very
direct mechanism for inlining content, but only if it is BINARY.  It
also has an ENCODING parameter (this time, it's in the spec) and
apparently, a way to refer to another "content portion" - again,
non-specific if this is referring to a mechanism of referencing sibling
attachments in a MIME structure, or simply referencing something in the
iCal itself.  Again, my assumption is that it is related to a MIME
structure.  But, does anyone actually generate or read this kind of
complex multipart/related content?
 
My gut feeling is that these concepts are closely related and that there
should be very similar mechanisms for inlining or outlining content,
specifying format, etc. for both attachments and the body of the event.
And, am I the only one interested in storing HTML descriptions of
events?
 
cameron
 
_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

To: <[email-masked]>
Subject: Re: [Ietf-calsify] ALTREP and ATTACH
From: [email-masked]
Date: Thu, 19 Aug 2004 18:18:17 -0400

This is a multi-part message in MIME format...

--=_alternative 007A723F85256EF5_=
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

Notes has implemented ALTREP  and  ATTACH features.
The ALTREP cid value points to a text/html in the same MIME stream as the 
text/calendar but in a multipart/related section.
 In ATTACHMENT cid value points to a attachment in the same MIME stream 
but  in a multipart/mix section.

The iCalendar spec allows the ATTACH to be encoded directly into the 
iCalendar stream.  Notes code does not use that option.
I don't think the ALTREP parameter has any provisions for inserting the 
image within the iCalendar data.

"Cameron Stillion" <[email-masked]> 
Sent by: [email-masked]
08/19/2004 06:01 PM

To
<[email-masked]>
cc

Subject
[Ietf-calsify] ALTREP and ATTACH

Section 4.2.1 of RFC2445 contains this example:
 
Example:

     DESCRIPTION;ALTREP="CID:<[email-masked]>":Project
       XYZ Review Meeting will include the following agenda items: (a)
       Market Overview, (b) Finances, (c) Project Management

   The "ALTREP" property parameter value might point to a "text/html"
   content portion.

     Content-Type:text/html
     Content-Id:<[email-masked]>

     <html><body>
     <p><b>Project XYZ Review Meeting</b> will include the following
     agenda items:<ol><li>Market
     Overview</li><li>Finances</li><li>Project Management</li></ol></p>
     </body></html>

I haven't found any clients that actually support this, but if they did
- it isn't clear from the context of this example where the "content
portion" mentioned above actually lives.  possibility #1) Is the .ics
file contained in a multipart/related MIME portion of a message that
also contains this text/html body part?  OR - possibility #2) Is this
"content portion" actually inside of the iCal itself? The example isn't
quite clear, but I'm guessing that #1 is the answer, and the rest of
these details are simply left out.  If I'm reading this correctly, there
doesn't seem to be any means of specifying the format of the DESCRIPTION
text.  Does this mean it is limited to plain text? BioCity seems to
generate DESCRIPTIONS with ENCODING parameter and with actual inline
HTML content. I suppose clients could parse the description, discover
HTML-like tags, guess it's HTML, and do the right thing... but that
seems flimsy to me.  Shouldn't we specify the format if it is not plain
text?  What do other clients do?
 
The second half of this question concerns attachments.  There is a very
direct mechanism for inlining content, but only if it is BINARY.  It
also has an ENCODING parameter (this time, it's in the spec) and
apparently, a way to refer to another "content portion" - again,
non-specific if this is referring to a mechanism of referencing sibling
attachments in a MIME structure, or simply referencing something in the
iCal itself.  Again, my assumption is that it is related to a MIME
structure.  But, does anyone actually generate or read this kind of
complex multipart/related content?
 
My gut feeling is that these concepts are closely related and that there
should be very similar mechanisms for inlining or outlining content,
specifying format, etc. for both attachments and the body of the event.
And, am I the only one interested in storing HTML descriptions of
events?
 
cameron
 
_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

--=_alternative 007A723F85256EF5_=--

Content-class: urn:content-classes:message
Date: Thu, 19 Aug 2004 15:01:02 -0700
From: "Cameron Stillion" <[email-masked]>
To: <[email-masked]>
Subject: [Ietf-calsify] ALTREP and ATTACH

This is a multi-part message in MIME format...

------=_NextPartTM-000-4d8279d7-34e5-4c83-8665-9450aa9653fb
Content-Type: multipart/alternative; boundary="----------=_1092952958-22661-47"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.411 (Entity 5.404)

This is a multi-part message in MIME format...

------------=_1092952958-22661-47
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Section 4.2.1 of RFC2445 contains this example:
=20
Example:

     DESCRIPTION;ALTREP=3D"CID:<[email-masked]>":Project
       XYZ Review Meeting will include the following agenda items: (a)
       Market Overview, (b) Finances, (c) Project Management

   The "ALTREP" property parameter value might point to a "text/html"
   content portion.

     Content-Type:text/html
     Content-Id:<[email-masked]>

     <html><body>
     <p><b>Project XYZ Review Meeting</b> will include the following
     agenda items:<ol><li>Market
     Overview</li><li>Finances</li><li>Project Management</li></ol></p>
     </body></html>

I haven't found any clients that actually support this, but if they did
- it isn't clear from the context of this example where the "content
portion" mentioned above actually lives.  possibility #1) Is the .ics
file contained in a multipart/related MIME portion of a message that
also contains this text/html body part?  OR - possibility #2) Is this
"content portion" actually inside of the iCal itself? The example isn't
quite clear, but I'm guessing that #1 is the answer, and the rest of
these details are simply left out.  If I'm reading this correctly, there
doesn't seem to be any means of specifying the format of the DESCRIPTION
text.  Does this mean it is limited to plain text? BioCity seems to
generate DESCRIPTIONS with ENCODING parameter and with actual inline
HTML content. I suppose clients could parse the description, discover
HTML-like tags, guess it's HTML, and do the right thing... but that
seems flimsy to me.  Shouldn't we specify the format if it is not plain
text?  What do other clients do?
=20
The second half of this question concerns attachments.  There is a very
direct mechanism for inlining content, but only if it is BINARY.  It
also has an ENCODING parameter (this time, it's in the spec) and
apparently, a way to refer to another "content portion" - again,
non-specific if this is referring to a mechanism of referencing sibling
attachments in a MIME structure, or simply referencing something in the
iCal itself.  Again, my assumption is that it is related to a MIME
structure.  But, does anyone actually generate or read this kind of
complex multipart/related content?
=20
My gut feeling is that these concepts are closely related and that there
should be very similar mechanisms for inlining or outlining content,
specifying format, etc. for both attachments and the body of the event.
And, am I the only one interested in storing HTML descriptions of
events?
=20
cameron
=20

------------=_1092952958-22661-47--

------=_NextPartTM-000-4d8279d7-34e5-4c83-8665-9450aa9653fb--

Date: Thu, 19 Aug 2004 10:50:52 -0700
From: Elias Sinderson <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Time Zones

Anil SRIVASTAVA wrote:

>There are timezone on the 1/2 hour [India] and 45 minute [Kathmandu] 
>boundaries that are not represented by the table below.  
>  
>
To say nothing of Darwin, Australia (GMT+930), which I believe was 
mentioned in a previous post...  :-)

Personally, I'd really prefer to see all times represented over the wire 
and on the server in UTC, with the client being ultimately responsible 
for time conversions to/from local time, including dealing with daylight 
savings. This approach greatly simplifies or outright eliminates many of 
the issues that have been brought up, such as Dougs use case in which a 
manager wants to schedule a recurring conference call at 10am each 
monday in his time zone. In this case, the meeting is scheduled at a 
fixed UTC time and any clients would convert the scheduled UTC time into 
the local time on any given day.

WRT bringing this spec to draft status, I believe the above approach 
will offer the path of least resistance towards demonstrating the 
necessary interoperability.

Regards,
Elias

Content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify] Another issue - reschedules and recurrences
Date: Thu, 19 Aug 2004 09:15:32 -0700
From: "Cameron Stillion" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: 

Yep, it is hard to figure out what to do.  Outlook, for instance,
deletes all of the old instances, loses all conflicts, and
re-establishes the meeting at the new recurrence locations.  Not pretty,
but in the end you have what you asked for (albeit a bit brutally).

There is a user model here that is not quite clear.  When you are
changing a meeting significantly, do you simply truncate the existing
one and create a new one? Or, do you munge the old one beyond
recognition? It seems rather repugnant to simply exclude every instance
of the appointment and include a secondary recurrence that accurately
represents the meeting.  But I'm not sure we should enforce either
behavior.  The user does whatever they will do.  

Perhaps the underlying storage should even support both approaches (it
does now).  Smarter clients though, could avoid changing past
recurrences using exceptions (let's hope there aren't too many) and
create new (future) recurrences using the updated recurrence info.  Can
we leave this decision to the clients?

This seems less of a schema/interop issue than a client decision.

cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Wednesday, August 18, 2004 12:44 PM
To: [email-masked]
Subject: RE: [Ietf-calsify] Another issue - reschedules and recurrences

I still think there's a problem with that.  Just sending out a
reschedule that can both add on new dates to the meeting *and* remove
some old dates (new Rule is a good example) can be hard for  vendors to
figure out what to do with.  Which dates to keep?  Which dates to move?
Which dates to cancel?  There's too much going on there I think.  I
think there's a general issue with iCal that it's often hard to figure
out - what did you mean when you sent this?

A better solution, imho, would be to have dates removed be cancels and
dates added as some other form of action.  This way the cancel case and
the regular reschedule case follow simple rules - look up the UID of the
meeting, the recurrennce ID and move/cancel that one.  Adding on to an
existing meeting could simply be another invite with the same UID and
recurrence IDs that never existed before.
-CS

"Cameron Stillion" <[email-masked]> wrote on 08/18/2004
03:36:53 PM:

>
> It seems like we should leave it up to client applications what to do 
> with past meetings that receive an update for the recurrence.  
> However, I think the standard should continue to allow it.  I want to 
> change my team meeting to wednesdays instead of tuesdays, and extend 
> it to the end of the year - I'll send an update to do so.  The old 
> appointments could either be carved in stone (since they are past) and

> stored as a kind of static history, or altered to reflect the new 
> recurrence pattern depending on the sophistication of the client.
>
>
> cameron
>
>
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Wednesday, August 18, 2004 10:50 AM
> Subject: [Ietf-calsify] Another issue - reschedules and recurrences
>
>
>
>
>
> Should we allow recurrences to grow on a reschedule?  The standard 
> currently allows for this - simply send a new rule (or list of 
> time/dates if we went that route - doesn't matter).  The Rule example 
> can have a different number of occurences than the original meeting.
>
> Should we make this more clear?  If you want to grow or shrink the 
> number of occurences, should be send the recipient more information, 
> like which ones from the old set to keep (if any).  There might be 
> different room or body information on the old set that the sender 
> might be intending to preserve and just move around on the calendar.
> -CS
>
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

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

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-calsify] Time Zones
Date: Thu, 19 Aug 2004 15:20:24 +0200
To: [email-masked]

On Aug 19, 2004, at 15:14, [email-masked] wrote:
> Why are we re-doing timezones.... they are not broken are well defined

Because full timezone support might not be required for transport and 
storage but makes everything a whole lot more complicated (maybe 
unnecessarily).

So even if we find out that we shouldn't (or can't) do something about 
it, it is certainly worth consideration.

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

To: [email-masked]
Subject: Re: [Ietf-calsify] Time Zones
From: [email-masked]
Date: Thu, 19 Aug 2004 09:14:08 -0400

This is a multi-part message in MIME format...

--=_alternative 0048A0EE85256EF5_=
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

Why are we re-doing timezones.... they are not broken are well defined
--=_alternative 0048A0EE85256EF5_=--

Date: Wed, 18 Aug 2004 19:21:33 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify]	Recommendationsfor	strippingdown	iCaltoa	manageable 'standard'
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Thu, 19 Aug 2004 01:21:49 -0000

This is a cryptographically signed message in MIME format.

--------------ms050107000905080003070307
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Cameron Stillion wrote:

>TRANSP does allow parameters, so perhaps we could use the FBTYPE= param
>on this property, and simply ignore the actual value of TRANSP if it
>exists.  This allows us to fold these ideas *which are exactly the same*
>without using two different schema elements.  Existing iCals would not
>be broken.  New iCals would not break old parsers.  How does that sound?
>

What does it add to the functionality? It would be neater, but at what 
cost to
compatibility? We are talking about computer read data.

>No surprise that two new TRANSP properties are being added... they are
>communicating the same notion as FBTYPE, only TRANSP incorrectly tries
>to imply client rendering behavior.  If you prefer using TRANSP to using
>the (more expressive imho)  FBTYPE, then I suggest we make TRANSP values
>that represent each of these free/busy states.  It's not clear to me
>that they match up currently:
>
>Free = transparent
>Busy = opaque
>Busy-Tentative = ?
>Busy-Unavailable = OPAQUE-NOCONFLICT
>? = TRANSPARENT-NOCONFLICT
>

Some implementations map their BUSY time to mean BOOKED time (OPAQUE
with TENTATIVE or not)

Some implementations map their BUSY  their to mean OPAQUE and not 
TENTATIVE only time.

The real meaning of BUSY is - you can not book this time slot for what 
ever reason.
And you might not have access to find if it is TENTATIVE, OPAQUE, or 
TRANSPARENT.
Just no.

Free time is useless information as it can mean that nothing is booked. 
It does not
mean that you are allowed to book that time (1am for example).

So, perhaps we need to come up with a VFREEBUSY2 that does clearly
defined things.

>There seeme to be no way to describe tentative, and no way in VFREEBUSY
>to describe the transparent but unschedulable (? Is that any different
>than a private booked 'busy' appointment?)
>
That's up to the user in some implementations, can not always be automated.

A CUA that asks for VFREEBUSY information gets it so that there can be
a decision on what time are available for inviting a calendar to an 
appointment.

Does it matter why you can not book the time?

>
>It's fine to have an event that takes no time, I don't have a problem
>with that. But that isn't an all-day event, and we shouldn't assume it
>is.  
>  
>
I agree.

>I'm not trying to argue that all events require a duration - I concede
>your point there.  Let's be clear though that our assumption in such
>case should be a zero-time event rather than any other assumption (such
>as an all-day event)
>
Yes.

-- 

--------------ms050107000905080003070307
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms050107000905080003070307--

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-calsify] Time Zones
Date: Wed, 18 Aug 2004 18:11:15 -0700
To: [email-masked]
Cc: Cameron Stillion <[email-masked]>, [email-masked]

The GEOPRIV WG might have some technology that would help us in that 
plan.

lisa

On Aug 18, 2004, at 5:33 PM, [email-masked] wrote:

> Cameron - can you provide a link to information about this time zone 
> scheme? Is it based entirely upon 15 degrees of longitude or does it 
> "zig zag" like time zones do? What about places like Indiana and 
> Arizona that don't participate in daylight savings time? I am 
> interested in reading more.
>
>  I have previously have-jokingly suggested a WG to discuss a new 
> solution for time instead of timezones :-), this might be close.  
> Timezones were invented, if I'm not mistaken, sometime after the 
> advent of railroad transportation, it might be time (pun intended) to 
> look again at Timezones themselves.
>
> All kidding aside, though, my idea was to map FROM a GEO, TO a 
> timezone - if you know where you are, you definitely can know what 
> timezone you're in by some sort of table/database lookup without it 
> being encoded in the calendar items transported.  What the military 
> uses probably meets that criteria(?) and this does look like a simple 
> proposal.
>
> Tim Hare
> Interested Bystander, Non-Inc.
>
>
>
> At 08:41 AM 8/18/04, you wrote:
>
>> I think time zones are more easily mapped to time deltas than GEOs...
>> for probalby every client and system.  But I've heard other requests 
>> to
>> standardize and simplify the timezone story.  Here's a radical idea -
>> what if we only used the military time zone references? These are 
>> fairly
>> standard (within one community, anyway).  We have adopted Zulu pretty
>> readily, how about we just go with the rest of the alphabetic 
>> standard?
>> For those interested, here it is:
>>
>> A : UTC+1
>> B : UTC+2
>> C : UTC+3
>> D : UTC+4
>> E : UTC+5
>> F : UTC+6
>> G : UTC+7
>> H : UTC+8
>> I : UTC+9
>> K : UTC+10
>> L : UTC+11
>> M : UTC+12
>> N : UTC-1
>> O : UTC-2
>> P : UTC-3
>> Q : UTC-4
>> R : UTC-5
>> S : UTC-6
>> T : UTC-7
>> U : UTC-8
>> V : UTC-9
>> W : UTC-10
>> X : UTC-11
>> Y : UTC-12
>> Z : UTC
>>
>> (for those curious about why Juliet was left out...? It's not about 
>> the
>> tragic Capulet, but the tragic army officer named Custer, and the 
>> army's
>> inability to forgive him...)
>>
>> Alternatively - what if there are only floating times and zulu times?
>> All other time zone processing could be pushed to the client - is that
>> too draconian?
>>
>>
>> Also... concerning GetCapabilities - that doesn't necessarily work 
>> for a
>> standalone .ics file that I publish to a website... But I completely
>> agree with your assessment of RRULE as a means of communicating a vast
>> recurrence set tersely.  This is why I think we should not completely 
>> do
>> away with it, but rather simplify it.
>>
>>
>> Regards,
>> cameron
>>
>>
>> [mailto:[email-masked]] On Behalf Of
>> [email-masked]
>> Sent: Tuesday, August 17, 2004 8:37 PM
>> Subject: [Ietf-calsify] Thoughts on some of the simplification 
>> thoughts
>> sofar
>>
>> If you start breaking out VTODOs, VJOURNALs, or whatever, then perhaps
>> you're on a path where you have a multi-layered standard:
>>
>>          Layer 0 would be representation of the "generic" parts of the
>> object (DTSTAMP, UID, DTSTART(?) etc.)
>>          Layer 1 would be representation of specific items, perhaps 
>> one
>> standard per VEVENT/VTODO/VJOURNAL, etc.
>>
>> Endpoints of a calendaring conversation would have to either identify
>> what objects they could deal with, or issue errors when passed an 
>> object
>> they couldn't, or both.
>>
>> Elimination of recurrence rules by passing lists of date/time values
>> back and forth overlooks the advantage of using the "shorthand" of
>> recurrence rules, which allow a large list of dates and times with a
>> short rule. I'm not arguing for or against, just making a point that I
>> hadn't heard expressed.  If you end wanting both possibilities, you 
>> have
>> to have a discovery mechanism to see what the other end handles. 
>> This, I
>> think, is at least partly handled by the "expand recurrence" property
>> which is returned in the GET-CAPABILITY response (I think).
>>
>> Elimination of GEO values - I would rather see GEO be used as an index
>> into timezone data, rather than passing the timezone data along with 
>> the
>> objects, since a geographic location rather efficiently can get you 
>> the
>> timezone information. If eliminated, then I would like to see another
>> document for standardization of time zone identifiers, and only pass 
>> the
>> identifiers, not all of the time zone rules themselves.
>>
>>
>> Tim Hare
>> Interested Bystander, Non-Inc.
>>
>>
>> _______________________________________________
>> Ietf-calsify mailing list
>> [email-masked]
>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
> Tim Hare
> Interested Bystander, Non-Inc.
>
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Date: Wed, 18 Aug 2004 20:51:42 -0400
To: [email-masked]
From: [email-masked]
Subject: Re: [Ietf-calsify] Time Zones

The additions (UTC OFFSET and VTIMEZONE) mentioned seem to me to make a 
pretty good case for all times being stored or exchanged to be in Zulu 
time, and leave the local time as a OS/UI problem. On the mainframe I work 
on, things are handled this way - the hardware clock is set to Zulu time, 
the timezone offset is stored as a parameter to the OS, and the calls 
applications make to the OS get time can return either value depending upon 
the need (database logging uses Zulu, displaying today's date on a screen 
uses local time, for example).

This would push some of the time complexity out of the iCalendar protocol 
and implementations, to the OS. But that's not necessarily bad, the OS 
should be the one source for time info for anything executing on that piece 
of hardware, in my opinion.

One other use case that hit me last summer, when I was trying to create a 
file for my PDA, and which has to be accounted for: when the client will be 
physicially moved to a new time zone. Specifically, I wanted to add 
conference session events, but I did NOT want to change my PDA's time to 
the local time when I got there. I solved it then by using floating time 
for all events, but storing everything in floating time causes  problems 
when you are synchronizing people across multiple timezones.

Tim Hare
Interested Bystander, Non-Inc.

At 12:51 PM 8/18/04, you wrote:

>Cameron Stillion wrote:
>
>>I think time zones are more easily mapped to time deltas than GEOs...
>>for probalby every client and system.  But I've heard other requests to
>>standardize and simplify the timezone story.  Here's a radical idea -
>>what if we only used the military time zone references? These are fairly
>>standard (within one community, anyway).  We have adopted Zulu pretty
>>readily, how about we just go with the rest of the alphabetic standard?
>>For those interested, here it is:
>...
>
>Sounds like a good idea. The probem is that some time zones are not
>multiple of 60 minutes. Some are 30 minutes, and a few are 15 minutes.
>
>So we added UTC-OFFST.
>
>Second problem is that the rule for when to change the time are not
>uniform and are subject to local cival authority. For example when I was
>young some parts of  area did not go to daylight savings time, others did.
>So its not a UTC offset problem. its a mapping the UTC offset problem
>into what each users wall clock says is the time.
>
>So we added the VTIMEZONE, and allowed objects to point
>to the VTIMEZONE objects. I am not against simplification. I am
>against not being able to tell what time I need to pick up the
>phone and get on a conferenec call to some country where my
>one year old application can not resolve its time to wall clock time.
>
>This problem is even more complecated by simple recurring meetings.
>
>Again I would love simplification. But its not that simple of a problem.
>
>A manager wants to say 'have everyone be on the conference call
>at 10am my wall clock time each Monday". Regardless of the UTC
>offset this monday here vs the UTC offset on monay 3 months from now
>after daylight savings time changes in his time zone and not yours.
>
>--
>
>_______________________________________________
>Ietf-calsify mailing list
>[email-masked]
>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Tim Hare
Interested Bystander, Non-Inc. 

Date: Wed, 18 Aug 2004 20:33:55 -0400
To: [email-masked], "Cameron Stillion" <[email-masked]>
From: [email-masked]
Subject: RE: [Ietf-calsify] Time Zones
Cc: 

Cameron - can you provide a link to information about this time zone 
scheme? Is it based entirely upon 15 degrees of longitude or does it "zig 
zag" like time zones do? What about places like Indiana and Arizona that 
don't participate in daylight savings time? I am interested in reading more.

  I have previously have-jokingly suggested a WG to discuss a new solution 
for time instead of timezones :-), this might be close.  Timezones were 
invented, if I'm not mistaken, sometime after the advent of railroad 
transportation, it might be time (pun intended) to look again at Timezones 
themselves.

All kidding aside, though, my idea was to map FROM a GEO, TO a timezone - 
if you know where you are, you definitely can know what timezone you're in 
by some sort of table/database lookup without it being encoded in the 
calendar items transported.  What the military uses probably meets that 
criteria(?) and this does look like a simple proposal.

Tim Hare
Interested Bystander, Non-Inc.

At 08:41 AM 8/18/04, you wrote:

>I think time zones are more easily mapped to time deltas than GEOs...
>for probalby every client and system.  But I've heard other requests to
>standardize and simplify the timezone story.  Here's a radical idea -
>what if we only used the military time zone references? These are fairly
>standard (within one community, anyway).  We have adopted Zulu pretty
>readily, how about we just go with the rest of the alphabetic standard?
>For those interested, here it is:
>
>A : UTC+1
>B : UTC+2
>C : UTC+3
>D : UTC+4
>E : UTC+5
>F : UTC+6
>G : UTC+7
>H : UTC+8
>I : UTC+9
>K : UTC+10
>L : UTC+11
>M : UTC+12
>N : UTC-1
>O : UTC-2
>P : UTC-3
>Q : UTC-4
>R : UTC-5
>S : UTC-6
>T : UTC-7
>U : UTC-8
>V : UTC-9
>W : UTC-10
>X : UTC-11
>Y : UTC-12
>Z : UTC
>
>(for those curious about why Juliet was left out...? It's not about the
>tragic Capulet, but the tragic army officer named Custer, and the army's
>inability to forgive him...)
>
>Alternatively - what if there are only floating times and zulu times?
>All other time zone processing could be pushed to the client - is that
>too draconian?
>
>
>Also... concerning GetCapabilities - that doesn't necessarily work for a
>standalone .ics file that I publish to a website... But I completely
>agree with your assessment of RRULE as a means of communicating a vast
>recurrence set tersely.  This is why I think we should not completely do
>away with it, but rather simplify it.
>
>
>Regards,
>cameron
>
>
>[mailto:[email-masked]] On Behalf Of
>[email-masked]
>Sent: Tuesday, August 17, 2004 8:37 PM
>Subject: [Ietf-calsify] Thoughts on some of the simplification thoughts
>sofar
>
>If you start breaking out VTODOs, VJOURNALs, or whatever, then perhaps
>you're on a path where you have a multi-layered standard:
>
>          Layer 0 would be representation of the "generic" parts of the
>object (DTSTAMP, UID, DTSTART(?) etc.)
>          Layer 1 would be representation of specific items, perhaps one
>standard per VEVENT/VTODO/VJOURNAL, etc.
>
>Endpoints of a calendaring conversation would have to either identify
>what objects they could deal with, or issue errors when passed an object
>they couldn't, or both.
>
>Elimination of recurrence rules by passing lists of date/time values
>back and forth overlooks the advantage of using the "shorthand" of
>recurrence rules, which allow a large list of dates and times with a
>short rule. I'm not arguing for or against, just making a point that I
>hadn't heard expressed.  If you end wanting both possibilities, you have
>to have a discovery mechanism to see what the other end handles. This, I
>think, is at least partly handled by the "expand recurrence" property
>which is returned in the GET-CAPABILITY response (I think).
>
>Elimination of GEO values - I would rather see GEO be used as an index
>into timezone data, rather than passing the timezone data along with the
>objects, since a geographic location rather efficiently can get you the
>timezone information. If eliminated, then I would like to see another
>document for standardization of time zone identifiers, and only pass the
>identifiers, not all of the time zone rules themselves.
>
>
>Tim Hare
>Interested Bystander, Non-Inc.
>
>
>_______________________________________________
>Ietf-calsify mailing list
>[email-masked]
>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Tim Hare
Interested Bystander, Non-Inc. 

Subject: RE: [Ietf-calsify] Another issue - reschedules and recurrences
To: [email-masked]
From: [email-masked]
Date: Wed, 18 Aug 2004 15:44:23 -0400

I still think there's a problem with that.  Just sending out a reschedule
that can both add on new dates to the meeting *and* remove some old dates
(new Rule is a good example) can be hard for  vendors to figure out what to
do with.  Which dates to keep?  Which dates to move?  Which dates to
cancel?  There's too much going on there I think.  I think there's a
general issue with iCal that it's often hard to figure out - what did you
mean when you sent this?

A better solution, imho, would be to have dates removed be cancels and
dates added as some other form of action.  This way the cancel case and the
regular reschedule case follow simple rules - look up the UID of the
meeting, the recurrennce ID and move/cancel that one.  Adding on to an
existing meeting could simply be another invite with the same UID and
recurrence IDs that never existed before.
-CS

"Cameron Stillion" <[email-masked]> wrote on 08/18/2004
03:36:53 PM:

>
> It seems like we should leave it up to client applications what to do
> with past meetings that receive an update for the recurrence.  However,
> I think the standard should continue to allow it.  I want to change my
> team meeting to wednesdays instead of tuesdays, and extend it to the end
> of the year - I'll send an update to do so.  The old appointments could
> either be carved in stone (since they are past) and stored as a kind of
> static history, or altered to reflect the new recurrence pattern
> depending on the sophistication of the client.
>
>
> cameron
>
>
> [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Wednesday, August 18, 2004 10:50 AM
> Subject: [Ietf-calsify] Another issue - reschedules and recurrences
>
>
>
>
>
> Should we allow recurrences to grow on a reschedule?  The standard
> currently allows for this - simply send a new rule (or list of
> time/dates if we went that route - doesn't matter).  The Rule example
> can have a different number of occurences than the original meeting.
>
> Should we make this more clear?  If you want to grow or shrink the
> number of occurences, should be send the recipient more information,
> like which ones from the old set to keep (if any).  There might be
> different room or body information on the old set that the sender might
> be intending to preserve and just move around on the calendar.
> -CS
>
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify] Another issue - reschedules and recurrences
Date: Wed, 18 Aug 2004 12:36:53 -0700
From: "Cameron Stillion" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: 

It seems like we should leave it up to client applications what to do
with past meetings that receive an update for the recurrence.  However,
I think the standard should continue to allow it.  I want to change my
team meeting to wednesdays instead of tuesdays, and extend it to the end
of the year - I'll send an update to do so.  The old appointments could
either be carved in stone (since they are past) and stored as a kind of
static history, or altered to reflect the new recurrence pattern
depending on the sophistication of the client.

cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Wednesday, August 18, 2004 10:50 AM
To: [email-masked]
Subject: [Ietf-calsify] Another issue - reschedules and recurrences

Should we allow recurrences to grow on a reschedule?  The standard
currently allows for this - simply send a new rule (or list of
time/dates if we went that route - doesn't matter).  The Rule example
can have a different number of occurences than the original meeting.

Should we make this more clear?  If you want to grow or shrink the
number of occurences, should be send the recipient more information,
like which ones from the old set to keep (if any).  There might be
different room or body information on the old set that the sender might
be intending to preserve and just move around on the calendar.
-CS

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

Date: Wed, 18 Aug 2004 12:31:22 -0700 (Pacific Daylight Time)
From: Anil SRIVASTAVA <[email-masked]>
Subject: RE: [Ietf-calsify] Time Zones
Sender: [email-masked]
To: Cameron Stillion <[email-masked]>
Organization: Sun Microsystems [http://www.sun.com]
Accept-Language: English; en
Cc: [email-masked]
Reply-To: [email-masked]

There are timezone on the 1/2 hour [India] and 45 minute [Kathmandu] 
boundaries that are not represented by the table below.  

Anil

On 2004-08-18/05:41 [-0700], [email-masked] [Cameron...:

> 
> I think time zones are more easily mapped to time deltas than GEOs... 
> for probalby every client and system.  But I've heard other requests 
> to standardize and simplify the timezone story.  Here's a radical idea 
> - what if we only used the military time zone references? These are 
> fairly standard (within one community, anyway).  We have adopted Zulu 
> pretty readily, how about we just go with the rest of the alphabetic 
> standard? For those interested, here it is:
> 
> A : UTC+1
> B : UTC+2
> C : UTC+3
> D : UTC+4
> E : UTC+5
> F : UTC+6
> G : UTC+7
> H : UTC+8
> I : UTC+9
> K : UTC+10
> L : UTC+11
> M : UTC+12
> N : UTC-1
> O : UTC-2
> P : UTC-3
> Q : UTC-4
> R : UTC-5
> S : UTC-6
> T : UTC-7
> U : UTC-8
> V : UTC-9
> W : UTC-10
> X : UTC-11
> Y : UTC-12
> Z : UTC
> 
> (for those curious about why Juliet was left out...? It's not about the
> tragic Capulet, but the tragic army officer named Custer, and the army's
> inability to forgive him...)
> 
> Alternatively - what if there are only floating times and zulu times?
> All other time zone processing could be pushed to the client - is that
> too draconian? 
> 
> 
> Also... concerning GetCapabilities - that doesn't necessarily work for a
> standalone .ics file that I publish to a website... But I completely
> agree with your assessment of RRULE as a means of communicating a vast
> recurrence set tersely.  This is why I think we should not completely do
> away with it, but rather simplify it.
> 
> 
> Regards,
> cameron
> 
> 
> [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Tuesday, August 17, 2004 8:37 PM
> Subject: [Ietf-calsify] Thoughts on some of the simplification thoughts
> sofar
> 
> If you start breaking out VTODOs, VJOURNALs, or whatever, then perhaps
> you're on a path where you have a multi-layered standard:
> 
>          Layer 0 would be representation of the "generic" parts of the
> object (DTSTAMP, UID, DTSTART(?) etc.)
>          Layer 1 would be representation of specific items, perhaps one
> standard per VEVENT/VTODO/VJOURNAL, etc.
> 
> Endpoints of a calendaring conversation would have to either identify
> what objects they could deal with, or issue errors when passed an object
> they couldn't, or both.
> 
> Elimination of recurrence rules by passing lists of date/time values
> back and forth overlooks the advantage of using the "shorthand" of
> recurrence rules, which allow a large list of dates and times with a
> short rule. I'm not arguing for or against, just making a point that I
> hadn't heard expressed.  If you end wanting both possibilities, you have
> to have a discovery mechanism to see what the other end handles. This, I
> think, is at least partly handled by the "expand recurrence" property
> which is returned in the GET-CAPABILITY response (I think).
> 
> Elimination of GEO values - I would rather see GEO be used as an index
> into timezone data, rather than passing the timezone data along with the
> objects, since a geographic location rather efficiently can get you the
> timezone information. If eliminated, then I would like to see another
> document for standardization of time zone identifiers, and only pass the
> identifiers, not all of the time zone rules themselves.
> 
> 
> Tim Hare
> Interested Bystander, Non-Inc. 
> 
> 
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> 
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> 

-- 
__________
Anil SRIVASTAVA
[email-masked]

To: [email-masked]
Subject: Re: [Ietf-calsify] Time Zones
From: [email-masked]
Date: Wed, 18 Aug 2004 14:16:24 -0400

This is a multi-part message in MIME format...

--=_alternative 00644D2885256EF4_=
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

The driving issue for timezones was for repeating meetings that cross 
daylight/standard date.  The date that daylight/standard switch occurs on, 
depends on the timezone of chair not the timezone of invitee.  Because of 
this just sending offsets causes problems.

Doug Royer <[email-masked]> 
Sent by: [email-masked]
08/18/2004 12:51 PM
Please respond to
[email-masked]

To
[email-masked]
cc

Subject
Re: [Ietf-calsify] Time Zones

Cameron Stillion wrote:

>I think time zones are more easily mapped to time deltas than GEOs...
>for probalby every client and system.  But I've heard other requests to
>standardize and simplify the timezone story.  Here's a radical idea -
>what if we only used the military time zone references? These are fairly
>standard (within one community, anyway).  We have adopted Zulu pretty
>readily, how about we just go with the rest of the alphabetic standard?
>For those interested, here it is:
>
...

Sounds like a good idea. The probem is that some time zones are not
multiple of 60 minutes. Some are 30 minutes, and a few are 15 minutes.

So we added UTC-OFFST.

Second problem is that the rule for when to change the time are not
uniform and are subject to local cival authority. For example when I was
young some parts of  area did not go to daylight savings time, others did.
So its not a UTC offset problem. its a mapping the UTC offset problem
into what each users wall clock says is the time.

So we added the VTIMEZONE, and allowed objects to point
to the VTIMEZONE objects. I am not against simplification. I am
against not being able to tell what time I need to pick up the
phone and get on a conferenec call to some country where my
one year old application can not resolve its time to wall clock time.

This problem is even more complecated by simple recurring meetings.

Again I would love simplification. But its not that simple of a problem.

A manager wants to say 'have everyone be on the conference call
at 10am my wall clock time each Monday". Regardless of the UTC
offset this monday here vs the UTC offset on monay 3 months from now
after daylight savings time changes in his time zone and not yours.

-- 

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

--=_alternative 00644D2885256EF4_=--

To: [email-masked]
From: [email-masked]
Date: Wed, 18 Aug 2004 13:50:06 -0400
Subject: [Ietf-calsify] Another issue - reschedules and recurrences

Should we allow recurrences to grow on a reschedule?  The standard
currently allows for this - simply send a new rule (or list of time/dates
if we went that route - doesn't matter).  The Rule example can have a
different number of occurences than the original meeting.

Should we make this more clear?  If you want to grow or shrink the number
of occurences, should be send the recipient more information, like which
ones from the old set to keep (if any).  There might be different room or
body information on the old set that the sender might be intending to
preserve and just move around on the calendar.
-CS

Content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify] Recommendationsfor	strippingdown	iCaltoa	manageable 'standard'
Date: Wed, 18 Aug 2004 10:45:28 -0700
From: "Cameron Stillion" <[email-masked]>
To: <[email-masked]>

If an event has no DURATION and no DTEND, we assume that it starts and
ends at the   same time, in which case, I agree TRANSP does not matter.

TRANSP does allow parameters, so perhaps we could use the FBTYPE= param
on this property, and simply ignore the actual value of TRANSP if it
exists.  This allows us to fold these ideas *which are exactly the same*
without using two different schema elements.  Existing iCals would not
be broken.  New iCals would not break old parsers.  How does that sound?

No surprise that two new TRANSP properties are being added... they are
communicating the same notion as FBTYPE, only TRANSP incorrectly tries
to imply client rendering behavior.  If you prefer using TRANSP to using
the (more expressive imho)  FBTYPE, then I suggest we make TRANSP values
that represent each of these free/busy states.  It's not clear to me
that they match up currently:

Free = transparent
Busy = opaque
Busy-Tentative = ?
Busy-Unavailable = OPAQUE-NOCONFLICT
? = TRANSPARENT-NOCONFLICT

There seeme to be no way to describe tentative, and no way in VFREEBUSY
to describe the transparent but unschedulable (? Is that any different
than a private booked 'busy' appointment?)

It's fine to have an event that takes no time, I don't have a problem
with that. But that isn't an all-day event, and we shouldn't assume it
is.  

I misspoke that an event can have both enddate and duration - they
cannot.

I'm not trying to argue that all events require a duration - I concede
your point there.  Let's be clear though that our assumption in such
case should be a zero-time event rather than any other assumption (such
as an all-day event)

cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Doug Royer
Sent: Wednesday, August 18, 2004 9:33 AM
To: [email-masked]
Subject: Re: [Ietf-calsify] Recommendationsfor strippingdown iCaltoa
manageable 'standard'

Cameron Stillion wrote:

>It seems like whether the event shows as busy, free or tentative should

>be independent of whether it is a multi-day, single-day, all-day event,

>or just a regular old appointment.  We can make no assumptions about 
>the availability based on the start or end time, the timezone 
>association, or whether it has hours or minutes.  Let's not make 
>dependencies on orthogonal properties.
>

It's not that its a rule. Its that if it has no DURATION or DTEND then
there are ZERO seconds that are really booked. So even if TRANSP were
set to OPAQUE it would be opaque for zero seconds which is identical to
TRANSPARENT.

Maybe we can come up with a way to be compatible with existing iCal
objects. If we simply declare two of the items the same, then we can no
longer import them and know what to do with them.

>Speaking of TRANSP... This should have the same values as the 
>fbtypeparam. The document constantly refers to this as the free/busy 
>state of the event anyway, let's just make it very clear that it is 
>indeed the same.  And actually, the state definition which is { opaque 
>| transparent } seems to imply a lot about how the client renders such 
>things.  It makes much more sense to me to use the { free | busy | 
>busy-unavailable | busy-tentative } states and let the client 
>applications determine how these are rendered.
>
There will soon be 2 more TRANSP states introduced from CAP that will be
pooping out soon from the 4-5 vendors that will be sending CAP objects
soon.

    TRANSPARENT-NOCONFLICT
    OPAQUE-NOCONFLICT

Where NOCONFLICT means that no other object may use any of the the same
time slot.

And the VFREEBUSY was a stop gap until we had some kind of real time
transport anyway.  In CAP for example you can ask for the dynamic
VFREEBUSY object that represents the free time from a calendar. I can
mark 6pm-8am as TRANSPARENT-NOCONFLICT so that no one would be able to
book time with me for non-working hours (one example of usage).  I would
not be available and have only one bogus repeating object, yet not show
up as booked time.

I do not think that we should change the values of TRANSP even if it
looks difficult to follow as it will break existing objects. Instead we
need to more clearly explain how to use its values.

>I still think that the anniversary example should have a duration.  
>That is to say, either an event has an end date or a duration or both.

>Why would we default the length of an event to 1 day? It seems like an 
>optimization for an uncommon case.
>
Many PDAs, PIMs, and application allow for the creation of objects that
consume no time at all (NO END).  At 10am take your pill for example,
would consume no time and yet have an entry. So even if you do not call
it an anniverisy you still have the same problem.

>
>So, we don't need a boolean for all-day property, since this can be 
>gleaned from DTSTART and ( DTEND or DURATION - which are mutually 
>exclusive, btw).
>  
>
Those are also valid needs. I do not see that you have sucessfully
argued for the ability to require all object to have a duration.

-- 

To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-calsify] Time Zones
From: [email-masked]
Date: Wed, 18 Aug 2004 13:18:08 -0400
Cc: [email-masked], [email-masked]

This is a multi-part message in MIME format...

--=_alternative 005EF76A85256EF4_=
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

The timezone component has been tested in several interops

Lisa Dusseault <[email-masked]> 
Sent by: [email-masked]
08/18/2004 01:03 PM

To
Dan Winship <[email-masked]>
cc
[email-masked]
Subject
Re: [Ietf-calsify] Time Zones

> And I think we need to keep it in the spec. Weekly conference calls 
> with
> people in other countries that have different daylight savings time
> rules than you are a fact of business life these days.
>
Recall that in order to take iCalendar to Draft Standard, the 
specification MUST drop any features that aren't implemented and 
interoperable -- CalConnect is part of the effort to document tested 
interoperable features.  So the consideration "need to keep it in the 
spec" must be followed by, not theoretical use cases, but actual tested 
interoperability (either already documented, or performed between now 
and submitting to draft standard).

Lisa

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

--=_alternative 005EF76A85256EF4_=--

Date: Wed, 18 Aug 2004 11:06:02 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Recommendations for	strippingdown	iCaltoa	manageable 'standard'
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Wed, 18 Aug 2004 17:06:18 -0000

This is a cryptographically signed message in MIME format.

--------------ms060104040803030600060802
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Preston Stephenson wrote:

>Sorry, I need more clarification.
>I've seen UI's that put all day events in a different place than
>appointments.
>What is the determine factor that decides to put an appointments as an
>all day event?
>Being transparent (free or busy-tentative) and having a duration of a
>day (or multiple days)?
>If a day or multiple day event blocks time, it is displayed with other
>appointments?
>Transparency alone can't be the deciding factor.
>Thanks.
>Preston
>
>  
>
TRANSPART means it does not show up in your busy time.

OPAQUE means it does show up in your busy time. 

New CAP TRANSP values coming out:

The TRANSPART-NO-CONFLICT values means it  does not show
up in the busy time and no one is allowed to book that time.

The TRANSPART-CONFLICT values means it  does not show
up in the busy time and the time can be booked.

In all cases it is a  CU discussion not a CUA decision. It
can not be automated all of the time. An implementation
might automate it, another might ask the CU if they
want to allow conflicts or not, so you would need to be
ready for ether case.

The two new values were added in CAP to simplify
the problem where some thought that OPAQUE meant
no-overlapped booking and other thought it meant
overlaps are allowed shows up as busy. It it was
as clarification / simplification that allows different
implementations to understand the intention of
the objects busy and overlapped booking values.

-- 

--------------ms060104040803030600060802
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms060104040803030600060802--

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-calsify] Time Zones
Date: Wed, 18 Aug 2004 10:03:55 -0700
To: Dan Winship <[email-masked]>
Cc: [email-masked]

> And I think we need to keep it in the spec. Weekly conference calls 
> with
> people in other countries that have different daylight savings time
> rules than you are a fact of business life these days.
>
Recall that in order to take iCalendar to Draft Standard, the 
specification MUST drop any features that aren't implemented and 
interoperable -- CalConnect is part of the effort to document tested 
interoperable features.  So the consideration "need to keep it in the 
spec" must be followed by, not theoretical use cases, but actual tested 
interoperability (either already documented, or performed between now 
and submitting to draft standard).

Lisa

Date: Wed, 18 Aug 2004 10:51:53 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Time Zones
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Wed, 18 Aug 2004 16:52:06 -0000

This is a cryptographically signed message in MIME format.

--------------ms050803080604040307080805
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Cameron Stillion wrote:

>I think time zones are more easily mapped to time deltas than GEOs...
>for probalby every client and system.  But I've heard other requests to
>standardize and simplify the timezone story.  Here's a radical idea -
>what if we only used the military time zone references? These are fairly
>standard (within one community, anyway).  We have adopted Zulu pretty
>readily, how about we just go with the rest of the alphabetic standard?
>For those interested, here it is:
>
...

Sounds like a good idea. The probem is that some time zones are not
multiple of 60 minutes. Some are 30 minutes, and a few are 15 minutes.

So we added UTC-OFFST.

Second problem is that the rule for when to change the time are not
uniform and are subject to local cival authority. For example when I was
young some parts of  area did not go to daylight savings time, others did.
So its not a UTC offset problem. its a mapping the UTC offset problem
into what each users wall clock says is the time.

So we added the VTIMEZONE, and allowed objects to point
to the VTIMEZONE objects. I am not against simplification. I am
against not being able to tell what time I need to pick up the
phone and get on a conferenec call to some country where my
one year old application can not resolve its time to wall clock time.

This problem is even more complecated by simple recurring meetings.

Again I would love simplification. But its not that simple of a problem.

A manager wants to say 'have everyone be on the conference call
at 10am my wall clock time each Monday". Regardless of the UTC
offset this monday here vs the UTC offset on monay 3 months from now
after daylight savings time changes in his time zone and not yours.

-- 

--------------ms050803080604040307080805
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms050803080604040307080805--

Date: Wed, 18 Aug 2004 10:38:17 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] PIM Data Types
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Wed, 18 Aug 2004 16:38:29 -0000

This is a cryptographically signed message in MIME format.

--------------ms080005000705070708070309
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Cameron Stillion wrote:

>For example, I need to be able to specify that a particular calendar
>that I have published to my website is My Personal free/busy
>information, or My Personal Schedule, and not just an IETF 60 calendar
>that I put together for everyone's use. This implies that the calendar
>have a property that links it to a contact (me) - and I would argue
>vCard is the right general direction for that.  Likewise, I might want a
>link from inside the vCard to my personal free/busy .ics so that when I
>share my contact with someone, they can also schedule me for meetings. 
>  
>
I submitted such a draft severl months ago (now expired).   I agree. And 
there
is an RFC that describes how to link a VCARD to an iCAL objects
and that RFC also included LDAP links. RFC-2739

-- 

--------------ms080005000705070708070309
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms080005000705070708070309--

Date: Wed, 18 Aug 2004 10:32:32 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Recommendations for	strippingdown	iCaltoa	manageable 'standard'
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Wed, 18 Aug 2004 16:32:49 -0000

This is a cryptographically signed message in MIME format.

--------------ms070108020106080505010205
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Cameron Stillion wrote:

>It seems like whether the event shows as busy, free or tentative should
>be independent of whether it is a multi-day, single-day, all-day event,
>or just a regular old appointment.  We can make no assumptions about the
>availability based on the start or end time, the timezone association,
>or whether it has hours or minutes.  Let's not make dependencies on
>orthogonal properties.  
>

It's not that its a rule. Its that if it has no DURATION or DTEND then
there are ZERO seconds that are really booked. So even if TRANSP
were set to OPAQUE it would be opaque for zero seconds which
is identical to TRANSPARENT.

Maybe we can come up with a way to be compatible with existing iCal
objects. If we simply declare two of the items the same, then we can no
longer import them and know what to do with them.

>Speaking of TRANSP... This should have the same values as the
>fbtypeparam. The document constantly refers to this as the free/busy
>state of the event anyway, let's just make it very clear that it is
>indeed the same.  And actually, the state definition which is { opaque |
>transparent } seems to imply a lot about how the client renders such
>things.  It makes much more sense to me to use the { free | busy |
>busy-unavailable | busy-tentative } states and let the client
>applications determine how these are rendered.
>
There will soon be 2 more TRANSP states introduced from CAP that will be
pooping out soon from the 4-5 vendors that will be sending CAP
objects soon.

    TRANSPARENT-NOCONFLICT
    OPAQUE-NOCONFLICT

Where NOCONFLICT means that no other object may use any of the the
same time slot.

And the VFREEBUSY was a stop gap until we had some kind of real time
transport anyway.  In CAP for example you can ask for the dynamic VFREEBUSY
object that represents the free time from a calendar. I can mark 6pm-8am as
TRANSPARENT-NOCONFLICT so that no one would be able to book time
with me for non-working hours (one example of usage).  I would not be
available and have only one bogus repeating object, yet not show up
as booked time.

I do not think that we should change the values of TRANSP even if it looks
difficult to follow as it will break existing objects. Instead we need 
to more
clearly explain how to use its values.

>I still think that the anniversary example should have a duration.  That
>is to say, either an event has an end date or a duration or both.  Why
>would we default the length of an event to 1 day? It seems like an
>optimization for an uncommon case.
>
Many PDAs, PIMs, and application allow for the creation of objects that
consume no time at all (NO END).  At 10am take your pill for example,
would consume no time and yet have an entry. So even if you do not
call it an anniverisy you still have the same problem.

>
>So, we don't need a boolean for all-day property, since this can be
>gleaned from DTSTART and ( DTEND or DURATION - which are mutually
>exclusive, btw).
>  
>
Those are also valid needs. I do not see that you have sucessfully argued
for the ability to require all object to have a duration.

-- 

--------------ms070108020106080505010205
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms070108020106080505010205--

Date: Wed, 18 Aug 2004 12:22:08 -0400
Subject: Re: [Ietf-calsify] Time Zones
From: Graham Gilmore <[email-masked]>
To: "Cameron Stillion" <[email-masked]>, <[email-masked]>
Cc: 

	There are some time zones whose offsets don't fall on the hour, and 
would be unrepresentable with this proposal.

	Graham

On Wednesday, August 18, 2004, at 08:41  AM, Cameron Stillion wrote:

>
> I think time zones are more easily mapped to time deltas than GEOs...
> for probalby every client and system.  But I've heard other requests to
> standardize and simplify the timezone story.  Here's a radical idea -
> what if we only used the military time zone references? These are 
> fairly
> standard (within one community, anyway).  We have adopted Zulu pretty
> readily, how about we just go with the rest of the alphabetic standard?
> For those interested, here it is:
>
> A : UTC+1
> B : UTC+2
> C : UTC+3
> D : UTC+4
> E : UTC+5
> F : UTC+6
> G : UTC+7
> H : UTC+8
> I : UTC+9
> K : UTC+10
> L : UTC+11
> M : UTC+12
> N : UTC-1
> O : UTC-2
> P : UTC-3
> Q : UTC-4
> R : UTC-5
> S : UTC-6
> T : UTC-7
> U : UTC-8
> V : UTC-9
> W : UTC-10
> X : UTC-11
> Y : UTC-12
> Z : UTC

Content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify] Recommendations forstrippingdown	iCaltoa	manageable 'standard'
Date: Wed, 18 Aug 2004 08:43:58 -0700
From: "Cameron Stillion" <[email-masked]>
To: "Preston Stephenson" <[email-masked]>, <[email-masked]>
Cc: 

Ah, let me clarify:

What I mean is - transparency is a misnamed, misguided property that
should be replaced by the notion of fbstate.  Literal "transparency" is
a rendering issue that should NOT be decided by the store or transport.
What clients need to know is whether the time should be considered free,
busy, tentative, or out-of-office.  How transparent the client wishes to
render should be left for it to decide.

All day events are identified by their lack of a specific time in
DTSTART and DTEND.  Or DURATION, if present would be an integral number
of days. Transparency shouldn't be a deciding factor AT ALL.

These two properties should be completely orthogonal.

Cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Preston
Stephenson
Sent: Wednesday, August 18, 2004 6:00 AM
To: [email-masked]
Subject: RE: [Ietf-calsify] Recommendations forstrippingdown iCaltoa
manageable 'standard'

Sorry, I need more clarification.
I've seen UI's that put all day events in a different place than
appointments.
What is the determine factor that decides to put an appointments as an
all day event?
Being transparent (free or busy-tentative) and having a duration of a
day (or multiple days)?
If a day or multiple day event blocks time, it is displayed with other
appointments?
Transparency alone can't be the deciding factor.
Thanks.
Preston

>>> "Cameron Stillion" <[email-masked]> 08/18/04 6:02
AM >>>

It seems like whether the event shows as busy, free or tentative should
be independent of whether it is a multi-day, single-day, all-day event,
or just a regular old appointment.  We can make no assumptions about the
availability based on the start or end time, the timezone association,
or whether it has hours or minutes.  Let's not make dependencies on
orthogonal properties.  

Speaking of TRANSP... This should have the same values as the
fbtypeparam. The document constantly refers to this as the free/busy
state of the event anyway, let's just make it very clear that it is
indeed the same.  And actually, the state definition which is { opaque
|
transparent } seems to imply a lot about how the client renders such
things.  It makes much more sense to me to use the { free | busy |
busy-unavailable | busy-tentative } states and let the client
applications determine how these are rendered.

I still think that the anniversary example should have a duration. 
That
is to say, either an event has an end date or a duration or both.  Why
would we default the length of an event to 1 day? It seems like an
optimization for an uncommon case.

So, we don't need a boolean for all-day property, since this can be
gleaned from DTSTART and ( DTEND or DURATION - which are mutually
exclusive, btw).

Regards,
cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Doug Royer
Sent: Tuesday, August 17, 2004 8:42 PM
To: [email-masked]
Subject: Re: [Ietf-calsify] Recommendations for strippingdown iCaltoa
manageable 'standard'

Cameron Stillion wrote:

>I would argue that Anniversary should include duration (one day in
most
>cases?) And also that your third case is really the same as the
first.
>In other words, New Year's Day is just an anniversary that happens on
1

>Jan every year.  Multi-day events (like IETF60) would have a start 
>date, end date, and duration of 5 days. By specifying time, you imply

>that the event is not all-day.
>  
>
The differences between the 1st and the 3rd is that the 1st never shows
up as busy time as it has no DURATION or DTEND and therefore does not
have any time to block out.

The 3rd can show up as busy time depending  on the value of TRANSP as it
always has a DURATION or DTEND.

And the 1st  can be relative to a time zone and the 3rd is never
relative to a time zone.

So the 1st and 3rd are not the same.  OR we can call them the same
except one has a DURATION or DTEND. that may or might not have a time
zone.
Nothing is eliminated.

>I'm not convinced that everyone represents these the same way, but 
>maybe this is a case where we simply need to communicate the method 
>more clearly, show better examples, etc.  And simply clarify the text

>of the RFC.
That may be the real problem. I know of one vendor that always adds time
zone to time zone independent holidays (New years day for example).

>They exist as  anniversary, DTSTART/DTEND with time zone and 
>DTSTART/DTEND wo/time zone.
>
>All three have distinct differences:
>
>    Anniversary:
>                All day - never shows up as opaque (Birthday)
>                Has DTSTART with VALUE=DATE and does not include DTEND

>or DURATION.
>                I do not think that we can eliminate this one.
>
>    DTSTART/DTEND with TZ:
>                All day in specific time zone.  An event that consumes

>specific time
>                relative to UTC that just happens to exactly overlap 
>one day in a specific time zone.
>                This one can not be eliminated as it is really just
any

>kind of VEVENT that just
>                happens to span 24 hours.
>
>    DTSTART/DTEND with out TZ
>               All day in viewers local time.  (New Years day is local

>to viewer)
>               I do not think we can eliminate this one.
>
>So what is the conflict or addition?
>
>  
>

-- 

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

Subject: Re: [Ietf-calsify] Recommendations for stripping down iCal to a	manageable 'standard'
To: [email-masked]
From: [email-masked]
Date: Wed, 18 Aug 2004 11:28:25 -0400

Dan Winship wrote:

> > 2.1) Better examples
>
> In particular, "the last work day of the month" requires both BYDAY and
> BYSETPOS, and that should probably be expressible.
>
> Lots of holidays require multiple BY*s as well (eg, the "U.S.
> Presidential Election Day" example uses 3). But then, does anyone really
> use those? I can't imagine what a UI would look like that would let you
> create an event like that...
>
> The RRULE semantics are just awful. (See how long it takes you to
> actually generate the aforementioned election day rule.) It would be
> nice to come up with a comprehensive list of examples, covering all the
> sorts of recurrences we think the spec should cover, and then come up
> with a new, simpler recurrence rule grammar that covers that.

This is exactly why a list of time/dates sounds to me like a better option
- we avoid having to think of and provide every possible rule situation
where the reciever needs to infer what you meant when you sent the invite.
-CS

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-calsify] Time Zones
Date: Wed, 18 Aug 2004 17:34:38 +0200
To: "<[email-masked]> <[email-masked]>" <[email-masked]>

On Aug 18, 2004, at 17:24, Cameron Stillion wrote:
> Hmmm.  I'd hate to complicate recurrence patterns in all this.  Perhaps
> time zones aren't so bad, but do we really need custom ones?

What do you mean by "custom ones"?

There are three "levels" of timezone support:
a) just UTC (Zulu)
b) only fix offsets from UTC (GMT+0400) [provides no advantage]
c) political timezones (either by name or as a ruleset)

What I'm suggesting is to remove timezones and instead just add the DST 
exception intended by the event creator. The client can calculate the 
UTC relative DST range based on the political tz information it needs 
to have anyway. The transport/store doesn't need to bother anymore.
Drawback: if a political timezone changes, the cycle event is broken 
(but the same is true for rules encoded in the iCal file itself).

This approach actually doesn't complicate recurrence patterns, it makes 
them easier because the pattern processor doesn't need to consider 
timezones (and it makes all the non-cyclic stuff much easier).

IMHO its also more semantically correct, because the recurrence 
timezone is a property of the cycle calculation and not a property of 
the start/enddate of the cycle. (what happens today with clients if a 
cycle vevent specifies a different timezone for startdate and enddate? 
;-)

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

From: Jonathan Lennox <[email-masked]>
Date: Wed, 18 Aug 2004 11:30:46 -0400
To: [email-masked]
Subject: Re: [Ietf-calsify] Thoughts on some of the simplification thoughts so far
Cc: [email-masked]

On Tuesday, August 17 2004, "[email-masked]" wrote to "[email-masked]" saying:

> Elimination of recurrence rules by passing lists of date/time values back 
> and forth overlooks the advantage of using the "shorthand" of recurrence 
> rules, which allow a large list of dates and times with a short rule.

The other big advantage of recurrence rules is editability.  If you've got
an event with a rule that says "every Tuesday at 4:00", it's easy to edit
that into "every Wednesday at 11:00".  Clients have to be a whole lot
smarter in order to figure out that a long list of occurences, all of which
happen to fall on Tuesdays at 4:00, should be changed in a bunch.
(Basically, in order to edit events as a group, clients would have to
reverse-engineer RRULEs from event sets.  This seems like it could be a
nightmare for interoperability.)

That said, I'm definitely in favor of simplifying RRULEs.  (People may be
aware that I'm the author of the Call Processing Language, which re-uses
iCalendar's RRULEs to specify periods of time for time-of-day call routing.)

One property I'd very much like to see in a simplified RRULE spec: given an
RRULE and a period of time, it should be possible to determine what
instances of the RRULE fall within the period, without having to expand the
RRULE.  (I *believe* this is possible if you just eliminate COUNT and
BYSETPOS from the RRULE spec; but there are enough ugly corner cases that
I'm not positive my algorithm is correct.)

> Elimination of GEO values - I would rather see GEO be used as an index into 
> timezone data, rather than passing the timezone data along with the 
> objects, since a geographic location rather efficiently can get you the 
> timezone information. If eliminated, then I would like to see another 
> document for standardization of time zone identifiers, and only pass the 
> identifiers, not all of the time zone rules themselves.

This ought to be coordinated with the TZ list <[email-masked]>, which
maintains the Olson timezone database, the de-facto Unix standard.

-- 
Jonathan Lennox
[email-masked]

Content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify] Time Zones
Date: Wed, 18 Aug 2004 08:24:23 -0700
From: "Cameron Stillion" <[email-masked]>
To: "Helge Hess" <[email-masked]>, "Dan Winship" <[email-masked]>
Cc: [email-masked]

Hmmm.  I'd hate to complicate recurrence patterns in all this.  Perhaps
time zones aren't so bad, but do we really need custom ones?

cam

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Helge Hess
Sent: Wednesday, August 18, 2004 8:01 AM
To: Dan Winship
Cc: [email-masked]
Subject: Re: [Ietf-calsify] Time Zones

On Aug 18, 2004, at 16:50, Dan Winship wrote:
> On Wed, 2004-08-18 at 14:52 +0200, Helge Hess wrote:
>> The one place where timezones might be required are recurring events,
> Exactly so. We can't drop time zones unless we're dropping unbounded 
> recurrences as well. (Which I don't think we should.)

OK.

What do you think about attaching the timezone rule directly to the
cyclic event? The dates of the event could still be required to be
specified in UTC and the rule would just need to specify the ranges
where this the cycle is different?
This might be easier to handle by both, clients and servers?

Greets,
   Helge
--
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

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

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-calsify] Time Zones
Date: Wed, 18 Aug 2004 17:00:36 +0200
To: Dan Winship <[email-masked]>
Cc: [email-masked]

On Aug 18, 2004, at 16:50, Dan Winship wrote:
> On Wed, 2004-08-18 at 14:52 +0200, Helge Hess wrote:
>> The one place where timezones might be required are recurring events,
> Exactly so. We can't drop time zones unless we're dropping unbounded
> recurrences as well. (Which I don't think we should.)

OK.

What do you think about attaching the timezone rule directly to the 
cyclic event? The dates of the event could still be required to be 
specified in UTC and the rule would just need to specify the ranges 
where this the cycle is different?
This might be easier to handle by both, clients and servers?

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

Subject: Re: [Ietf-calsify] Time Zones
From: Dan Winship <[email-masked]>
To: Helge Hess <[email-masked]>
Date: Wed, 18 Aug 2004 10:50:24 -0400
Cc: [email-masked]

On Wed, 2004-08-18 at 14:52 +0200, Helge Hess wrote:
> The one place where timezones might be required are recurring events,

Exactly so. We can't drop time zones unless we're dropping unbounded
recurrences as well. (Which I don't think we should.)

> though I can hardly imagine that this is properly implement by any 
> client out there ;-)

There seems to be a lot of failure of imagination going on on this
list. :) There are certainly clients that implement this properly.

And I think we need to keep it in the spec. Weekly conference calls with
people in other countries that have different daylight savings time
rules than you are a fact of business life these days.

-- Dan

Date: Wed, 18 Aug 2004 07:00:03 -0600
From: "Preston Stephenson" <[email-masked]>
To: <[email-masked]>
Subject: RE: [Ietf-calsify] Recommendations for strippingdown	iCaltoa	manageable 'standard'

Sorry, I need more clarification.
I've seen UI's that put all day events in a different place than
appointments.
What is the determine factor that decides to put an appointments as an
all day event?
Being transparent (free or busy-tentative) and having a duration of a
day (or multiple days)?
If a day or multiple day event blocks time, it is displayed with other
appointments?
Transparency alone can't be the deciding factor.
Thanks.
Preston

>>> "Cameron Stillion" <[email-masked]> 08/18/04 6:02
AM >>>

It seems like whether the event shows as busy, free or tentative
should
be independent of whether it is a multi-day, single-day, all-day
event,
or just a regular old appointment.  We can make no assumptions about
the
availability based on the start or end time, the timezone association,
or whether it has hours or minutes.  Let's not make dependencies on
orthogonal properties.  

Speaking of TRANSP... This should have the same values as the
fbtypeparam. The document constantly refers to this as the free/busy
state of the event anyway, let's just make it very clear that it is
indeed the same.  And actually, the state definition which is { opaque
|
transparent } seems to imply a lot about how the client renders such
things.  It makes much more sense to me to use the { free | busy |
busy-unavailable | busy-tentative } states and let the client
applications determine how these are rendered.

I still think that the anniversary example should have a duration. 
That
is to say, either an event has an end date or a duration or both.  Why
would we default the length of an event to 1 day? It seems like an
optimization for an uncommon case.

So, we don't need a boolean for all-day property, since this can be
gleaned from DTSTART and ( DTEND or DURATION - which are mutually
exclusive, btw).

Regards,
cameron

-----Original Message-----
From: [email-masked] 
[mailto:[email-masked]] On Behalf Of Doug
Royer
Sent: Tuesday, August 17, 2004 8:42 PM
To: [email-masked] 
Subject: Re: [Ietf-calsify] Recommendations for strippingdown iCaltoa
manageable 'standard'

Cameron Stillion wrote:

>I would argue that Anniversary should include duration (one day in
most
>cases?) And also that your third case is really the same as the
first.
>In other words, New Year's Day is just an anniversary that happens on
1

>Jan every year.  Multi-day events (like IETF60) would have a start 
>date, end date, and duration of 5 days. By specifying time, you imply

>that the event is not all-day.
>  
>
The differences between the 1st and the 3rd is that the 1st never
shows
up as busy time as it has no DURATION or DTEND and therefore does not
have any time to block out.

The 3rd can show up as busy time depending  on the value of TRANSP as
it
always has a DURATION or DTEND.

And the 1st  can be relative to a time zone and the 3rd is never
relative to a time zone.

So the 1st and 3rd are not the same.  OR we can call them the same
except one has a DURATION or DTEND. that may or might not have a time
zone.
Nothing is eliminated.

>I'm not convinced that everyone represents these the same way, but 
>maybe this is a case where we simply need to communicate the method 
>more clearly, show better examples, etc.  And simply clarify the text

>of the RFC.
That may be the real problem. I know of one vendor that always adds
time
zone to time zone independent holidays (New years day for example).

>They exist as  anniversary, DTSTART/DTEND with time zone and 
>DTSTART/DTEND wo/time zone.
>
>All three have distinct differences:
>
>    Anniversary:
>                All day - never shows up as opaque (Birthday)
>                Has DTSTART with VALUE=DATE and does not include DTEND

>or DURATION.
>                I do not think that we can eliminate this one.
>
>    DTSTART/DTEND with TZ:
>                All day in specific time zone.  An event that consumes

>specific time
>                relative to UTC that just happens to exactly overlap 
>one day in a specific time zone.
>                This one can not be eliminated as it is really just
any

>kind of VEVENT that just
>                happens to span 24 hours.
>
>    DTSTART/DTEND with out TZ
>               All day in viewers local time.  (New Years day is local

>to viewer)
>               I do not think we can eliminate this one.
>
>So what is the conflict or addition?
>
>  
>

-- 

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

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-calsify] Time Zones
Date: Wed, 18 Aug 2004 14:52:30 +0200
To: "<[email-masked]> <[email-masked]>" <[email-masked]>

On Aug 18, 2004, at 14:41, Cameron Stillion wrote:
> Alternatively - what if there are only floating times and zulu times?
> All other time zone processing could be pushed to the client - is that
> too draconian?

IMHO this is the correct approach. Timezones are a "view layer" thing 
and need to be processed by the client. Allowing arbitary timezones in 
the transport or storage just produces duplicate code and the 
possibility of mismatches.

The one place where timezones might be required are recurring events, 
though I can hardly imagine that this is properly implement by any 
client out there ;-)

best regards,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

Content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify] Recommendations for stripping down iCal to amanageable 'standard'
Date: Wed, 18 Aug 2004 05:50:53 -0700
From: "Cameron Stillion" <[email-masked]>
To: "Dan Winship" <[email-masked]>
Cc: [email-masked]

Excellent points.

Concerning the multiple BY's, the fact that there exists no client
software that can actually allow the user to generate such things I
think is very telling.  Having said that, I wish that there were a
better grammar to express these things, and to support the kind of
sophisticated recurrences that are used commonly in business (payday is
the prime example).  Let's put some thought into what such a grammar
might look like. (Regular Expressions? Pseudo-code?)

Regards,
cameron

-----Original Message-----
From: Dan Winship [mailto:[email-masked]] 
Sent: Tuesday, August 17, 2004 3:36 PM
To: Cameron Stillion
Cc: [email-masked]
Subject: Re: [Ietf-calsify] Recommendations for stripping down iCal to
amanageable 'standard'

On Mon, 2004-08-16 at 20:35 -0400, Cameron Stillion wrote:
> 1.3) eCal Scale
> 
> It has also been recommended that the standard be limited to 
> "Gregorian" calendar support.  I suggest that other types of calendars

> will require different schemas and should therefore be handled in 
> different standards... IF they are desirable in the future.  This 
> standard should deal exclusively in Gregorian dates, in my opinion.

But really, the standard already does deal exclusively in Gregorian
dates. YYYYMMDD won't cut it in a calendar system where some days aren't
part of any month, or there are mid-year leap months that change the
month numbering. So dropping CALSCALE isn't going to let us simplify
anything anywhere else in the spec.

What it would mean, would be that if someone did later come up with an
Islamic calendar standard, that they'd have to have the calendars start
with "BEGIN:VISLAMICCALENDAR" or something, rather than "BEGIN:VCALENDAR
CALSCALE:ISLAMIC". Which means that clients would only be able to say "I
have no idea at all what this data is" rather than "I can't import this
calendar data because it uses dates from a non-Gregorian calendar
system."

So I vote for keeping CALSCALE, but clarifying that we have no idea what
non-GREGORIAN calendar data would look like, and that clients shouldn't
even try to parse a VCALENDAR object if they don't recognize its
CALSCALE.

> 2) Simplify recurrences
> 
> Nathaniel suggested in San Diego a rather severe approach which 
> included doing away completely with recurrence rules.

Boo! But I agree they should be simplified.

> I also recommend that we disallow multiple BY*'s in one FREQ.

Hm... I think that needs to be considered at the same time as:

> 2.1) Better examples

In particular, "the last work day of the month" requires both BYDAY and
BYSETPOS, and that should probably be expressible.

Lots of holidays require multiple BY*s as well (eg, the "U.S.
Presidential Election Day" example uses 3). But then, does anyone really
use those? I can't imagine what a UI would look like that would let you
create an event like that...

The RRULE semantics are just awful. (See how long it takes you to
actually generate the aforementioned election day rule.) It would be
nice to come up with a comprehensive list of examples, covering all the
sorts of recurrences we think the spec should cover, and then come up
with a new, simpler recurrence rule grammar that covers that.

> 3) Simplify exceptions
> 
> I propose that exceptions be exclusively one-off events, never 
> recurrences themselves.

Seems reasonable.

-- Dan

Content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify] Time Zones
Date: Wed, 18 Aug 2004 05:41:12 -0700
From: "Cameron Stillion" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: 

I think time zones are more easily mapped to time deltas than GEOs...
for probalby every client and system.  But I've heard other requests to
standardize and simplify the timezone story.  Here's a radical idea -
what if we only used the military time zone references? These are fairly
standard (within one community, anyway).  We have adopted Zulu pretty
readily, how about we just go with the rest of the alphabetic standard?
For those interested, here it is:

A : UTC+1
B : UTC+2
C : UTC+3
D : UTC+4
E : UTC+5
F : UTC+6
G : UTC+7
H : UTC+8
I : UTC+9
K : UTC+10
L : UTC+11
M : UTC+12
N : UTC-1
O : UTC-2
P : UTC-3
Q : UTC-4
R : UTC-5
S : UTC-6
T : UTC-7
U : UTC-8
V : UTC-9
W : UTC-10
X : UTC-11
Y : UTC-12
Z : UTC

(for those curious about why Juliet was left out...? It's not about the
tragic Capulet, but the tragic army officer named Custer, and the army's
inability to forgive him...)

Alternatively - what if there are only floating times and zulu times?
All other time zone processing could be pushed to the client - is that
too draconian? 

Also... concerning GetCapabilities - that doesn't necessarily work for a
standalone .ics file that I publish to a website... But I completely
agree with your assessment of RRULE as a means of communicating a vast
recurrence set tersely.  This is why I think we should not completely do
away with it, but rather simplify it.

Regards,
cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, August 17, 2004 8:37 PM
To: [email-masked]
Subject: [Ietf-calsify] Thoughts on some of the simplification thoughts
sofar

If you start breaking out VTODOs, VJOURNALs, or whatever, then perhaps
you're on a path where you have a multi-layered standard:

         Layer 0 would be representation of the "generic" parts of the
object (DTSTAMP, UID, DTSTART(?) etc.)
         Layer 1 would be representation of specific items, perhaps one
standard per VEVENT/VTODO/VJOURNAL, etc.

Endpoints of a calendaring conversation would have to either identify
what objects they could deal with, or issue errors when passed an object
they couldn't, or both.

Elimination of recurrence rules by passing lists of date/time values
back and forth overlooks the advantage of using the "shorthand" of
recurrence rules, which allow a large list of dates and times with a
short rule. I'm not arguing for or against, just making a point that I
hadn't heard expressed.  If you end wanting both possibilities, you have
to have a discovery mechanism to see what the other end handles. This, I
think, is at least partly handled by the "expand recurrence" property
which is returned in the GET-CAPABILITY response (I think).

Elimination of GEO values - I would rather see GEO be used as an index
into timezone data, rather than passing the timezone data along with the
objects, since a geographic location rather efficiently can get you the
timezone information. If eliminated, then I would like to see another
document for standardization of time zone identifiers, and only pass the
identifiers, not all of the time zone rules themselves.

Tim Hare
Interested Bystander, Non-Inc. 

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

Content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify] PIM Data Types
Date: Wed, 18 Aug 2004 05:27:16 -0700
From: "Cameron Stillion" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: 

Well said.  I think that in reality, we have this situation today
already. Contact information is (somewhat) commonly transported through
a completely different standard - vCard (RFC 2426).  This standard is
remarkably similar to iCal, but that is not surprising given the common
beginnings (vCal, et.al. from versit technologies...)

I don't actually know what the status of vCard proposed standard is, but
obviously there is interest enough for a proposed standard to exist for
that PIM data type. Unfortunately, vCard uses slightly different
schematization for dates, time zones, etc. <aside: I would welcome an
effort similar to CALCIFY for contact data once we've brought
calendaring to a standard that we all feel pretty good about.../>

These separate standards should be brought into harmony so that separate
parsing engines do not have to be built for each one, but many basic
elements can be reused.  There also needs to be specification for
interoperability between these formats.  

For example, I need to be able to specify that a particular calendar
that I have published to my website is My Personal free/busy
information, or My Personal Schedule, and not just an IETF 60 calendar
that I put together for everyone's use. This implies that the calendar
have a property that links it to a contact (me) - and I would argue
vCard is the right general direction for that.  Likewise, I might want a
link from inside the vCard to my personal free/busy .ics so that when I
share my contact with someone, they can also schedule me for meetings. 

Similar situations exist with tasks, and other PIM data types.  We
should specify each of these data types in separate documents, using the
same basic underlying property types and schematization.  If there is
sufficient interest in publishing these data types and interoperating
between applications with them, then those documents will naturally move
along the standards track.  Adding links and interoperability of
multiple PIM data types should be built upon the standards.

Regards,
cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, August 17, 2004 8:37 PM
To: [email-masked]
Subject: [Ietf-calsify] Thoughts on some of the simplification thoughts
sofar

If you start breaking out VTODOs, VJOURNALs, or whatever, then perhaps
you're on a path where you have a multi-layered standard:

         Layer 0 would be representation of the "generic" parts of the
object (DTSTAMP, UID, DTSTART(?) etc.)
         Layer 1 would be representation of specific items, perhaps one
standard per VEVENT/VTODO/VJOURNAL, etc.

Endpoints of a calendaring conversation would have to either identify
what objects they could deal with, or issue errors when passed an object
they couldn't, or both.

Elimination of recurrence rules by passing lists of date/time values
back and forth overlooks the advantage of using the "shorthand" of
recurrence rules, which allow a large list of dates and times with a
short rule. I'm not arguing for or against, just making a point that I
hadn't heard expressed.  If you end wanting both possibilities, you have
to have a discovery mechanism to see what the other end handles. This, I
think, is at least partly handled by the "expand recurrence" property
which is returned in the GET-CAPABILITY response (I think).

Elimination of GEO values - I would rather see GEO be used as an index
into timezone data, rather than passing the timezone data along with the
objects, since a geographic location rather efficiently can get you the
timezone information. If eliminated, then I would like to see another
document for standardization of time zone identifiers, and only pass the
identifiers, not all of the time zone rules themselves.

Tim Hare
Interested Bystander, Non-Inc. 

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

Subject: RE: [Ietf-calsify] Recommendations for strippingdown	iCaltoa	manageable 'standard'
Date: Wed, 18 Aug 2004 05:02:07 -0700
Content-class: urn:content-classes:message
From: "Cameron Stillion" <[email-masked]>
To: <[email-masked]>

It seems like whether the event shows as busy, free or tentative should
be independent of whether it is a multi-day, single-day, all-day event,
or just a regular old appointment.  We can make no assumptions about the
availability based on the start or end time, the timezone association,
or whether it has hours or minutes.  Let's not make dependencies on
orthogonal properties.  

Speaking of TRANSP... This should have the same values as the
fbtypeparam. The document constantly refers to this as the free/busy
state of the event anyway, let's just make it very clear that it is
indeed the same.  And actually, the state definition which is { opaque |
transparent } seems to imply a lot about how the client renders such
things.  It makes much more sense to me to use the { free | busy |
busy-unavailable | busy-tentative } states and let the client
applications determine how these are rendered.

I still think that the anniversary example should have a duration.  That
is to say, either an event has an end date or a duration or both.  Why
would we default the length of an event to 1 day? It seems like an
optimization for an uncommon case.

So, we don't need a boolean for all-day property, since this can be
gleaned from DTSTART and ( DTEND or DURATION - which are mutually
exclusive, btw).

Regards,
cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Doug Royer
Sent: Tuesday, August 17, 2004 8:42 PM
To: [email-masked]
Subject: Re: [Ietf-calsify] Recommendations for strippingdown iCaltoa
manageable 'standard'

Cameron Stillion wrote:

>I would argue that Anniversary should include duration (one day in most
>cases?) And also that your third case is really the same as the first.
>In other words, New Year's Day is just an anniversary that happens on 1

>Jan every year.  Multi-day events (like IETF60) would have a start 
>date, end date, and duration of 5 days. By specifying time, you imply 
>that the event is not all-day.
>  
>
The differences between the 1st and the 3rd is that the 1st never shows
up as busy time as it has no DURATION or DTEND and therefore does not
have any time to block out.

The 3rd can show up as busy time depending  on the value of TRANSP as it
always has a DURATION or DTEND.

And the 1st  can be relative to a time zone and the 3rd is never
relative to a time zone.

So the 1st and 3rd are not the same.  OR we can call them the same
except one has a DURATION or DTEND. that may or might not have a time
zone.
Nothing is eliminated.

>I'm not convinced that everyone represents these the same way, but 
>maybe this is a case where we simply need to communicate the method 
>more clearly, show better examples, etc.  And simply clarify the text 
>of the RFC.
>
That may be the real problem. I know of one vendor that always adds time
zone to time zone independent holidays (New years day for example).

>They exist as  anniversary, DTSTART/DTEND with time zone and 
>DTSTART/DTEND wo/time zone.
>
>All three have distinct differences:
>
>    Anniversary:
>                All day - never shows up as opaque (Birthday)
>                Has DTSTART with VALUE=DATE and does not include DTEND 
>or DURATION.
>                I do not think that we can eliminate this one.
>
>    DTSTART/DTEND with TZ:
>                All day in specific time zone.  An event that consumes 
>specific time
>                relative to UTC that just happens to exactly overlap 
>one day in a specific time zone.
>                This one can not be eliminated as it is really just any

>kind of VEVENT that just
>                happens to span 24 hours.
>
>    DTSTART/DTEND with out TZ
>               All day in viewers local time.  (New Years day is local 
>to viewer)
>               I do not think we can eliminate this one.
>
>So what is the conflict or addition?
>
>  
>

-- 

Date: Tue, 17 Aug 2004 23:36:52 -0400
To: [email-masked]
From: [email-masked]
Subject: [Ietf-calsify] Thoughts on some of the simplification thoughts so far

If you start breaking out VTODOs, VJOURNALs, or whatever, then perhaps 
you're on a path where you have a multi-layered standard:

         Layer 0 would be representation of the "generic" parts of the 
object (DTSTAMP, UID, DTSTART(?) etc.)
         Layer 1 would be representation of specific items, perhaps one 
standard per VEVENT/VTODO/VJOURNAL, etc.

Endpoints of a calendaring conversation would have to either identify what 
objects they could deal with, or issue errors when passed an object they 
couldn't, or both.

Elimination of recurrence rules by passing lists of date/time values back 
and forth overlooks the advantage of using the "shorthand" of recurrence 
rules, which allow a large list of dates and times with a short rule. I'm 
not arguing for or against, just making a point that I hadn't heard 
expressed.  If you end wanting both possibilities, you have to have a 
discovery mechanism to see what the other end handles. This, I think, is at 
least partly handled by the "expand recurrence" property which is returned 
in the GET-CAPABILITY response (I think).

Elimination of GEO values - I would rather see GEO be used as an index into 
timezone data, rather than passing the timezone data along with the 
objects, since a geographic location rather efficiently can get you the 
timezone information. If eliminated, then I would like to see another 
document for standardization of time zone identifiers, and only pass the 
identifiers, not all of the time zone rules themselves.

Tim Hare
Interested Bystander, Non-Inc. 

Date: Tue, 17 Aug 2004 21:41:44 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Recommendations for stripping down	iCaltoa	manageable 'standard'
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Wed, 18 Aug 2004 03:42:01 -0000

This is a cryptographically signed message in MIME format.

--------------ms050102090500060602090305
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Cameron Stillion wrote:

>I would argue that Anniversary should include duration (one day in most
>cases?) And also that your third case is really the same as the first.
>In other words, New Year's Day is just an anniversary that happens on 1
>Jan every year.  Multi-day events (like IETF60) would have a start date,
>end date, and duration of 5 days. By specifying time, you imply that the
>event is not all-day.
>  
>
The differences between the 1st and the 3rd is that the 1st never shows up
as busy time as it has no DURATION or DTEND and therefore does not
have any time to block out.

The 3rd can show up as busy time depending  on the value of TRANSP as it 
always
has a DURATION or DTEND.

And the 1st  can be relative to a time zone and the 3rd is never 
relative to a time zone.

So the 1st and 3rd are not the same.  OR we can call them the same except
one has a DURATION or DTEND. that may or might not have a time zone.
Nothing is eliminated.

>I'm not convinced that everyone represents these the same way, but maybe
>this is a case where we simply need to communicate the method more
>clearly, show better examples, etc.  And simply clarify the text of the
>RFC.
>
That may be the real problem. I know of one vendor that always adds time 
zone
to time zone independent holidays (New years day for example).

>They exist as  anniversary, DTSTART/DTEND with time zone and
>DTSTART/DTEND wo/time zone.
>
>All three have distinct differences:
>
>    Anniversary:
>                All day - never shows up as opaque (Birthday)
>                Has DTSTART with VALUE=DATE and does not include DTEND
>or DURATION.
>                I do not think that we can eliminate this one.
>
>    DTSTART/DTEND with TZ:
>                All day in specific time zone.  An event that consumes
>specific time
>                relative to UTC that just happens to exactly overlap one
>day in a specific time zone.
>                This one can not be eliminated as it is really just any
>kind of VEVENT that just
>                happens to span 24 hours.
>
>    DTSTART/DTEND with out TZ
>               All day in viewers local time.  (New Years day is local
>to viewer)
>               I do not think we can eliminate this one.
>
>So what is the conflict or addition?
>
>  
>

-- 

--------------ms050102090500060602090305
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms050102090500060602090305--

Content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify] Recommendations for stripping down iCaltoa	manageable 'standard'
Date: Tue, 17 Aug 2004 20:00:31 -0700
From: "Cameron Stillion" <[email-masked]>
To: <[email-masked]>

I would argue that Anniversary should include duration (one day in most
cases?) And also that your third case is really the same as the first.
In other words, New Year's Day is just an anniversary that happens on 1
Jan every year.  Multi-day events (like IETF60) would have a start date,
end date, and duration of 5 days. By specifying time, you imply that the
event is not all-day.

I'm not convinced that everyone represents these the same way, but maybe
this is a case where we simply need to communicate the method more
clearly, show better examples, etc.  And simply clarify the text of the
RFC.

Is this reasonable?

camerost 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Doug Royer
Sent: Tuesday, August 17, 2004 1:41 PM
To: [email-masked]
Subject: Re: [Ietf-calsify] Recommendations for stripping down iCaltoa
manageable 'standard'

Cameron Stillion wrote:

>I'd love to see a property for all-day events, but that implies adding 
>to our standard.  Perhaps there's an x- prop that we can encourage use 
>of? A boolean property makes more sense to me than specifying midnight 
>to midnight or a time range of zero.  It is resilient to time zone 
>calculations.
>
>Does anyone else feel strongly about all-day events?
>
They exist as  anniversary, DTSTART/DTEND with time zone and
DTSTART/DTEND wo/time zone.

All three have distinct differences:

    Anniversary:
                All day - never shows up as opaque (Birthday)
                Has DTSTART with VALUE=DATE and does not include DTEND
or DURATION.
                I do not think that we can eliminate this one.

    DTSTART/DTEND with TZ:
                All day in specific time zone.  An event that consumes
specific time
                relative to UTC that just happens to exactly overlap one
day in a specific time zone.
                This one can not be eliminated as it is really just any
kind of VEVENT that just
                happens to span 24 hours.

    DTSTART/DTEND with out TZ
               All day in viewers local time.  (New Years day is local
to viewer)
               I do not think we can eliminate this one.

So what is the conflict or addition?

-- 

Subject: Re: [Ietf-calsify] Recommendations for stripping down iCal to a manageable 'standard'
From: Dan Winship <[email-masked]>
To: Cameron Stillion <[email-masked]>
Date: Tue, 17 Aug 2004 18:36:12 -0400
Cc: [email-masked]

On Mon, 2004-08-16 at 20:35 -0400, Cameron Stillion wrote:
> 1.3) eCal Scale
> 
> It has also been recommended that the standard be limited to
> "Gregorian" calendar support.  I suggest that other types of calendars
> will require different schemas and should therefore be handled in
> different standards... IF they are desirable in the future.  This
> standard should deal exclusively in Gregorian dates, in my opinion.

But really, the standard already does deal exclusively in Gregorian
dates. YYYYMMDD won't cut it in a calendar system where some days aren't
part of any month, or there are mid-year leap months that change the
month numbering. So dropping CALSCALE isn't going to let us simplify
anything anywhere else in the spec.

What it would mean, would be that if someone did later come up with an
Islamic calendar standard, that they'd have to have the calendars start
with "BEGIN:VISLAMICCALENDAR" or something, rather than "BEGIN:VCALENDAR
CALSCALE:ISLAMIC". Which means that clients would only be able to say "I
have no idea at all what this data is" rather than "I can't import this
calendar data because it uses dates from a non-Gregorian calendar
system."

So I vote for keeping CALSCALE, but clarifying that we have no idea what
non-GREGORIAN calendar data would look like, and that clients shouldn't
even try to parse a VCALENDAR object if they don't recognize its
CALSCALE.

> 2) Simplify recurrences
> 
> Nathaniel suggested in San Diego a rather severe approach which
> included doing away completely with recurrence rules.

Boo! But I agree they should be simplified.

> I also recommend that we disallow multiple BY*'s in one FREQ.

Hm... I think that needs to be considered at the same time as:

> 2.1) Better examples

In particular, "the last work day of the month" requires both BYDAY and
BYSETPOS, and that should probably be expressible.

Lots of holidays require multiple BY*s as well (eg, the "U.S.
Presidential Election Day" example uses 3). But then, does anyone really
use those? I can't imagine what a UI would look like that would let you
create an event like that...

The RRULE semantics are just awful. (See how long it takes you to
actually generate the aforementioned election day rule.) It would be
nice to come up with a comprehensive list of examples, covering all the
sorts of recurrences we think the spec should cover, and then come up
with a new, simpler recurrence rule grammar that covers that.

> 3) Simplify exceptions
> 
> I propose that exceptions be exclusively one-off events, never
> recurrences themselves.

Seems reasonable.

-- Dan

Date: Tue, 17 Aug 2004 14:14:00 -0700
From: Satya Vempati <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] Event class

This is a multi-part message in MIME format...

--14140625-17188-1092777241=:1868
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-Disposition: inline

Another area in need of simplification/better explanation is the event clas=
s: PUBLIC/PRIVATE/CONFIDENTIAL.
=20
The spec does not clearly define what each value means.

--14140625-17188-1092777241=:1868--

Subject: RE: [Ietf-calsify] Just for the record. Notes has a full implementationof VTODOs
From: Dan Winship <[email-masked]>
To: Cameron Stillion <[email-masked]>
Date: Tue, 17 Aug 2004 17:04:43 -0400
Cc: [email-masked]

On Tue, 2004-08-17 at 12:27 -0700, Cameron Stillion wrote:
> I realize there are actually a few vendors out there who have actually
> put the time and effort into implementing VTODO from the previously
> proposed standard.  I question whether this investment was made in
> response to users clamoring for more task-management features from
> calendaring systems, or if it was done simply because it happens to be
> in the spec.  I know of no web sites that publish task lists using this
> mechanism, no clients that even propose to interoperate in this way.

Lots of clients and servers that were written post-2445 use VTODO as
their native task data format (eg Evolution, Apple's iCal) and some
actually even do VTODO-over-iMIP and such. I think we should probably
keep VTODO, though maybe in a separate document as Doug suggested. (And
I also agree with your later post, that it really seems like some of the
existing VTODO features were just copied over from VEVENT "because we
can", and should be rethought.)

-- Dan

Subject: RE: [Ietf-calsify] Recommendations for stripping down iCal toa	manageable 'standard'
To: [email-masked]
From: [email-masked]
Date: Tue, 17 Aug 2004 16:34:53 -0400

Cameron Stillion wrote on 08/17/2004 04:10:03 PM:

> I'd love to see a property for all-day events, but that implies adding
> to our standard.  Perhaps there's an x- prop that we can encourage use
> of? A boolean property makes more sense to me than specifying midnight
> to midnight or a time range of zero.  It is resilient to time zone
> calculations.
>
> Does anyone else feel strongly about all-day events?
>
>
> Cam

I agree that All Day Events need some sort of additional property.  These
can get tricky and if we can quickly figure out it's an All Day Event, that
would help implementors decide what to do with it (without first parsing
the time/date objects, etc.)
-CS

Date: Tue, 17 Aug 2004 14:41:27 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Recommendations for stripping down iCal toa	manageable 'standard'
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Tue, 17 Aug 2004 20:41:39 -0000

This is a cryptographically signed message in MIME format.

--------------ms020002000105000705030804
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Cameron Stillion wrote:

>I'd love to see a property for all-day events, but that implies adding
>to our standard.  Perhaps there's an x- prop that we can encourage use
>of? A boolean property makes more sense to me than specifying midnight
>to midnight or a time range of zero.  It is resilient to time zone
>calculations.
>
>Does anyone else feel strongly about all-day events?
>
They exist as  anniversary, DTSTART/DTEND with time zone and
DTSTART/DTEND wo/time zone.

All three have distinct differences:

    Anniversary:
                All day - never shows up as opaque (Birthday)
                Has DTSTART with VALUE=DATE and does not include DTEND 
or DURATION.
                I do not think that we can eliminate this one.

    DTSTART/DTEND with TZ:
                All day in specific time zone.  An event that consumes 
specific time
                relative to UTC that just happens to exactly overlap one 
day in a specific time zone.
                This one can not be eliminated as it is really just any 
kind of VEVENT that just
                happens to span 24 hours.

    DTSTART/DTEND with out TZ
               All day in viewers local time.  (New Years day is local 
to viewer)
               I do not think we can eliminate this one.

So what is the conflict or addition?

-- 

--------------ms020002000105000705030804
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms020002000105000705030804--

From: Cornelius Schumacher <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Just for the record. Notes has a =?iso-8859-1?q?full=09implementationof?= VTODOs
Date: Tue, 17 Aug 2004 22:30:08 +0200

On Tuesday 17 August 2004 21:39, [email-masked] wrote:
> I disagree.  There is very little diffence between the VTODO and the
> VCALENDAR.  Both have the same repeat behavior and attendee
> information. The only difference is that the VTODO has a few
> additional response states.
>
> I have no problem with removing journal entries, since these are
> basically different than a Calendar or group todo.  Also I do not
> know of any implimentors.

KDE has an implementation of iCalendar journal entries. 

> Has anybody implimented iTip VFREEBUSY requests?

KDE also implements this.

In general I would like to see at least the todos but preferably also 
the journal entries stay in the standard to avoid any further 
fragmentation. Most organizer applications handle these kind of objects 
anyway, so why have another standard for them?

-- 
Cornelius Schumacher <[email-masked]>

Subject: Re: [Ietf-calsify] Re: RRULEs
To: [email-masked]
From: [email-masked]
Date: Tue, 17 Aug 2004 16:20:53 -0400

Doug Royer  wrote on 08/17/2004 02:53:31 PM:

> >I disagree.  I think Rules should go.  Why not take out the complexity
of
> >recurrences and have the standard dictate that the vendor must send a
list
> >of dates, and optionally send a recurrence rule (for UI purposes or
maybe
> >for handheld devices)?  This way the recipient does not have to infer
what
> >the rule meant, but can simply put the sent dates on the calendar.
> >
> Standing staff meeting every Monday at 2pm. The argument for not being
able
> to have unbounded instances is the problem. What limit? How many means
> forever?
> Or do we add a new unbound property or parameter. Then we are back to
some
> version of rrule.
>
> Currently multiple RRULE properties are allowed per object. I think that
> needs to go at a minimum.

Yes - infinitely recurring meetings would no longer be supported. There
would simply be no way to express that in a list of time/dates, unless, as
you said, we fell back to sending a rule as well.

What about just getting rid of infinite recurrences?

> >I really think this is worthwhile to consider if you take it step
further -
> >to reschedules.  This is where each vendor does their own thing
> >(currently).  That's ok, so long as we're all sending the same basic
data,
> >but we're not.  If we sent the exact dates that we want rescheduled, and
> >the exact dates that we want rescheduled to, we'd solve alot of basic
> >rescheduling interop problems.
> >
> Yes. TOSS all of the iTIP complexity. Simply send replacement objects.
> That's one
> method of updating objects that works for all vendors already. Keep the
> same UID
> and update the SEQ values, send new objects. Simplifies all of that mess.

Right - and think of this: the vendor can still have multiple Rules,
exceptions, etc. in their UI, but what they send has to be the
consolidation of all of that in a list of time/dates...
-CS

Date: Tue, 17 Aug 2004 14:26:06 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Just for the record. Notes has a full	implementationof VTODOs
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Tue, 17 Aug 2004 20:26:20 -0000

This is a cryptographically signed message in MIME format.

--------------ms040302030707040407030003
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Lisa Dusseault wrote:

> I think Cameron may be right, even though I'd like to see a standard 
> for Todo item schema.  Therefore, I'd be willing to work on it 
> separately.  It might be an extremely simple separate spec if a todo 
> is actually nearly a subset of a VEVENT -- the separate spec could 
> reuse almost everything from VEVENT and define almost nothing new. 

I think that is an excellent idea. We all agree that VEVENT is necessary.

A VEVENT + VCALENDAR draft, a VTODO draft and a VJOURNAL draft (if 
anyone wants it).

iCal was designed to be extendable. By breaking these apart each one can 
make
standard status or fade out.

-- 

--------------ms040302030707040407030003
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms040302030707040407030003--

Date: Tue, 17 Aug 2004 14:25:12 -0600
From: "Preston Stephenson" <[email-masked]>
To: <[email-masked]>
Subject: RE: [Ietf-calsify] Just for the record. Notes has a full	implementationof VTODOs

Are VFREEBUSY requests on the table?
There was a discussion of iTip VFREEBUSY in CAP.
There were opposing views a how it should look/work.
We (GroupWise) have had VFREEBUSY internally for 10+ years.
We don't expose the VFREEBUSY to external users, yet.
We were looking to expose it in a standard's way.
That's also why I asked about the VTODO's and VJOURNAL.
We've had similar concepts for some time and was looking for a way to
expose it.
If the consensus is to only do VEVENTS, that's fine.
Preston

>>> <[email-masked]> 08/17/04 1:39 PM >>>
I disagree.  There is very little diffence between the VTODO and the 
VCALENDAR.  Both have the same repeat behavior and attendee
information. 
The only difference is that the VTODO has a few additional response 
states.

I have no problem with removing journal entries, since these are
basically 
different than a Calendar or group todo.  Also I do not know of any 
implimentors.

Has anybody implimented iTip VFREEBUSY requests?

"Cameron Stillion" <[email-masked]> 
Sent by: [email-masked] 
08/17/2004 03:27 PM

To
<[email-masked]>, <[email-masked]>
cc

Subject
RE: [Ietf-calsify] Just for the record. Notes has a full
implementationof 
VTODOs

I realize there are actually a few vendors out there who have actually
put the time and effort into implementing VTODO from the previously
proposed standard.  I question whether this investment was made in
response to users clamoring for more task-management features from
calendaring systems, or if it was done simply because it happens to be
in the spec.  I know of no web sites that publish task lists using
this
mechanism, no clients that even propose to interoperate in this way.
 
Also, I think it is clearly outside the scope of this standard (and
indeed this working group) to attempt to define a standard schema for
ALL OTHER PIM DATA TYPES.  I suggest that one of the mistakes made by
previous attempts to bring iCal to standard is that they tried to
extend
the notion of a calendar data type to include task items and journal
items, which are different beasts, and should be treated differently.
They have different schemas, different semantics, and applications who
want to communicate using such data types will have very different
requirements for those data types.
 
I suggest that we stick to calendaring exclusively.  Removing support
for VTODO and VJOURNAL will hurt very few if any clients.  Systems
that
have implemented a means of parsing or generating these datatypes, I
would argue, have no compelling interoperability scenario or clear
user
features compelling in the space we are working in.  If there is
sufficient interest in specifying such data structures, I suggest that
separate working groups and separate documents be created to bring
these
Task and Journal schemas into the standards process.
 
If we try to take on the whole PIM data enchilada, I believe we will
fail as have previous attempts to make calendaring and scheduling
schemas and systems speak a standard language. 
 
camerost 

________________________________

From: [email-masked] 
[mailto:[email-masked]] On Behalf Of
[email-masked] 
Sent: Tuesday, August 17, 2004 7:50 AM
To: [email-masked] 
Subject: [Ietf-calsify] Just for the record. Notes has a full
implementationof VTODOs

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

Content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify] Just for the record. Notes has a full	implementationof VTODOs
Date: Tue, 17 Aug 2004 13:15:30 -0700
From: "Cameron Stillion" <[email-masked]>
To: <[email-masked]>
Cc: [email-masked], [email-masked]

This is a multi-part message in MIME format...

------=_NextPartTM-000-0dafe423-90ba-4e9f-8d34-ebc77a16bf4b
Content-Type: multipart/alternative; boundary="----------=_1092773734-13492-2"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.411 (Entity 5.404)

This is a multi-part message in MIME format...

------------=_1092773734-13492-2
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Perhaps for your application.  Not in my experience in any of the PIMs I
have worked on.  Tasks typically do not have attendees.  They instead
have the notion of assignment, but typically it is limited to a single
person.  Some repeat, but some regenerate, and sometimes they rollover.
They have priority whereas events do not.  Philosophically, they
represent discretionary time whereas events represent non-discretionary
time.  They have very different notions in different applications and
systems.  Tasks cannot be easily shoehorned into the event schema.   It
would be easy to say that journal items are just like events that have
passed... but again, I think they have different semantics, different
client functionality, and very different schemas.
=20
camerost=20
=20

________________________________

From: [email-masked]
[mailto:[email-masked]]=20
Sent: Tuesday, August 17, 2004 12:39 PM
To: Cameron Stillion
Cc: [email-masked];
[email-masked]
Subject: RE: [Ietf-calsify] Just for the record. Notes has a full
implementationof VTODOs

I disagree.  There is very little diffence between the VTODO and the
VCALENDAR.  Both have the same repeat behavior and attendee information.
The only difference is that the VTODO has a few additional response
states.=20

I have no problem with removing journal entries, since these are
basically different than a Calendar or group todo.  Also I do not know
of any implimentors.=20

Has anybody implimented iTip VFREEBUSY requests?=20

"Cameron Stillion" <[email-masked]>=20
Sent by: [email-masked]=20

08/17/2004 03:27 PM=20

To
<[email-masked]>, <[email-masked]>=20
cc
Subject
RE: [Ietf-calsify] Just for the record. Notes has a full
implementationof VTODOs

=09

I realize there are actually a few vendors out there who have actually
put the time and effort into implementing VTODO from the previously
proposed standard.  I question whether this investment was made in
response to users clamoring for more task-management features from
calendaring systems, or if it was done simply because it happens to be
in the spec.  I know of no web sites that publish task lists using this
mechanism, no clients that even propose to interoperate in this way.

Also, I think it is clearly outside the scope of this standard (and
indeed this working group) to attempt to define a standard schema for
ALL OTHER PIM DATA TYPES.  I suggest that one of the mistakes made by
previous attempts to bring iCal to standard is that they tried to extend
the notion of a calendar data type to include task items and journal
items, which are different beasts, and should be treated differently.
They have different schemas, different semantics, and applications who
want to communicate using such data types will have very different
requirements for those data types.

I suggest that we stick to calendaring exclusively.  Removing support
for VTODO and VJOURNAL will hurt very few if any clients.  Systems that
have implemented a means of parsing or generating these datatypes, I
would argue, have no compelling interoperability scenario or clear user
features compelling in the space we are working in.  If there is
sufficient interest in specifying such data structures, I suggest that
separate working groups and separate documents be created to bring these
Task and Journal schemas into the standards process.

If we try to take on the whole PIM data enchilada, I believe we will
fail as have previous attempts to make calendaring and scheduling
schemas and systems speak a standard language.=20=20

camerost=20

________________________________

From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, August 17, 2004 7:50 AM
To: [email-masked]
Subject: [Ietf-calsify] Just for the record. Notes has a full
implementationof VTODOs

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

------------=_1092773734-13492-2--

------=_NextPartTM-000-0dafe423-90ba-4e9f-8d34-ebc77a16bf4b--

Content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify] Recommendations for stripping down iCal toa manageable 'standard'
Date: Tue, 17 Aug 2004 13:10:03 -0700
From: "Cameron Stillion" <[email-masked]>
To: "Preston Stephenson" <[email-masked]>, <[email-masked]>
Cc: 

I'd love to see a property for all-day events, but that implies adding
to our standard.  Perhaps there's an x- prop that we can encourage use
of? A boolean property makes more sense to me than specifying midnight
to midnight or a time range of zero.  It is resilient to time zone
calculations.

Does anyone else feel strongly about all-day events?

Cam

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Preston
Stephenson
Sent: Tuesday, August 17, 2004 11:35 AM
To: [email-masked]
Subject: Re: [Ietf-calsify] Recommendations for stripping down iCal toa
manageable 'standard'

>1.1) Limit Schema Support
>
>As a non-goal, I suggest that our purpose is NOT to define a schema
for
>all types of PIM data -  specifically, journal items, task items,
etc.
>Other data types like those mentioned should be specified in OTHER 
>standards.  This means removing VJOURNAL and VTODO from this
document.

Do you think it will add too much complexity to support VJOURNAL and
VTODO?

They are usually simpler than VEVENT's.
It wouldn't seem that more difficult to support all three.
Are we going to come up with a definition of an all-day event?
I've seen it handled multiple ways.

Thanks.
Preston

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

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-calsify] Just for the record. Notes has a full implementationof VTODOs
Date: Tue, 17 Aug 2004 12:45:35 -0700
To: "Cameron Stillion" <[email-masked]>
Cc: [email-masked]

I think Cameron may be right, even though I'd like to see a standard 
for Todo item schema.  Therefore, I'd be willing to work on it 
separately.  It might be an extremely simple separate spec if a todo is 
actually nearly a subset of a VEVENT -- the separate spec could reuse 
almost everything from VEVENT and define almost nothing new.

Lisa

On Aug 17, 2004, at 12:27 PM, Cameron Stillion wrote:

> I realize there are actually a few vendors out there who have actually
> put the time and effort into implementing VTODO from the previously
> proposed standard.  I question whether this investment was made in
> response to users clamoring for more task-management features from
> calendaring systems, or if it was done simply because it happens to be
> in the spec.  I know of no web sites that publish task lists using this
> mechanism, no clients that even propose to interoperate in this way.
>
> Also, I think it is clearly outside the scope of this standard (and
> indeed this working group) to attempt to define a standard schema for
> ALL OTHER PIM DATA TYPES.  I suggest that one of the mistakes made by
> previous attempts to bring iCal to standard is that they tried to 
> extend
> the notion of a calendar data type to include task items and journal
> items, which are different beasts, and should be treated differently.
> They have different schemas, different semantics, and applications who
> want to communicate using such data types will have very different
> requirements for those data types.
>
> I suggest that we stick to calendaring exclusively.  Removing support
> for VTODO and VJOURNAL will hurt very few if any clients.  Systems that
> have implemented a means of parsing or generating these datatypes, I
> would argue, have no compelling interoperability scenario or clear user
> features compelling in the space we are working in.  If there is
> sufficient interest in specifying such data structures, I suggest that
> separate working groups and separate documents be created to bring 
> these
> Task and Journal schemas into the standards process.
>
> If we try to take on the whole PIM data enchilada, I believe we will
> fail as have previous attempts to make calendaring and scheduling
> schemas and systems speak a standard language.
>
> camerost
>
>
> ________________________________
>
> [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Tuesday, August 17, 2004 7:50 AM
> Subject: [Ietf-calsify] Just for the record. Notes has a full
> implementationof VTODOs
>
>
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

To: "Cameron Stillion" <[email-masked]>
Subject: RE: [Ietf-calsify] Just for the record. Notes has a full	implementationof VTODOs
From: [email-masked]
Date: Tue, 17 Aug 2004 15:39:26 -0400
Cc: [email-masked], [email-masked]

This is a multi-part message in MIME format...

--=_alternative 006BE70985256EF3_=
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

I disagree.  There is very little diffence between the VTODO and the 
VCALENDAR.  Both have the same repeat behavior and attendee information. 
The only difference is that the VTODO has a few additional response 
states.

I have no problem with removing journal entries, since these are basically 
different than a Calendar or group todo.  Also I do not know of any 
implimentors.

Has anybody implimented iTip VFREEBUSY requests?

"Cameron Stillion" <[email-masked]> 
Sent by: [email-masked]
08/17/2004 03:27 PM

To
<[email-masked]>, <[email-masked]>
cc

Subject
RE: [Ietf-calsify] Just for the record. Notes has a full implementationof 
VTODOs

I realize there are actually a few vendors out there who have actually
put the time and effort into implementing VTODO from the previously
proposed standard.  I question whether this investment was made in
response to users clamoring for more task-management features from
calendaring systems, or if it was done simply because it happens to be
in the spec.  I know of no web sites that publish task lists using this
mechanism, no clients that even propose to interoperate in this way.
 
Also, I think it is clearly outside the scope of this standard (and
indeed this working group) to attempt to define a standard schema for
ALL OTHER PIM DATA TYPES.  I suggest that one of the mistakes made by
previous attempts to bring iCal to standard is that they tried to extend
the notion of a calendar data type to include task items and journal
items, which are different beasts, and should be treated differently.
They have different schemas, different semantics, and applications who
want to communicate using such data types will have very different
requirements for those data types.
 
I suggest that we stick to calendaring exclusively.  Removing support
for VTODO and VJOURNAL will hurt very few if any clients.  Systems that
have implemented a means of parsing or generating these datatypes, I
would argue, have no compelling interoperability scenario or clear user
features compelling in the space we are working in.  If there is
sufficient interest in specifying such data structures, I suggest that
separate working groups and separate documents be created to bring these
Task and Journal schemas into the standards process.
 
If we try to take on the whole PIM data enchilada, I believe we will
fail as have previous attempts to make calendaring and scheduling
schemas and systems speak a standard language. 
 
camerost 

________________________________

From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, August 17, 2004 7:50 AM
To: [email-masked]
Subject: [Ietf-calsify] Just for the record. Notes has a full
implementationof VTODOs

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

--=_alternative 006BE70985256EF3_=--

Content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify] Recommendations for stripping down iCal to amanageable 'standard'
Date: Tue, 17 Aug 2004 12:27:05 -0700
From: "Cameron Stillion" <[email-masked]>
To: "Elias Sinderson" <[email-masked]>, <[email-masked]>
Cc: 

Comments on 1.2:
I don't have a problem specifically with allowing seconds optionally to
the start or end times of appointments.  I think it will be VERY rarely
used, and I question its real value in actual applications that real
humans run on real computers to do real time and schedule management. I
do, however, think that recurrences byseconds are not meaningful in the
space we are targeting.  

This all comes back to the charge of this working group.  I think the
space we are trying to solve is the personal time management space, not
the micro-organism life span space, or the stellar cartography motion of
siderial time space.  Frankly, there are time-based applications and
systems out there that will not use this standard.  And I'm ok with
that. Frankly, I wouldn't expect these systems to use a standard schema
in the first place.  They have specialized scientific purposes that will
be optimized and specially designed for their own use.  I'm hoping to
get most of us to agree on the space that we are targeting.

If we can get a lot of bang for the buck without cluttering the standard
(like including seconds for those of you who want to use it) then I
suppose we should make room for it.  But be cautious - the slope is
slippery.

Comments on 1.3:
Any non-gregorian calendar would need to specify a completely different
schema for recurrences, and potentially even date specification.  I
think it is highly unlikely the schemas we build now for gregorian
calendars will be generally applicable to other calendar types.
Therefore, I think they should be defined by other standards.  As a
suggestion, a mechanism for other calendar types would be supported by
the notion of:  BEGIN:X-HANGUL-EVENT  or BEGIN:X-LUNAR-EVENT

If there is sufficient interest in making such schemas more standard, by
all means we should define a new document which details how such things
work.

Comments on 2:
The question in my mind is whether supporting such complex recurrences
is actually meaningful? Not whether we can support complex equations by
duplicating UIDs... though that does seem like a fascinating workaround.
The formal proof, then, is "show what purpose requires their existence".

Comments on 5:
Yes, compatibility will be broken with some.  I guess what I'm trying to
say here is - let's make it somewhat inclusive, but not overly so.
We're not going to make everyone happy, but if we make the pain points
mostly on the uncharted edges, we're likely to face less problems.  For
example: depracating recurrence rules completely would be a far more
destructive change than I think would survive. So many iCals use them
already. Instead, let's just depracate the things about them that no one
uses.

Gracias,
cam

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Elias
Sinderson
Sent: Monday, August 16, 2004 9:52 PM
To: [email-masked]
Subject: Re: [Ietf-calsify] Recommendations for stripping down iCal to
amanageable 'standard'

Doug Royer wrote:

> Cameron Stillion wrote:
>
>> 1.2) Limit Data Support
>> I further recommend that it is NOT our goal to define a time/date 
>> schema that is necessarily universally applicable [...] this standard

>> will not necessarily support managing time-based or scheduling 
>> information in the sub-minute or multi-century scope.
>
> I do not follow the above item. Are you saying do always with 
> YYYYMMDDTHHMMSS in iCal?
> I do not see how SS adds too much. How about for compatibility we just

> say that SS is optional and if not supplied equals zero?

SS must at least be optional as there are many applications which
require sub-minute scheduling. (Scheduling satellite communications
windows is a primary example of this.) Developing a standard that leaves
out the concerns of aerospace and defense applications is, IMHO, an
illformed mission to embark upon. It is honestly no more difficult to
handle SS than it is to handle MM and, as I said, should at least be
optional (SHOULD) if not outright required (MUST).

>> 1.3) eCal Scale
>> It has also been recommended that the standard be limited to 
>> "Gregorian" calendar support.  I suggest that other types of 
>> calendars will require different schemas and should therefore be 
>> handled in different standards... IF they are desirable in the 
>> future.  This standard should deal exclusively in Gregorian dates, in

>> my opinion.
> Yes!

A reasonable simplifying assumption that will cover most cases. However,
I would like to advance the notion that the specification should provide
a mechanism for defining other calendars in terms of standard units,
e.g. by specifying a multiplier to 'stretch' / 'compress' seconds, or
redefine the number of days in a 'year'. In the absence of such
definitions, the Gregorian calendar should obviously be the standard
default that is used. Again, prime examples include NASA mission
scheduling requirements as well as other non-Gregorian, Earth-based
calendars, which 'begin' prior to year '0'. To simplify client and
server development, support for non-gregorian systems should be
optional, but specifying the mechanism for this would be a benefit in
that people wouldn't go off and define ad hoc and incompatible methods.

>> 2) Simplify recurrences
>
> Remove multiple BY's in one rule - yes. In iTIP all same SEQ/UID items

> are the same object. Complex recurrences can be represented the same 
> now by providing multiple objects each with simple recurrences and all

> with the same UID. [...]

I would provisionally agree, although I would like to see a formal proof
that one can achieve the same recurrences using the simplified approach.

>> 3) Simplify exceptions
>> I propose that exceptions be exclusively one-off events, never 
>> recurrences themselves. [...]
>
> Yes.

Agreed.

>> 4)  Remove useless properties
>
> Deprecate - GEO - yes. The were added when GPS's were new and everyone

> thought it would be a great addition.

Agreed.

>> 5) Compatibility
>> Fortunately or Unfortunately, there exist lots of iCals out there in 
>> the  world wide web thingy - while we may not like the way they do 
>> things, it would be very naughty of us to declare everything they do 
>> as non-standard.  I think we should be somewhat cautious about our 
>> removals at least to the degree that we do not severely cripple the 
>> large existing data that is stored on sites such as eventsherpa and 
>> icalshare. This will also help our ultimate goal which is (in this 
>> small scope) to bring this draft to standard.
>
I have mixed feeling regarding this. In general, I agree with you in
principle, it seems clear that it is folly to try and import everything
into this standard. Hence, it is also clear that some existing things
will be broken (i.e. non-compliant). So, while commendable, I feel that
we can only regard other non-standard calendaring schemes as just that. 
Yes, we should make an attempt to include what they have gotten right
but let's not lose the path ourselves simply to save a few lost sheep.
:-)

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

Content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify] Just for the record. Notes has a full implementationof VTODOs
Date: Tue, 17 Aug 2004 12:27:58 -0700
From: "Cameron Stillion" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: 

This is a multi-part message in MIME format...

------=_NextPartTM-000-3f9667d8-e4da-44ba-927d-a6b6f1341e29
Content-Type: multipart/alternative; boundary="----------=_1092770863-10808-2"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.411 (Entity 5.404)

This is a multi-part message in MIME format...

------------=_1092770863-10808-2
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I realize there are actually a few vendors out there who have actually
put the time and effort into implementing VTODO from the previously
proposed standard.  I question whether this investment was made in
response to users clamoring for more task-management features from
calendaring systems, or if it was done simply because it happens to be
in the spec.  I know of no web sites that publish task lists using this
mechanism, no clients that even propose to interoperate in this way.
=20
Also, I think it is clearly outside the scope of this standard (and
indeed this working group) to attempt to define a standard schema for
ALL OTHER PIM DATA TYPES.  I suggest that one of the mistakes made by
previous attempts to bring iCal to standard is that they tried to extend
the notion of a calendar data type to include task items and journal
items, which are different beasts, and should be treated differently.
They have different schemas, different semantics, and applications who
want to communicate using such data types will have very different
requirements for those data types.
=20
I suggest that we stick to calendaring exclusively.  Removing support
for VTODO and VJOURNAL will hurt very few if any clients.  Systems that
have implemented a means of parsing or generating these datatypes, I
would argue, have no compelling interoperability scenario or clear user
features compelling in the space we are working in.  If there is
sufficient interest in specifying such data structures, I suggest that
separate working groups and separate documents be created to bring these
Task and Journal schemas into the standards process.
=20
If we try to take on the whole PIM data enchilada, I believe we will
fail as have previous attempts to make calendaring and scheduling
schemas and systems speak a standard language.=20=20
=20
camerost=20
=20

________________________________

From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, August 17, 2004 7:50 AM
To: [email-masked]
Subject: [Ietf-calsify] Just for the record. Notes has a full
implementationof VTODOs

------------=_1092770863-10808-2--

------=_NextPartTM-000-3f9667d8-e4da-44ba-927d-a6b6f1341e29--

Date: Tue, 17 Aug 2004 12:53:31 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
Subject: [Ietf-calsify] Re: RRULEs
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Tue, 17 Aug 2004 18:53:45 -0000

This is a cryptographically signed message in MIME format.

--------------ms050309080509010004080109
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

[email-masked] wrote:

>
>>2) Simplify recurrences
>>
>>Nathaniel suggested in San Diego a rather severe approach which included
>>doing away completely with recurrence rules.  While I applaud his
>>ability to think outside the box, I believe that the problem is not
>>necessarily the existence of recurrences that causes a problem, but the
>>ability to specify recurrences that don't make sense or that are beyond
>>the scope of the problem.
>>
>>I recommend that we remove the recurrence BY*'s that are not applicable
>>to PIM data.  I think those are: BYHOUR, BYMINUTE, and BYSECOND.
>>
>>I also recommend that we disallow multiple BY*'s in one FREQ.
>>    
>>
>
>I disagree.  I think Rules should go.  Why not take out the complexity of
>recurrences and have the standard dictate that the vendor must send a list
>of dates, and optionally send a recurrence rule (for UI purposes or maybe
>for handheld devices)?  This way the recipient does not have to infer what
>the rule meant, but can simply put the sent dates on the calendar.
>
Standing staff meeting every Monday at 2pm. The argument for not being able
to have unbounded instances is the problem. What limit? How many means 
forever?
Or do we add a new unbound property or parameter. Then we are back to some
version of rrule.

Currently multiple RRULE properties are allowed per object. I think that
needs to go at a minimum.

>I really think this is worthwhile to consider if you take it step further -
>to reschedules.  This is where each vendor does their own thing
>(currently).  That's ok, so long as we're all sending the same basic data,
>but we're not.  If we sent the exact dates that we want rescheduled, and
>the exact dates that we want rescheduled to, we'd solve alot of basic
>rescheduling interop problems.
>
Yes. TOSS all of the iTIP complexity. Simply send replacement objects. 
That's one
method of updating objects that works for all vendors already. Keep the 
same UID
and update the SEQ values, send new objects. Simplifies all of that mess.

-- 

--------------ms050309080509010004080109
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms050309080509010004080109--

Subject: Re: [Ietf-calsify] Recommendations for stripping down iCal to a	manageable 'standard'
To: [email-masked]
From: [email-masked]
Date: Tue, 17 Aug 2004 14:23:06 -0400

Cameron Stillion wrote on 08/16/2004 08:35:08 PM:

> 0) New Name
>
> Let's not put new wine in old bottles.  I recommend we call this the
> "eCal" standard, short for "electronic calendar".  I like this better
> than sCal or qCal, mostly because it expresses a similarity to eMail,
> and I believe one of our stated goals (at least verbally) is to bring
> calendaring out of obscurity and into the ubiquity of electronic mail.

Is there any worth to keeping "iCal"?  Some companies have adopted iCal as
a standard even if it's not in Draft state yet, and we might do well to
build off of that branding so to speak?

> 1.1) Limit Schema Support
>
> As a non-goal, I suggest that our purpose is NOT to define a schema for
> all types of PIM data -  specifically, journal items, task items, etc.
> Other data types like those mentioned should be specified in OTHER
> standards.  This means removing VJOURNAL and VTODO from this document.

Journal at least should go.  I agree with that.  To Do's, well, I'm
hesitant to agree that they should go.  What are To Dos?  They tend to act
like just a special meeting type, so maybe they do fit in here.  In
Berkley, we discussed another option - why not have To Dos as a "should"
but require that if the vendor does not support To Dos, to respond with
that to the sender.

>
> 1.3) eCal Scale
>
> It has also been recommended that the standard be limited to "Gregorian"
> calendar support.  I suggest that other types of calendars will require
> different schemas and should therefore be handled in different
> standards... IF they are desirable in the future.  This standard should
> deal exclusively in Gregorian dates, in my opinion.

Should this just be removed then?  Or have the vendor specify a default of
"Gregorian", giving the option of extending it in the future?

> 2) Simplify recurrences
>
> Nathaniel suggested in San Diego a rather severe approach which included
> doing away completely with recurrence rules.  While I applaud his
> ability to think outside the box, I believe that the problem is not
> necessarily the existence of recurrences that causes a problem, but the
> ability to specify recurrences that don't make sense or that are beyond
> the scope of the problem.
>
> I recommend that we remove the recurrence BY*'s that are not applicable
> to PIM data.  I think those are: BYHOUR, BYMINUTE, and BYSECOND.
>
> I also recommend that we disallow multiple BY*'s in one FREQ.

I disagree.  I think Rules should go.  Why not take out the complexity of
recurrences and have the standard dictate that the vendor must send a list
of dates, and optionally send a recurrence rule (for UI purposes or maybe
for handheld devices)?  This way the recipient does not have to infer what
the rule meant, but can simply put the sent dates on the calendar.

I really think this is worthwhile to consider if you take it step further -
to reschedules.  This is where each vendor does their own thing
(currently).  That's ok, so long as we're all sending the same basic data,
but we're not.  If we sent the exact dates that we want rescheduled, and
the exact dates that we want rescheduled to, we'd solve alot of basic
rescheduling interop problems.

And this path allows the vendor to be as complex as they would like.  Some
offer very complex repeat rules, while a new vendor to the iCal space may
want to offer a much smaller subset of the recurrence feature.  Both should
still send the same iCal and interoperate if they both send a list of
time/dates instead of rules and exceptions.

> 4)  Remove useless properties
>
> For example:
>
> GEO = Geographic Position (?)
> Does anyone use this? Does anyone think they will ever specify the lat
> and long of their next team meeting?  I don't understand the purpose of
> this, since we have such great time zone support?  What could a client
> ever reasonably do with this information?

I agree.  Don't think this is being used...

> 5) Compatibility
>
> Fortunately or Unfortunately, there exist lots of iCals out there in the
> world wide web thingy - while we may not like the way they do things, it
> would be very naughty of us to declare everything they do as
> non-standard.  I think we should be somewhat cautious about our removals
> at least to the degree that we do not severely cripple the large
> existing data that is stored on sites such as eventsherpa and icalshare.
> This will also help our ultimate goal which is (in this small scope) to
> bring this draft to standard.

That's a good point.  I think though, if we each take the position that
we'll probably all have to modify our implementation in order to fit what
we come up with as the iCal (or eCal or whatever) standard, then maybe it's
ok to make drastic changes to the standard.  We'll all likely have work to
do from this....
-CS

Date: Tue, 17 Aug 2004 12:34:47 -0600
From: "Preston Stephenson" <[email-masked]>
To: <[email-masked]>
Subject: Re: [Ietf-calsify] Recommendations for stripping down iCal to a manageable 'standard'

>1.1) Limit Schema Support
>
>As a non-goal, I suggest that our purpose is NOT to define a schema
for
>all types of PIM data -  specifically, journal items, task items,
etc.
>Other data types like those mentioned should be specified in OTHER
>standards.  This means removing VJOURNAL and VTODO from this
document.

Do you think it will add too much complexity to support VJOURNAL and
VTODO?

They are usually simpler than VEVENT's.
It wouldn't seem that more difficult to support all three.
Are we going to come up with a definition of an all-day event?
I've seen it handled multiple ways.

Thanks.
Preston

Subject: Re: [Ietf-calsify] Recommendations for stripping down iCal to a	manageable 'standard'
To: [email-masked]
From: [email-masked]
Date: Tue, 17 Aug 2004 14:01:54 -0400

Elias wrote on 08/17/2004 12:51:52 AM:

> >> 1.2) Limit Data Support
> >> I further recommend that it is NOT our goal to define a time/date
> >> schema that is necessarily universally applicable [...] this standard
> >> will not necessarily support managing time-based or scheduling
> >> information in the sub-minute or multi-century scope.
> >
> > I do not follow the above item. Are you saying do always with
> > YYYYMMDDTHHMMSS in iCal?
> > I do not see how SS adds too much. How about for compatibility we just
> > say that SS is optional and if not supplied equals zero?
>
> SS must at least be optional as there are many applications which
> require sub-minute scheduling. (Scheduling satellite communications
> windows is a primary example of this.) Developing a standard that leaves
> out the concerns of aerospace and defense applications is, IMHO, an
> illformed mission to embark upon. It is honestly no more difficult to
> handle SS than it is to handle MM and, as I said, should at least be
> optional (SHOULD) if not outright required (MUST).

I agree.  I'd like to see consideration of Seconds as at least optional.
We might have a good example of this being necessary where the application
is not message-based, but instead builds a queue.  Given that, in order to
use DTSTAMP appropriately, they might need seconds in the time/date.

> >> 1.3) eCal Scale
> >> It has also been recommended that the standard be limited to
> >> "Gregorian" calendar support.  I suggest that other types of
> >> calendars will require different schemas and should therefore be
> >> handled in different standards... IF they are desirable in the
> >> future.  This standard should deal exclusively in Gregorian dates, in
> >> my opinion.

Why was this put into the standard in the first place?  Does anyone
remember?

Will respond to the Recurrence part separately.....
-Chris Stoner

Date: Tue, 17 Aug 2004 11:24:44 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Recommendations for stripping down iCal to a	manageable 'standard'
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Tue, 17 Aug 2004 17:24:55 -0000

This is a cryptographically signed message in MIME format.

--------------ms020504050107090403040702
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Elias Sinderson wrote:

>
>>> 1.3) eCal Scale
>>> It has also been recommended that the standard be limited to 
>>> "Gregorian" calendar support.  I suggest that other types of 
>>> calendars will require different schemas and should therefore be 
>>> handled in different standards... IF they are desirable in the 
>>> future.  This standard should deal exclusively in Gregorian dates, 
>>> in my opinion.
>>
>
> A reasonable simplifying assumption that will cover most cases. 
> However, I would like to advance the notion that the specification 
> should provide a mechanism for defining other calendars in terms of 
> standard units, e.g. by specifying a multiplier to 'stretch' / 
> 'compress' seconds, or redefine the number of days in a 'year'. In the 
> absence of such definitions, the Gregorian calendar should obviously 
> be the standard default that is used. Again, prime examples include 
> NASA mission scheduling requirements as well as other non-Gregorian, 
> Earth-based calendars, which 'begin' prior to year '0'. To simplify 
> client and server development, support for non-gregorian systems 
> should be optional, but specifying the mechanism for this would be a 
> benefit in that people wouldn't go off and define ad hoc and 
> incompatible methods. 

Those can be separate drafts.

>>> 2) Simplify recurrences
>>
>>
>> Remove multiple BY's in one rule - yes. In iTIP all same SEQ/UID 
>> items are the same object. Complex recurrences
>> can be represented the same now by providing multiple objects each 
>> with simple recurrences and all with the same UID. [...]
>
>
> I would provisionally agree, although I would like to see a formal 
> proof that one can achieve the same recurrences using the simplified 
> approach.

In the simplest form, each of the multiple objects has exactly one 
date/time and
no RRULE.  Now add simplified RRULEs. I can not think of any set of entries
that can not be represented.

>
>>> 4)  Remove useless properties 
>>
Also 'RELATED-TO' is value is vendor specific and unusable as documented.

The purpose of iCal is to allow for the transfer of information between 
vendors.
A property that is specifically unspecified is not useful.

-- 

--------------ms020504050107090403040702
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms020504050107090403040702--

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-calsify] Calsify list vs. CalDAV list?
Date: Tue, 17 Aug 2004 10:21:51 -0700
To: [email-masked]
Cc: [email-masked], [email-masked]

That wasn't what I was trying to convey, I'm sorry if I wasn't clear 
enough about the purpose of the two lists.  The purpose of CALSIFY is 
only to revise the iCalendar, and possibly iMIP and iTIP RFCs, to go to 
draft standard, if that can be done and can improve interoperability 
and deployment.  Since you can't add features when going to draft 
standard, clearly any "server" feature, including notifications, is out 
of scope for CALSIFY.

The CalDAV group might decide that notifications is out of scope, but 
at least it's worth discussing whether notifications are a MUST, a 
feature to do later, or a feature to not even think about right now.  I 
suspect our job will be a lot simpler if we declare notifications out 
of scope for now, although I'd be happy to work on calendar event 
notifications next after CalDAV.

Lisa

On Aug 16, 2004, at 5:34 PM, [email-masked] wrote:

> Sorry for the cross-post but it seems relevant. Let me preface this by 
> saying that I haven't read all of CalDAV yet - and I suspect I need to 
> be up to speed on DAV first. That said - it seems to me some of the 
> discussion going on now on the CalDAV list re: notifications and 
> client/server complexity are issues (either "also" or "instead") for 
> the Calsify list?
>
> Tim Hare
> Interested Bystander, Non-Inc.
>
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

To: [email-masked]
From: [email-masked]
Date: Tue, 17 Aug 2004 10:50:10 -0400
Subject: [Ietf-calsify] Just for the record. Notes has a full implementation of VTODOs

This is a multi-part message in MIME format...

--=_alternative 00516EE285256EF3_=
Content-Type: text/plain; charset="US-ASCII"
Content-Disposition: inline

--=_alternative 00516EE285256EF3_=--

Date: Mon, 16 Aug 2004 21:51:52 -0700
From: Elias Sinderson <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Recommendations for stripping down iCal to a manageable 'standard'

Doug Royer wrote:

> Cameron Stillion wrote:
>
>> 1.2) Limit Data Support
>> I further recommend that it is NOT our goal to define a time/date 
>> schema that is necessarily universally applicable [...] this standard 
>> will not necessarily support managing time-based or scheduling 
>> information in the sub-minute or multi-century scope.
>
> I do not follow the above item. Are you saying do always with 
> YYYYMMDDTHHMMSS in iCal?
> I do not see how SS adds too much. How about for compatibility we just 
> say that SS is optional and if not supplied equals zero?

SS must at least be optional as there are many applications which 
require sub-minute scheduling. (Scheduling satellite communications 
windows is a primary example of this.) Developing a standard that leaves 
out the concerns of aerospace and defense applications is, IMHO, an 
illformed mission to embark upon. It is honestly no more difficult to 
handle SS than it is to handle MM and, as I said, should at least be 
optional (SHOULD) if not outright required (MUST).

>> 1.3) eCal Scale
>> It has also been recommended that the standard be limited to 
>> "Gregorian" calendar support.  I suggest that other types of 
>> calendars will require different schemas and should therefore be 
>> handled in different standards... IF they are desirable in the 
>> future.  This standard should deal exclusively in Gregorian dates, in 
>> my opinion.
>
> Yes!

A reasonable simplifying assumption that will cover most cases. However, 
I would like to advance the notion that the specification should provide 
a mechanism for defining other calendars in terms of standard units, 
e.g. by specifying a multiplier to 'stretch' / 'compress' seconds, or 
redefine the number of days in a 'year'. In the absence of such 
definitions, the Gregorian calendar should obviously be the standard 
default that is used. Again, prime examples include NASA mission 
scheduling requirements as well as other non-Gregorian, Earth-based 
calendars, which 'begin' prior to year '0'. To simplify client and 
server development, support for non-gregorian systems should be 
optional, but specifying the mechanism for this would be a benefit in 
that people wouldn't go off and define ad hoc and incompatible methods.

>> 2) Simplify recurrences
>
> Remove multiple BY's in one rule - yes. In iTIP all same SEQ/UID items 
> are the same object. Complex recurrences
> can be represented the same now by providing multiple objects each 
> with simple recurrences and all with the same UID. [...]

I would provisionally agree, although I would like to see a formal proof 
that one can achieve the same recurrences using the simplified approach.

>> 3) Simplify exceptions
>> I propose that exceptions be exclusively one-off events, never 
>> recurrences themselves. [...]
>
> Yes.

Agreed.

>> 4)  Remove useless properties
>
> Deprecate - GEO - yes. The were added when GPS's were new and everyone 
> thought it would be a great addition.

Agreed.

>> 5) Compatibility
>> Fortunately or Unfortunately, there exist lots of iCals out there in 
>> the  world wide web thingy - while we may not like the way they do 
>> things, it would be very naughty of us to declare everything they do 
>> as non-standard.  I think we should be somewhat cautious about our 
>> removals at least to the degree that we do not severely cripple the 
>> large existing data that is stored on sites such as eventsherpa and 
>> icalshare. This will also help our ultimate goal which is (in this 
>> small scope) to bring this draft to standard.  
>
I have mixed feeling regarding this. In general, I agree with you in 
principle, it seems clear that it is folly to try and import everything 
into this standard. Hence, it is also clear that some existing things 
will be broken (i.e. non-compliant). So, while commendable, I feel that 
we can only regard other non-standard calendaring schemes as just that. 
Yes, we should make an attempt to include what they have gotten right 
but let's not lose the path ourselves simply to save a few lost sheep.  :-)

Regards,
Elias

Date: Mon, 16 Aug 2004 19:16:48 -0600
From: Doug Royer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Recommendations for stripping down iCal to a	manageable 'standard'
X-Royer.com-MailScanner-Information: Please contact [email-masked] for more information
X-Royer.com-MailScanner: Found to be clean
X-Scanned-By: MIMEDefang 2.39
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: [email-masked]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Tue, 17 Aug 2004 01:17:00 -0000

This is a cryptographically signed message in MIME format.

--------------ms090806080200020801090300
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

And it iTIP simplification in scope?

Cameron Stillion wrote:

>1.2) Limit Data Support
>
>I further recommend that it is NOT our goal to define a time/date schema
>that is necessarily universally applicable.  Non-calendaring
>applications may require more granular or more broad time-based
>calculation, but these are beyond the scope of this work.  More
>specifically, this standard will not necessarily support managing
>time-based or scheduling information in the sub-minute or multi-century
>scope.
>  
>
I do not follow the above item. Are you saying do always with 
YYYYMMDDTHHMMSS
in iCal?

I do not see how SS adds too much. How about for compatibility we just 
say that SS
is optional and if not supplied equals zero?

>1.3) eCal Scale
>
>It has also been recommended that the standard be limited to "Gregorian"
>calendar support.  I suggest that other types of calendars will require
>different schemas and should therefore be handled in different
>standards... IF they are desirable in the future.  This standard should
>deal exclusively in Gregorian dates, in my opinion.
>
Yes!

>2) Simplify recurrences
Remove multiple BY's in one rule - yes.

In iTIP all same SEQ/UID items are the same object. Complex recurrences
can be represented the same now by providing multiple objects each with
simple recurrences and all with the same UID. No need for those complex
recurrence rules.

>3) Simplify exceptions
>
>I propose that exceptions be exclusively one-off events, never
>recurrences themselves.  I believe this simplifies exceptions to a point
>that allows them to be implemented in a rational way.  I think this also
>makes recurrences much more palatable (see item 2 above) while not
>killing them off completely.
>
Yes.

>4)  Remove useless properties
>  
>
Deprecate - GEO - yes. The were added when GPS's were new and
everyone thought it would be a great addition.

>
>5) Compatibility
>
>Fortunately or Unfortunately, there exist lots of iCals out there in the
>world wide web thingy - while we may not like the way they do things, it
>would be very naughty of us to declare everything they do as
>non-standard.  I think we should be somewhat cautious about our removals
>at least to the degree that we do not severely cripple the large
>existing data that is stored on sites such as eventsherpa and icalshare.
>This will also help our ultimate goal which is (in this small scope) to
>bring this draft to standard.
>  
>
Some of the ideas in CAP should also be transferred over.
NAME, DESCRIPTION, and LOCALE of the calendar just to name a few.

When you look at the large number of free calendar .ICS files, they all seem
to have several vendor extensions in common that they all add. Such as
their version of the time zone of the calendar.  CAL-ID , CAL-URL.

Just to start a thread.

-- 

--------------ms090806080200020801090300
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms090806080200020801090300--

Date: Mon, 16 Aug 2004 20:47:50 -0400
To: [email-masked]
From: [email-masked]
Subject: [Ietf-calsify] Simplification

I'd like to start off this list by asking questions regarding calendar 
"simplification".

1. Is the intent to re-examine RCF2445/6/7?
2. Is the intent to make implementation simpler?
3. Is the intent to make use simpler (may conflict with #2).
4. Is the intent to make implementation more wide-spread?
5. Is the intent to make inter-operation better?
6. What are the perceived issues with the current RFCs?

Getting a consensus answer to these questions, I feel, will give the list a 
"level set" from which to work. My goal, as a user-sometimes-developer 
(i.e. I can program for a living but calendar coding I'm not paid for), is 
to get _some_  interoperable calendar thing working, sometime before:

BEGIN: VEVENT
DTSTART:  39541231T1100Z
SUMMARY: Tim's memorial service
END: VEVENT

:-)

Seriously, this is the kind of thing that, once it gets rolling and people 
use it, they will get to a point where it's like plumbing to them. Sort of 
the situation is for e-mail today; with all its flaws, we just take it for 
granted. I want calendaring to be like that.

Tim Hare
Interested Bystander, Non-Inc. 

Date: Mon, 16 Aug 2004 20:34:44 -0400
To: [email-masked], [email-masked]
From: [email-masked]
Cc: 
Subject: [Ietf-calsify] Calsify list vs. CalDAV list?

Sorry for the cross-post but it seems relevant. Let me preface this by 
saying that I haven't read all of CalDAV yet - and I suspect I need to be 
up to speed on DAV first. That said - it seems to me some of the discussion 
going on now on the CalDAV list re: notifications and client/server 
complexity are issues (either "also" or "instead") for the Calsify list?

Tim Hare
Interested Bystander, Non-Inc.  

Content-class: urn:content-classes:message
Date: Mon, 16 Aug 2004 17:35:08 -0700
From: "Cameron Stillion" <[email-masked]>
To: <[email-masked]>
Subject: [Ietf-calsify] Recommendations for stripping down iCal to a manageable 'standard'

I think it's about time to get this party started...

The following is a list of my personal recommendations for altering iCal
as it exists today in order to limit the scope of implementation and
bring it to a level that is suitable for widespread implementation:

0) New Name

Let's not put new wine in old bottles.  I recommend we call this the
"eCal" standard, short for "electronic calendar".  I like this better
than sCal or qCal, mostly because it expresses a similarity to eMail,
and I believe one of our stated goals (at least verbally) is to bring
calendaring out of obscurity and into the ubiquity of electronic mail.  

1) Clarify Purpose

I think it is critical to our success that we make it very clear what
the purpose of such a calendaring standard is.  My proposal is that our
mission here is to define a method and way to schematize Calendar data
for personal and/or group scheduling.  We want to be able to represent
electronically the kinds of data people store in planners, organizers,
wall calendars, and other types of time management and organizational
tools.

1.1) Limit Schema Support

As a non-goal, I suggest that our purpose is NOT to define a schema for
all types of PIM data -  specifically, journal items, task items, etc.
Other data types like those mentioned should be specified in OTHER
standards.  This means removing VJOURNAL and VTODO from this document.

1.2) Limit Data Support

I further recommend that it is NOT our goal to define a time/date schema
that is necessarily universally applicable.  Non-calendaring
applications may require more granular or more broad time-based
calculation, but these are beyond the scope of this work.  More
specifically, this standard will not necessarily support managing
time-based or scheduling information in the sub-minute or multi-century
scope.

1.3) eCal Scale

It has also been recommended that the standard be limited to "Gregorian"
calendar support.  I suggest that other types of calendars will require
different schemas and should therefore be handled in different
standards... IF they are desirable in the future.  This standard should
deal exclusively in Gregorian dates, in my opinion.

2) Simplify recurrences

Nathaniel suggested in San Diego a rather severe approach which included
doing away completely with recurrence rules.  While I applaud his
ability to think outside the box, I believe that the problem is not
necessarily the existence of recurrences that causes a problem, but the
ability to specify recurrences that don't make sense or that are beyond
the scope of the problem.

I recommend that we remove the recurrence BY*'s that are not applicable
to PIM data.  I think those are: BYHOUR, BYMINUTE, and BYSECOND.

I also recommend that we disallow multiple BY*'s in one FREQ.

2.1) Better examples

I believe that the example in the spec of "every Sunday in January at
8:30:00 AM and 9:30:00 AM, every other year" is heinously contrived and
should be expunged. I do, however, think that we should show examples of
commonly used recurrences that span the bulk of the valid recurrence
equations.  Perhaps this belongs in a different doc... Do we need a
"calendaring profiles" informational RFC that tells application
programmers how to implement standard types, and perhaps even provides
regular expressions for implementing reasonable parsers?  I've always
thought that format specifications should require actual regular
expression code that shreds it. 

3) Simplify exceptions

Exceptions are an important principle in calendaring, but they can be
problematic if they are not handled cleanly.  One of the reasons why
exceptions are so difficult in the current proposed standard is that
exceptions can be specified as recurrences themselves.  Therefore
exceptions inherit all the problems of recurrences squared.

I propose that exceptions be exclusively one-off events, never
recurrences themselves.  I believe this simplifies exceptions to a point
that allows them to be implemented in a rational way.  I think this also
makes recurrences much more palatable (see item 2 above) while not
killing them off completely.

4)  Remove useless properties

For example:

GEO = Geographic Position (?)
Does anyone use this? Does anyone think they will ever specify the lat
and long of their next team meeting?  I don't understand the purpose of
this, since we have such great time zone support?  What could a client
ever reasonably do with this information?

5) Compatibility

Fortunately or Unfortunately, there exist lots of iCals out there in the
world wide web thingy - while we may not like the way they do things, it
would be very naughty of us to declare everything they do as
non-standard.  I think we should be somewhat cautious about our removals
at least to the degree that we do not severely cripple the large
existing data that is stored on sites such as eventsherpa and icalshare.
This will also help our ultimate goal which is (in this small scope) to
bring this draft to standard.

Why don't we start with this as a means for discussion.

Let it begin...

cameron stillion
<[email-masked]>