Subject: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2447bis-00.txt

From: Internet-Drafts at ietf.org ([email-masked])
Date: Wed Aug 24 10:28:41 2005

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Calendaring and Scheduling Standards Simplification Working Group of the IETF.

	Title		: iCalendar Message-Based Interoperability Protocol (iMIP)
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-calsify-rfc2447bis-00.txt
	Pages		: 20
	Date		: 2005-8-18
	
   This document, [iMIP], specifies a binding from the iCalendar
   Transport-independent Interoperability Protocol (iTIP) to Internet
   email-based transports. Calendaring entries defined by the iCalendar
   Object Model [iCAL] are composed using constructs from [RFC-2822],
   [RFC-2045], [RFC-2046], [RFC-2047], [RFC-2048] and [RFC-2049].

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

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

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

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
-------------- next part --------------
Skipped content of type multipart/alternative-------------- next part --------------
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

To: [email-masked]
From: [email-masked]
Date: Thu, 18 Aug 2005 15:50:01 -0400
Sender: [email-masked]
Cc: [email-masked]
Subject: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2447bis-00.txt 
Reply-To: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Calendaring and Scheduling Standards Simplification Working Group of the IETF.

	Title		: iCalendar Message-Based Interoperability Protocol (iMIP)
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-calsify-rfc2447bis-00.txt
	Pages		: 20
	Date		: 2005-8-18
	
   This document, [iMIP], specifies a binding from the iCalendar
   Transport-independent Interoperability Protocol (iTIP) to Internet
   email-based transports. Calendaring entries defined by the iCalendar
   Object Model [iCAL] are composed using constructs from [RFC-2822],
   [RFC-2045], [RFC-2046], [RFC-2047], [RFC-2048] and [RFC-2049].

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

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

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

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-calsify-rfc2447bis-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-calsify-rfc2447bis-00.txt"; site="ftp.ietf.org";
	access-type="anon-ftp"; directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--

Date: Sun, 21 Aug 2005 15:21:11 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] UTF-8 / encoding / MIME headers

Doug Royer wrote:

> Alexey Melnikov wrote:
>
>> 3). In section "2.5 Content-Transfer-Encoding".
>>
>> The section says:
>>
>> Note that the default character set for iCalendar objects is UTF-8.
>>
>> After rereading the sentence several times I am not entirely sure 
>> what it means.
>> RFC 2822 says that the default charset is US-ASCII, if not specified. 
>> The iMIP document can't override this rule.
>
> It does not override making the default for 2822 MIME objects UTF-8.
> Just set the transfer-encoding to UTF-8 in the MIME header for
> text/calendar objects or encode the iCal object.
>
> 2445 says that the default for iCal objects is UTF-8.

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

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

That certainly makes more sense.

> As you can't always declare them as US-ASCII (Unless that just happen
> to be from that subset), so you must set the transfer encoding
> or some how encode the iCal object.
>
>> I think this sentence is trying to say that all CUAs MUST be able to 
>> accept calendars with data in UTF-8.
>
> That is also true.
>
>> If it is the case, this sentence should be rewritten to clarify.
>
>> Later in the same section RFC 2447 said:
>>
>> A transfer encoding SHOULD be used for iCalendar objects containing any
>> characters that are not part of the US-ASCII character set.
>>
>> Once again I was not entirely sure what this sentence was trying to 
>> say. Is it trying to say that unless you use 8bit safe transport, you 
>> should use content transfer encodings like quoted-printable or base64?
>
> US-ASCII is a subset of UTF-8. So if your iCal object is 100% US-ASCII,
> then you do not have to set the transfer-encoding to UTF-8 or encode
> anything.
>
> If your iCal object contains more than US-ASCII characters, you have
> to do the right MIME thing - what ever that is.

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

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

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

To: Calsify <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Date: Fri, 19 Aug 2005 17:14:56 -0700
Subject: [Ietf-calsify] Implementation reports

FYI, if you haven't seen this page already, here is where the IETF 
keeps implementation reports.  We need this for CALSIFY -- Pat Egen is 
editor for that work.

http://www.ietf.org/IESG/implementation.html

Lisa

Date: Fri, 19 Aug 2005 14:28:07 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] UTF-8 / encoding / MIME headers
Reply-To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms060002040200080509010505
Content-Type: multipart/mixed; boundary="------------020301090605010808030409"

This is a multi-part message in MIME format.
--------------020301090605010808030409
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

[email-masked] wrote:
> 
> It can be any charset that contains ascii as a subset.  For example you 
> can set charset to unicode.

It can also be any charset, as long as you update the MIME headers.

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------020301090605010808030409
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------020301090605010808030409--

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

--------------ms060002040200080509010505--

To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [Ietf-calsify] UTF-8 / encoding / MIME headers
Date: Fri, 19 Aug 2005 15:55:23 -0400
From: [email-masked]

--=_mixed 006D1CE985257062_=
Content-Type: text/html; charset="US-ASCII"

<br><font size=2 face="sans-serif">It can be any charset that contains
ascii as a subset. &nbsp;For example you can set charset to unicode.</font>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Doug Royer &lt;[email-masked]&gt;</b>
</font>
<br><font size=1 face="sans-serif">Sent by: [email-masked]</font>
<p><font size=1 face="sans-serif">08/19/2005 02:45 PM</font>
<table border>
<tr valign=top>
<td bgcolor=white>
<div align=center><font size=1 face="sans-serif">Please respond to<br>
[email-masked]</font></div></table>
<br>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">[email-masked]</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Re: [Ietf-calsify] UTF-8 / encoding
/ MIME headers</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><tt><font size=2><br>
<br>
Alexey Melnikov wrote:<br>
<br>
&gt; <br>
&gt; 3). In section &quot;2.5 Content-Transfer-Encoding&quot;.<br>
&gt; <br>
&gt; The section says:<br>
&gt; <br>
&gt; Note that the default character set for iCalendar objects is UTF-8.<br>
&gt; <br>
&gt; After rereading the sentence several times I am not entirely sure
what <br>
&gt; it means.<br>
&gt; RFC 2822 says that the default charset is US-ASCII, if not specified.
<br>
&gt; The iMIP document can't override this rule.<br>
<br>
It does not override making the default for 2822 MIME objects UTF-8.<br>
Just set the transfer-encoding to UTF-8 in the MIME header for<br>
text/calendar objects or encode the iCal object.<br>
<br>
2445 says that the default for iCal objects is UTF-8. As you<br>
can't always declare them as US-ASCII (Unless that just happen<br>
to be from that subset), so you must set the transfer encoding<br>
or some how encode the iCal object.<br>
<br>
&gt; I think this sentence is trying to say that all CUAs MUST be able
to <br>
&gt; accept calendars with data in UTF-8.<br>
<br>
That is also true.<br>
<br>
&gt; If it is the case, this sentence should be rewritten to clarify.<br>
<br>
<br>
&gt; Later in the same section RFC 2447 said:<br>
&gt; <br>
&gt; A transfer encoding SHOULD be used for iCalendar objects containing
any<br>
&gt; characters that are not part of the US-ASCII character set.<br>
&gt; <br>
&gt; Once again I was not entirely sure what this sentence was trying to
say. <br>
&gt; Is it trying to say that unless you use 8bit safe transport, you should
<br>
&gt; use content transfer encodings like quoted-printable or base64?<br>
<br>
US-ASCII is a subset of UTF-8. So if your iCal object is 100% US-ASCII,<br>
then you do not have to set the transfer-encoding to UTF-8 or encode<br>
anything.<br>
<br>
If your iCal object contains more than US-ASCII characters, you have<br>
to do the right MIME thing - what ever that is.<br>
<br>
And the preferred iCal object is in UTF-8, however it can be any<br>
charset, just make the MIME headers match what you are sending.<br>
<br>
-- <br>
<br>
Doug Royer &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; | http://INET-Consulting.com<br>
-------------------------------|-----------------------------<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; We Do Standards - You
Need Standards<br>
<br>
_______________________________________________<br>
Ietf-calsify mailing list<br>
[email-masked]<br>
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify<br>
</font></tt>
<br>
--=_mixed 006D1CE985257062_=
Content-Type: application/octet-stream; name="Doug.vcf"
Content-Disposition: attachment; filename="Doug.vcf"
Content-Transfer-Encoding: base64

YmVnaW46dmNhcmQNCmZuOkRvdWcgUm95ZXINCm46Um95ZXI7RG91Zw0Kb3JnOklORVQtQ29uc3Vs
dGluZy5jb20NCmFkcjo7OzE3OTUgVy4gQnJvYWR3YXkgU3QgIzI2NjtJZGFobyBGYWxscztJRDs4
MzQwMjtVLlMuQQ0KZW1haWw7aW50ZXJuZXQ6RG91Z0BSb3llci5jb20NCnRpdGxlOkNFTw0KdGVs
O3dvcms6MjA4LTg4MS0wMzgwDQp0ZWw7ZmF4Ojg2Ni00OTQtODU3NA0Kbm90ZTtxdW90ZWQtcHJp
bnRhYmxlOkFPTDogU3VwcG9ydFVuaXg9MEQ9MEE9DQoJTVNOOiBTdXBwb3J0QElORVQtQ29uc3Vs
dGluZy5jb209MEQ9MEE9DQoJWWFob286IEhlbHA0VW5peA0KeC1tb3ppbGxhLWh0bWw6VFJVRQ0K
dXJsOmh0dHA6Ly9Sb3llci5jb20NCnZlcnNpb246Mi4xDQplbmQ6dmNhcmQNCg0K

--=_mixed 006D1CE985257062_=
Content-Type: application/octet-stream; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

--=_mixed 006D1CE985257062_=--

Date: Fri, 19 Aug 2005 12:56:19 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Calsify <[email-masked]>
Subject: Re: [Ietf-calsify] is the ORGANIZER an ATTENDEE?
Reply-To: Calsify <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms020707090606050606040100
Content-Type: multipart/mixed; boundary="------------090305010603020508010206"

This is a multi-part message in MIME format.
--------------090305010603020508010206
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

>> ---snap---
>> So while your local calendar can store arbitary events, a published 
>> vfb entity is bound to some user. This is after all necessary to be 
>> able to process the data inside when the vfb is retrieved!
> 
> 
> Yes, but the only users to which it should be bound are ATTENDEEs.

Busy time makes calendar busy time opaque, not a users.

It consumes time on the calendar, the attendee may or might
not be attending. And even when not attending, the attendee
might want to make the time marked as busy in case they
are needed. And when attending, the attendee might consider
it a low priority and want the time shown as free time to
allow for a higher priority booking.

It is not true that 100% of the time that TRANSP VEVENT
time is free to any ATTENDEE attending or not.

It is not true that 100% of the time that OPAQUE VEVENT
time is busy to any ATTENDEE attending or not.

I do not think that an algorithm can be specified that
will cover what the CU wants.

I see TRANS as just a hint, not a rule.

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------090305010603020508010206
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------090305010603020508010206--

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

--------------ms020707090606050606040100--

Date: Fri, 19 Aug 2005 12:45:48 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] UTF-8 / encoding / MIME headers
Reply-To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms050909060000090502030905
Content-Type: multipart/mixed; boundary="------------020306080705090705030605"

This is a multi-part message in MIME format.
--------------020306080705090705030605
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Alexey Melnikov wrote:

> 
> 3). In section "2.5 Content-Transfer-Encoding".
> 
> The section says:
> 
> Note that the default character set for iCalendar objects is UTF-8.
> 
> After rereading the sentence several times I am not entirely sure what 
> it means.
> RFC 2822 says that the default charset is US-ASCII, if not specified. 
> The iMIP document can't override this rule.

It does not override making the default for 2822 MIME objects UTF-8.
Just set the transfer-encoding to UTF-8 in the MIME header for
text/calendar objects or encode the iCal object.

2445 says that the default for iCal objects is UTF-8. As you
can't always declare them as US-ASCII (Unless that just happen
to be from that subset), so you must set the transfer encoding
or some how encode the iCal object.

> I think this sentence is trying to say that all CUAs MUST be able to 
> accept calendars with data in UTF-8.

That is also true.

> If it is the case, this sentence should be rewritten to clarify.

> Later in the same section RFC 2447 said:
> 
> A transfer encoding SHOULD be used for iCalendar objects containing any
> characters that are not part of the US-ASCII character set.
> 
> Once again I was not entirely sure what this sentence was trying to say. 
> Is it trying to say that unless you use 8bit safe transport, you should 
> use content transfer encodings like quoted-printable or base64?

US-ASCII is a subset of UTF-8. So if your iCal object is 100% US-ASCII,
then you do not have to set the transfer-encoding to UTF-8 or encode
anything.

If your iCal object contains more than US-ASCII characters, you have
to do the right MIME thing - what ever that is.

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

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------020306080705090705030605
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------020306080705090705030605--

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

--------------ms050909060000090502030905--

Date: Fri, 19 Aug 2005 11:31:56 -0700
To: Helge Hess <[email-masked]>
From: John W Noerenberg II <[email-masked]>
Subject: Re: [Ietf-calsify] is the ORGANIZER an ATTENDEE?
Cc: Calsify <[email-masked]>

At 12:11 PM +0200 8/19/05, Helge Hess wrote:
>On Aug 19, 2005, at 5:46, John W Noerenberg II wrote:
>>Yup.  Restating the question:  Should your CUA show OPAQUE VEVENTs 
>>when you are not an ATTENDEE but are the ORGANIZER?
>
>I still think the discussion is going in the wrong direction. What 
>the CUA shows is a view thing and to be decided by the CUA, its not 
>standardized in the iCal spec.

Exactly so.

>Most CUAs store arbitary collections of events and show _all_ of 
>them, even if you are neither an organizer nor an attendee.

What any particular CUA does is an implementation choice.  Even if I 
agree with you (and I'm inclined to agree - not that I think it's 
correct) that most show *all* events regardless of the value of 
ORGANIZER and ATTENDEE, that doesn't necessarily mean the protocol 
demands this.  So this second statement is not relevant in light of 
your first comment.

>And this is actually required for shared folders since you want to 
>see items in other people calendars even if you are not a 
>participant.

Well, just because user2 wants to see events in user1's calendar, 
there's no stipulation that user1 agrees.  But this takes us way far 
afield of the original question.

>
>The important thing is how to calculate the freebusy information and 
>this is specified in iCal. It involves both, processing the 
>attendee's and the TRANSP field since it is associated with some 
>specific user:

Agreed.

>---snip---
>When used to publish busy time, the "ORGANIZER" property specifies
>the calendar user associated with the published busy time

Oh my goodness! Yes, this is what 2445 4.6.4 says.  I'm not sure 
about this...<sigh>... Well, 2445 is just a PROPOSED protocol. 
What's going on in this section needs some careful thought - more 
than I've given it.

>---snap---
>So while your local calendar can store arbitary events, a published 
>vfb entity is bound to some user. This is after all necessary to be 
>able to process the data inside when the vfb is retrieved!

Yes, but the only users to which it should be bound are ATTENDEEs.

>I agree that the spec isn't perfectly clear about that, but as far 
>as I can see this is the only useful interpretation?

"isn't perfectly clear" is a generous description imho. :-)  The way 
in which 4.6.4 describes the use of ORGANIZER for publishing 
VFREEBUSY components conflicts with the way in which ORGANIZER is 
used in VEVENTSs.  This seems like a very bad idea.

-- 
john noerenberg
[email-masked]
   --------------------------------------------------------------------
   We all learn here by the honorable path of horrible mistakes.
   -- Katherine Paterson, "The Master Puppeteer," 1975
   --------------------------------------------------------------------

Date: Fri, 19 Aug 2005 12:30:24 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Calsify <[email-masked]>
Subject: Re: [Ietf-calsify] is the ORGANIZER an ATTENDEE?
Reply-To: Calsify <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms080109030202020400070109
Content-Type: multipart/mixed; boundary="------------060209090008040708090307"

This is a multi-part message in MIME format.
--------------060209090008040708090307
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

The space shuttle launch is at 2-3pm I can turn on the TV and watch
it. It could be marked as TRANSPARENT and it is on my calendar and
does not show up in my BUSY time.

Or I could be so consumed with the desire to watch that launch that I
set my busy time for that hour so no one will book my time.
I just want the time blocked out for that VEVENT marked as TRANSPARENT.

Attendance has nothing to do with it, busy time is calculated
by saying "I am busy for this time period".

Not only that but PUBLISH events (like the shuttle launch) do NOT
have ATTENDEEs, yet can be OPAQUE or TRANSPARENT. All of which
is irrelevant to if I want my time blocked out.

And I can have my business partners OPAQUE meetings on my
calendar so I an keep in sync with what he is doing. I will
not be attending so my busy time does not calculate that
OPAQUE VEVENT.

Before TRASP was added to iCal, there was a discussion about
calendar hours of operation. The idea was to be able to
say that 'this specific' calendar is only available between
8am - 5pm Monday - Friday.  That evolved into TRANSP
so that it did not matter why that time was busy.
The ATTENDEE had nothing to do with it, it had to
do with the calendar time, not the ATTENDEE time.

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------060209090008040708090307
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------060209090008040708090307--

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

--------------ms080109030202020400070109--

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-calsify] is the ORGANIZER an ATTENDEE?
Date: Fri, 19 Aug 2005 09:56:48 -0700
To: Cyrus Daboo <[email-masked]>, Helge Hess <[email-masked]>
Cc: Calsify <[email-masked]>

Helge: The availability of a calendar user is based foremost on the 
VEVENTs, actually.  The CUA creates VEVENT objects and can then 
calculate free-busy time from those.  The only time you need VFREEBUSY 
is
   - to send free-busy time rollups over the wire
   - to export (or import) or send a blocked-out period of time that 
isn't an event

So in CalDAV, for example, we'd expect >90% of the components in a 
calendar would be VEVENT components, and only a few would be VFREEBUSY 
components stored to block out un-schedulable time (many users/CUAs 
might not have any VFREEBUSY components created).  The CalDAV server 
calculates what times are free and busy (for the REPORT) by using both 
VEVENTs and VFREEBUSYs.

Cyrus: This table does look like the kind of thing we need in the 
revised 2445 only it is less readable than I'd hope -- I'd start by 
removing the first column and using VEVENT or VFREEBUSY as a title 
instead of a first column.  Maybe then organizer and transparency could 
be the X and Y axes instead of both being in columns.

Also, wouldn't TRANSPARENT Not Present be the same as 
TRANSPARENT=OPAQUE in every case?

Lisa

On Aug 19, 2005, at 7:55 AM, Helge Hess wrote:

> On 19. Aug 2005, at 16:00 Uhr, Cyrus Daboo wrote:
>> VFREEBUSY components are obviously a different matter - I've was 
>> describing the behaviour for VEVENT components.
>
> Ah, OK, I see what you mean now ;-) Yes, I agree then, the freebusy 
> marker in the context of the VEVENT is just the TRANSP.
>
> But then the only purpose of this marker is to generate a VFREEBUSY 
> (or some similiar internal object representation) from the VEVENT?! It 
> doesn't have a lot of value to display this attribute in the CUA since 
> the availability of someone must be based on the VFREEBUSY information 
> anyway.
>
>
> However, this still doesn't have anything to do with the question of 
> the original poster (subject) though this started an impressive thread 
> ;-)
> I hope we all agree the the ORGANIZER is *not* an ATTENDEE in any case 
> and MUST be listed as an ATTENDEE if he intends to take part in the 
> timeslot?
>
>
>>> I interpret the TRANSP property as an additional property to consider
>>> whether the event is free or busy. Eg a 'birthday event' would be 
>>> marked
>>> transparent and not show up as busy, even if the the calendar user 
>>> is an
>>> attendee.
>> OK, I think its clear that 2445bis needs to say a lot more about what 
>> components/properties imply busy time for the 'owner' of the calendar 
>> containing the components. Here's an attempt at this:
>>
>>
>> +-------------------------------------------------------------+
>> |           | ORGANIZER/ATTENDEE | TRANSP       | Free/Busy   |
>> |           +====================+==============+=============+
>> |           |                    |              |             |
>> |           | No ORGANIZER       | Not present  | Busy        |
>> |           | or ATTENDEE        | TRANSPARENT  | Free        |
>> |           |                    | OPAQUE       | Busy        |
>> |           |                    |              |             |
>> |           +--------------------+--------------+-------------+
>> |           |                    |              |             |
>> | VEVENT    | ATTENDEE           | Not present  | Busy        |
>> |           | matching 'owner'   | TRANSPARENT  | Free        |
>> |           |                    | OPAQUE       | Busy        |
>> |           |                    |              |             |
>> |           +--------------------+--------------+-------------+
>> |           |                    |              |             |
>> |           | ORGANIZER          | Not present  | Free        |
>> |           | matching 'owner'   | TRANSPARENT  | Free        |
>> |           | no matching        | OPAQUE       | Busy        |
>> |           | ATTENDEE           |              |             |
>> |           |                    |              |             |
>> +-----------+--------------------+--------------+-------------+
>
> Honestly I cannot follow this table. What is the "Free/Busy" column 
> used for in the context of the operation of a CUA?
>
> During event scheduling we will always need to retrieve the VFREEBUSY 
> which is based on the ATTENDEE (+ the TRANSP).
>
> Thanks,
>   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] is the ORGANIZER an ATTENDEE?
Date: Fri, 19 Aug 2005 16:55:36 +0200
To: Calsify <[email-masked]>

On 19. Aug 2005, at 16:00 Uhr, Cyrus Daboo wrote:
> VFREEBUSY components are obviously a different matter - I've was  
> describing the behaviour for VEVENT components.

Ah, OK, I see what you mean now ;-) Yes, I agree then, the freebusy  
marker in the context of the VEVENT is just the TRANSP.

But then the only purpose of this marker is to generate a VFREEBUSY  
(or some similiar internal object representation) from the VEVENT?!  
It doesn't have a lot of value to display this attribute in the CUA  
since the availability of someone must be based on the VFREEBUSY  
information anyway.

However, this still doesn't have anything to do with the question of  
the original poster (subject) though this started an impressive  
thread ;-)
I hope we all agree the the ORGANIZER is *not* an ATTENDEE in any  
case and MUST be listed as an ATTENDEE if he intends to take part in  
the timeslot?

>> I interpret the TRANSP property as an additional property to consider
>> whether the event is free or busy. Eg a 'birthday event' would be  
>> marked
>> transparent and not show up as busy, even if the the calendar user  
>> is an
>> attendee.
> OK, I think its clear that 2445bis needs to say a lot more about  
> what components/properties imply busy time for the 'owner' of the  
> calendar containing the components. Here's an attempt at this:
>
>
> +-------------------------------------------------------------+
> |           | ORGANIZER/ATTENDEE | TRANSP       | Free/Busy   |
> |           +====================+==============+=============+
> |           |                    |              |             |
> |           | No ORGANIZER       | Not present  | Busy        |
> |           | or ATTENDEE        | TRANSPARENT  | Free        |
> |           |                    | OPAQUE       | Busy        |
> |           |                    |              |             |
> |           +--------------------+--------------+-------------+
> |           |                    |              |             |
> | VEVENT    | ATTENDEE           | Not present  | Busy        |
> |           | matching 'owner'   | TRANSPARENT  | Free        |
> |           |                    | OPAQUE       | Busy        |
> |           |                    |              |             |
> |           +--------------------+--------------+-------------+
> |           |                    |              |             |
> |           | ORGANIZER          | Not present  | Free        |
> |           | matching 'owner'   | TRANSPARENT  | Free        |
> |           | no matching        | OPAQUE       | Busy        |
> |           | ATTENDEE           |              |             |
> |           |                    |              |             |
> +-----------+--------------------+--------------+-------------+

Honestly I cannot follow this table. What is the "Free/Busy" column  
used for in the context of the operation of a CUA?

During event scheduling we will always need to retrieve the VFREEBUSY  
which is based on the ATTENDEE (+ the TRANSP).

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

Date: Fri, 19 Aug 2005 15:26:59 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] Open issues in iMIP revision (draft-ietf-calsify-rfc2447bis-00.txt)

[email-masked] wrote:

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

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

Here is the list of open issues (I've started addressing some of them):
1). In section "2.4 Content Type":

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

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

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

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

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

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

The section says:

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

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

Later in the same section RFC 2447 said:

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

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

Alexey

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

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

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

Date: Fri, 19 Aug 2005 10:00:53 -0400
From: Cyrus Daboo <[email-masked]>
To: Helge Hess <[email-masked]>, Calsify <[email-masked]>
Subject: Re: [Ietf-calsify] is the ORGANIZER an ATTENDEE?

Hi Helge,

--On August 19, 2005 12:11:29 PM +0200 Helge Hess 
<[email-masked]> wrote:

>> Hang on - this is mixing the concept of free busy time calculation
>> with whether an organiser is implicitly an attendee. From my reading
>> of 2445 the ONLY property that is used to determine free-busy state is
>> the TRANSP property - whether or not you are listed as an ATTENDEE or
>> ORGANIZER is irrelevant. So I think your assertion above is wrong
>> unless TRANSP:TRANSPARENT is specified in the event.
>
> That doesn't make a lot of sense to me. In what real-world situation
> would a freebusy entry not be bound to a specific attendee? What would a
> vfb consumer do with such a file?

VFREEBUSY components are obviously a different matter - I've was describing 
the behaviour for VEVENT components.

>> One could certainly make the case that an 'organised' event at which
>> you are not an attendee should by default be transparent - but the
>> client ought to use the TRANSP property to explicitly set that rather
>> than infer it when TRANSP is not present.
>
> I interpret the TRANSP property as an additional property to consider
> whether the event is free or busy. Eg a 'birthday event' would be marked
> transparent and not show up as busy, even if the the calendar user is an
> attendee.

OK, I think its clear that 2445bis needs to say a lot more about what 
components/properties imply busy time for the 'owner' of the calendar 
containing the components. Here's an attempt at this:

+-------------------------------------------------------------+
|           | ORGANIZER/ATTENDEE | TRANSP       | Free/Busy   |
|           +====================+==============+=============+
|           |                    |              |             |
|           | No ORGANIZER       | Not present  | Busy        |
|           | or ATTENDEE        | TRANSPARENT  | Free        |
|           |                    | OPAQUE       | Busy        |
|           |                    |              |             |
|           +--------------------+--------------+-------------+
|           |                    |              |             |
| VEVENT    | ATTENDEE           | Not present  | Busy        |
|           | matching 'owner'   | TRANSPARENT  | Free        |
|           |                    | OPAQUE       | Busy        |
|           |                    |              |             |
|           +--------------------+--------------+-------------+
|           |                    |              |             |
|           | ORGANIZER          | Not present  | Free        |
|           | matching 'owner'   | TRANSPARENT  | Free        |
|           | no matching        | OPAQUE       | Busy        |
|           | ATTENDEE           |              |             |
|           |                    |              |             |
+-----------+--------------------+--------------+-------------+

+-------------------------------------------------------------+
|           | iTIP                  | Contributes to 'owners' |
|           |                       | free/busy               |
|           +=======================+=========================+
|           |                       |                         |
|           | No ORGANIZER          | Yes                     |
|           | or ATTENDEE           |                         |
|           | (not iTIP)            |                         |
|           +-----------------------+-------------------------+
|           |                       |                         |
|           | REPLY ATTENDEE        | Yes                     |
|           | matching 'owner'      |                         |
|           | (see Notes 2 & 3)     |                         |
|           |                       |                         |
|           +-----------------------+-------------------------+
|           |                       |                         |
| VFREEBUSY | REPLY ATTENDEE not    | No                      |
|           | matching 'owner'      |                         |
|           | (see Note 2)          |                         |
|           |                       |                         |
|           +-----------------------+-------------------------+
|           |                       |                         |
|           | PUBLISH ORGANIZER     | Yes                     |
|           | matching 'owner'      |                         |
|           | (see Note 1)          |                         |
|           |                       |                         |
|           +-----------------------+-------------------------+
|           |                       |                         |
|           | PUBLISH ORGANIZER     | No                      |
|           | not matching 'owner'  |                         |
|           | (see Note 1)          |                         |
|           |                       |                         |
+-----------+-----------------------+-------------------------+

        Notes:

        1. PUBLISH'ed VFREEBUSY cannot contain ATTENDEEs,
        only ORGANIZER.

        2. The ORGANIZER in a REQUEST/REPLY iTIP exchange
        is irrelevant for purposes of free busy 'ownership'.

        3. Its not clear why an 'owner' would have their own
        REPLY in their calendar.

-- 
Cyrus Daboo

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-calsify] is the ORGANIZER an ATTENDEE?
Date: Fri, 19 Aug 2005 12:11:29 +0200
To: Calsify <[email-masked]>

On Aug 19, 2005, at 5:46, John W Noerenberg II wrote:
> Yup.  Restating the question:  Should your CUA show OPAQUE VEVENTs 
> when you are not an ATTENDEE but are the ORGANIZER?

I still think the discussion is going in the wrong direction. What the 
CUA shows is a view thing and to be decided by the CUA, its not 
standardized in the iCal spec. Most CUAs store arbitary collections of 
events and show _all_ of them, even if you are neither an organizer nor 
an attendee. And this is actually required for shared folders since you 
want to see items in other people calendars even if you are not a 
participant.

So some CUA may show organizer events, maybe tagged with some icon or 
allow some filtering ("show events organized by me"), etc. Plenty of 
freedom for the client to show the contained information in useful and 
innovative ways.

The important thing is how to calculate the freebusy information and 
this is specified in iCal. It involves both, processing the attendee's 
and the TRANSP field since it is associated with some specific user:
---snip---
When used to publish busy time, the "ORGANIZER" property specifies
the calendar user associated with the published busy time
---snap---
So while your local calendar can store arbitary events, a published vfb 
entity is bound to some user. This is after all necessary to be able to 
process the data inside when the vfb is retrieved!
I agree that the spec isn't perfectly clear about that, but as far as I 
can see this is the only useful interpretation?

On Aug 19, 2005, at 1:56, Cyrus Daboo wrote:
> Hang on - this is mixing the concept of free busy time calculation 
> with whether an organiser is implicitly an attendee. From my reading 
> of 2445 the ONLY property that is used to determine free-busy state is 
> the TRANSP property - whether or not you are listed as an ATTENDEE or 
> ORGANIZER is irrelevant. So I think your assertion above is wrong 
> unless TRANSP:TRANSPARENT is specified in the event.

That doesn't make a lot of sense to me. In what real-world situation 
would a freebusy entry not be bound to a specific attendee? What would 
a vfb consumer do with such a file?

> One could certainly make the case that an 'organised' event at which 
> you are not an attendee should by default be transparent - but the 
> client ought to use the TRANSP property to explicitly set that rather 
> than infer it when TRANSP is not present.

I interpret the TRANSP property as an additional property to consider 
whether the event is free or busy. Eg a 'birthday event' would be 
marked transparent and not show up as busy, even if the the calendar 
user is an attendee.

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

Date: Thu, 18 Aug 2005 20:46:51 -0700
To: [email-masked]
From: John W Noerenberg II <[email-masked]>
Subject: Re: [Ietf-calsify] is the ORGANIZER an ATTENDEE?
Cc: [email-masked]

At 8:10 PM -0600 8/18/05, Doug Royer wrote:
>
>TRANSP is for the VEVENT, not the ORGANIZER.

You are exactly right.

At 8:22 PM -0600 8/18/05, Doug Royer wrote:
>The issue is: Should your CUA show VEVENTs where you are not attending
>and are the ORGANIZER?
>
>If it does, and if the VEVENT is tagged as OPAQUE, then it is an
>OPAQUE VEVENT. And OPAQUE means found in busy searches.

Yup.  Restating the question:  Should your CUA show OPAQUE VEVENTs 
when you are not an ATTENDEE but are the ORGANIZER?

>
>iCal is for exchanging information between CUA's.

Well, iCalendar is for exchanging information between calendars, not CUAs.

>Most CUAs use it as the storage format.

Perhaps.  It is an implementation choice.  I won't hazard an opinion 
whether it is a good choice. :-)

>  It looks to me as if your CUA correctly told the recipients of the 
>VEVENT that it is OPAQUE.

I can't agree with this.  The CUA is part of the calendar software 
for managing a user's calendar.  But it is not *all* of the calendar 
software.

I claim that how this question is answered is a matter for the 
implementor, so how the calendar software interprets the properties 
is beyond our scope.  For example, the user may instruct the calendar 
software to regard an OPAQUE VEVENT for which the user is an 
ORGANIZER but not an ATTENDEE as FREE time for the user.  So a query 
for the user's free/busy time, would report the time spanned by the 
VEVENT as FREE.  However, a query for VEVENTs that span the time 
specified for the OPAQUE VEVENT would return this OPAQUE VEVENT in 
the list of VEVENTs satisfying the conditions of the query.  Bear in 
mind the source of the query may be the user's CUA or it may be some 
other object capable of querying the user's calendar.  The source of 
the query really doesn't matter, as far as this discussion goes.

As a user of the calendar software I may want to know about the 
events I've scheduled regardless of whether I'm an attendee; or I may 
want to know about the events for which I'm an attendee.

As a user of the calendar software I may want to know about the 
events my secretary has scheduled (if I'm a control freak); or I may 
want to know about the events those who report to me are attending 
(if I'm a control monster). :-)

-- 

john noerenberg
   ----------------------------------------------------------------------
   Statt des törichten Ignorabimus heiße im Gegenteil unsere Lösung:
   Wir müssen wissen, Wir werden wissen.
   -- David Hilbert, "Logic and the Understanding of Nature, Sep 1930
   ----------------------------------------------------------------------

Date: Thu, 18 Aug 2005 20:22:33 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Neal Gafter <[email-masked]>, [email-masked]
Subject: Re: [Ietf-calsify] is the ORGANIZER an ATTENDEE?
Reply-To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms090802010107080504060709
Content-Type: multipart/mixed; boundary="------------090000030501020905000500"

This is a multi-part message in MIME format.
--------------090000030501020905000500
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

The issue is: Should your CUA show VEVENTs where you are not attending
and are the ORGANIZER?

If it does, and if the VEVENT is tagged as OPAQUE, then it is an
OPAQUE VEVENT. And OPAQUE means found in busy searches.

iCal is for exchanging information between CUA's. Most CUAs use
it as the storage format. It looks to me as if your CUA correctly told
the recipients of the VEVENT that it is OPAQUE.

And then your CUA stored that OPAQUE VEVENT in your calendar
and correctly interpreted it as seen as busy time.

Neal Gafter wrote:
> Is the organizer of an event implicitly an attendee?  Many of the 
> calendar clients I've tried do not add the organizer as an attendee in 
> the .ics for a meeting, but do treat the organizer as busy during such 
> an event.  I could not find anything in the specs suggesting that the 
> organizer is implicitly an attendee of such an event.
> 
-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------090000030501020905000500
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------090000030501020905000500--

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

--------------ms090802010107080504060709--

Date: Thu, 18 Aug 2005 20:10:23 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Calsify <[email-masked]>
Subject: Re: [Ietf-calsify] is the ORGANIZER an ATTENDEE?
Reply-To: Calsify <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms020103070407050203010101
Content-Type: multipart/mixed; boundary="------------040201070402070603040409"

This is a multi-part message in MIME format.
--------------040201070402070603040409
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

John W Noerenberg II wrote:
> At 7:56 PM -0400 8/18/05, Cyrus Daboo wrote:
> 
>> Hang on - this is mixing the concept of free busy time calculation 
>> with whether an organiser is implicitly an attendee. From my reading 
>> of 2445 the ONLY property that is used to determine free-busy state is 
>> the TRANSP property - whether or not you are listed as an ATTENDEE or 
>> ORGANIZER is irrelevant. So I think your assertion above is wrong 
>> unless TRANSP:TRANSPARENT is specified in the event.

> 
> This would be correct if the TRANSP property MUST be specified in a 
> VEVENT.  But 2445 explicitly says TRANSP is optional.  Moreover the 
> description of VEVENT suggests that absent a TRANSP property, TRANSP = 
> OPAQUE.  But the language is not explicit.

It says: 'Default value is OPAQUE', looks explicit to me :-)

> It seems to me that TRANSP=OPAQUE should be the default, because it's 
> probably most often the case that organizers are also attendees. There 
> are classic exceptions to this, I know. (I would leave handling this to 
> implementor.)  I suggest that 2445bis always make the default state of 
> TRANSP = OPAQUE, rather than have its state depend on the inclusion of 
> ATTENDEE and/or ORGANIZER properties.

Its default is OPAQUE, and 2445 does not say that it depends on
if the ORGANIZER or ATTENDEE is attending.

It is simply a tag to indicate if the event is opaque or transparent
to busy searches. Most will be YES, so TRANSP defaults to OPAQUE.

>>
>> One could certainly make the case that an 'organised' event at which 
>> you are not an attendee should by default be transparent - but the 
>> client ought to use the TRANSP property to explicitly set that rather 
>> than infer it when TRANSP is not present.

TRANSP is for the VEVENT, not the ORGANIZER.

If you publish a VEVENT with TRANSP set to TRANSPARENT, then it
is TRANSPARENT to -ALL- ATTENDEEs. And that is not what you want.

> One could.  But one ought not. :-)  I certainly agree that including it 
> removes any ambiguity.  But I can't quite convince myself TRANSP MUST 
> occur.  As long as the default is clear, I'd rather save the bits on the 
> wire - call me old-fashioned. :-)
> 

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------040201070402070603040409
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------040201070402070603040409--

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

--------------ms020103070407050203010101--

Date: Thu, 18 Aug 2005 18:55:50 -0700
To: Cyrus Daboo <[email-masked]>, Calsify <[email-masked]>
From: John W Noerenberg II <[email-masked]>
Subject: Re: [Ietf-calsify] is the ORGANIZER an ATTENDEE?

Ah <sheepish grin>, OPAQUE is already the default....Nevermind...

At 6:35 PM -0700 8/18/05, John W Noerenberg II wrote:
>It seems to me that TRANSP=OPAQUE should be the default, because 
>it's probably most often the case that organizers are also 
>attendees. There are classic exceptions to this, I know. (I would 
>leave handling this to implementor.)  I suggest that 2445bis always 
>make the default state of TRANSP = OPAQUE, rather than have its 
>state depend on the inclusion of ATTENDEE and/or ORGANIZER 
>properties.

<mutter><mutter><mutter>

Date: Thu, 18 Aug 2005 18:35:54 -0700
To: Cyrus Daboo <[email-masked]>
From: John W Noerenberg II <[email-masked]>
Subject: Re: [Ietf-calsify] is the ORGANIZER an ATTENDEE?
Cc: Calsify <[email-masked]>

At 7:56 PM -0400 8/18/05, Cyrus Daboo wrote:
>Hang on - this is mixing the concept of free busy time calculation 
>with whether an organiser is implicitly an attendee. From my reading 
>of 2445 the ONLY property that is used to determine free-busy state 
>is the TRANSP property - whether or not you are listed as an 
>ATTENDEE or ORGANIZER is irrelevant. So I think your assertion above 
>is wrong unless TRANSP:TRANSPARENT is specified in the event.

This would be correct if the TRANSP property MUST be specified in a 
VEVENT.  But 2445 explicitly says TRANSP is optional.  Moreover the 
description of VEVENT suggests that absent a TRANSP property, TRANSP 
= OPAQUE.  But the language is not explicit.

It seems to me that TRANSP=OPAQUE should be the default, because it's 
probably most often the case that organizers are also attendees. 
There are classic exceptions to this, I know. (I would leave handling 
this to implementor.)  I suggest that 2445bis always make the default 
state of TRANSP = OPAQUE, rather than have its state depend on the 
inclusion of ATTENDEE and/or ORGANIZER properties.

>
>One could certainly make the case that an 'organised' event at which 
>you are not an attendee should by default be transparent - but the 
>client ought to use the TRANSP property to explicitly set that 
>rather than infer it when TRANSP is not present.

One could.  But one ought not. :-)  I certainly agree that including 
it removes any ambiguity.  But I can't quite convince myself TRANSP 
MUST occur.  As long as the default is clear, I'd rather save the 
bits on the wire - call me old-fashioned. :-)

-- 

john noerenberg
   ----------------------------------------------------------------------
   Statt des törichten Ignorabimus heiße im Gegenteil unsere Lösung:
   Wir müssen wissen, Wir werden wissen.
   -- David Hilbert, "Logic and the Understanding of Nature, Sep 1930
   ----------------------------------------------------------------------

Date: Thu, 18 Aug 2005 19:56:49 -0400
From: Cyrus Daboo <[email-masked]>
To: Helge Hess <[email-masked]>, Calsify <[email-masked]>
Subject: Re: [Ietf-calsify] is the ORGANIZER an ATTENDEE?

Hi Helge,

--On August 19, 2005 1:25:58 AM +0200 Helge Hess 
<[email-masked]> wrote:

> To check whether they treat the organizer as 'busy' publish your
> calendar as a freebusy file. It should _not_ contain the events where
> you are just an organizer but no attendee. (AFAIK iCal doesn't  support
> freebusy, so you can only check with Outlook).

Hang on - this is mixing the concept of free busy time calculation with 
whether an organiser is implicitly an attendee. From my reading of 2445 the 
ONLY property that is used to determine free-busy state is the TRANSP 
property - whether or not you are listed as an ATTENDEE or ORGANIZER is 
irrelevant. So I think your assertion above is wrong unless 
TRANSP:TRANSPARENT is specified in the event.

One could certainly make the case that an 'organised' event at which you 
are not an attendee should by default be transparent - but the client ought 
to use the TRANSP property to explicitly set that rather than infer it when 
TRANSP is not present.

-- 
Cyrus Daboo

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-calsify] is the ORGANIZER an ATTENDEE?
Date: Fri, 19 Aug 2005 01:25:58 +0200
To: Calsify <[email-masked]>

On 19. Aug 2005, at 01:09 Uhr, Neal Gafter wrote:
> I tried Apple ical 2.0.2 and MS Outlook, for example. Perhaps it is  
> just my misunderstanding.  If I invite my friend to lunch by  
> creating an event with him as an attendee but don't add myself as  
> an attendee, it still shows up on my calendar.

You  probably interpret the output of those tools incorrectly. What  
the calendar shows in those applications has nothing to do with the  
attendees, both just display the physical calendar records present in  
the respective calendar collections (a "folder" in Outlook, a  
"calendar" in iCal).
A lot of PIM applications lack filtering on attendees which hurts a  
lot with shared calendars.

Usually you are an attendee or at least an organizer, but this is not  
strictly required in either of the apps (eg think of a shared folder  
containing events of other people).

To check whether they treat the organizer as 'busy' publish your  
calendar as a freebusy file. It should _not_ contain the events where  
you are just an organizer but no attendee. (AFAIK iCal doesn't  
support freebusy, so you can only check with Outlook).

Greets,
   Helge

PS: people also often mix up the 'organizer' with the attendee with  
the role 'chair'. Different things in iCal (and often in real world).
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

Date: Thu, 18 Aug 2005 17:19:50 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Neal Gafter <[email-masked]>, Calsify <[email-masked]>
Subject: Re: [Ietf-calsify] is the ORGANIZER an ATTENDEE?
Reply-To: Calsify <[email-masked]>

This is a multi-part message in MIME format.
--------------010907060706070504020408
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

That is a feature/bug of the GUI you are using.

There are valid reasons to be the ORGANIZER and not attending
an event.

It is also possible to have something on your calendar and
not show as busy. Most vendors did what ever they wanted
with ORGANIZER and ATTENDEE.

Neal Gafter wrote:
> On 8/18/05, Helge Hess <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>      > Many of the calendar clients I've tried do not add the organizer as
>      > an attendee in the .ics for a meeting, but do treat the organizer
>      > as busy during such an event.
> 
>     Could you please elaborate? Which clients do so? 
> 
> 
> I tried Apple ical 2.0.2 and MS Outlook, for example. Perhaps it is just 
> my misunderstanding.  If I invite my friend to lunch by creating an 
> event with him as an attendee but don't add myself as an attendee, it 
> still shows up on my calendar.
> 

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------010907060706070504020408
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------010907060706070504020408--

Date: Thu, 18 Aug 2005 16:09:42 -0700
From: Neal Gafter <[email-masked]>
To: Helge Hess <[email-masked]>
Subject: Re: [Ietf-calsify] is the ORGANIZER an ATTENDEE?
Cc: Calsify <[email-masked]>

------=_Part_328_32706049.1124406582925
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 8/18/05, Helge Hess <[email-masked]> wrote:
>=20
> > Many of the calendar clients I've tried do not add the organizer as
> > an attendee in the .ics for a meeting, but do treat the organizer
> > as busy during such an event.
>=20
> Could you please elaborate? Which clients do so?

I tried Apple ical 2.0.2 and MS Outlook, for example. Perhaps it is just my=
=20
misunderstanding. If I invite my friend to lunch by creating an event with=
=20
him as an attendee but don't add myself as an attendee, it still shows up o=
n=20
my calendar.

------=_Part_328_32706049.1124406582925
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 8/18/05, <b class=3D"gmail_sendername">Helge Hess</b> &lt;<a href=3D"mai=
lto:[email-masked]">[email-masked]</a>&gt; wrot=
e:<div><span class=3D"gmail_quote"></span><blockquote class=3D"gmail_quote"=
 style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.=
8ex; padding-left: 1ex;">
&gt; Many of the calendar clients I've tried do not add the organizer as<br=
>&gt; an attendee in the .ics for a meeting, but do treat the organizer<br>=
&gt; as busy during such an event.<br><br>Could you please elaborate? Which=
 clients do so?
</blockquote><div><br>
I tried Apple ical 2.0.2 and MS Outlook, for example. Perhaps it is
just my misunderstanding.&nbsp; If I invite my friend to lunch by
creating an event with him as an attendee but don't add myself as an
attendee, it still shows up on my calendar.<br>
</div></div>

------=_Part_328_32706049.1124406582925--

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-calsify] is the ORGANIZER an ATTENDEE?
Date: Fri, 19 Aug 2005 00:38:03 +0200
To: Calsify <[email-masked]>

On 19. Aug 2005, at 00:32 Uhr, Neal Gafter wrote:
> Is the organizer of an event implicitly an attendee?

No.

> Many of the calendar clients I've tried do not add the organizer as  
> an attendee in the .ics for a meeting, but do treat the organizer  
> as busy during such an event.

Could you please elaborate? Which clients do so?

> I could not find anything in the specs suggesting that the  
> organizer is implicitly an attendee of such an event.

Because it isn't. The one organizing the meeting doesn't have to take  
part in a meeting for somewhat obvious reasons.

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

Date: Thu, 18 Aug 2005 15:32:25 -0700
From: Neal Gafter <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] is the ORGANIZER an ATTENDEE?

------=_Part_232_13167128.1124404345999
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Is the organizer of an event implicitly an attendee? Many of the calendar=
=20
clients I've tried do not add the organizer as an attendee in the .ics for =
a=20
meeting, but do treat the organizer as busy during such an event. I could=
=20
not find anything in the specs suggesting that the organizer is implicitly=
=20
an attendee of such an event.

------=_Part_232_13167128.1124404345999
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Is the organizer of an event implicitly an attendee?&nbsp; Many of the
calendar clients I've tried do not add the organizer as an attendee in
the .ics for a meeting, but do treat the organizer as busy during such
an event.&nbsp; I could not find anything in the specs suggesting that
the organizer is implicitly an attendee of such an event.<br>

------=_Part_232_13167128.1124404345999--

To: [email-masked]
From: [email-masked]
Sender: Michael Lee <[email-masked]>
Date: Thu, 18 Aug 2005 15:50:01 -0400
Cc: [email-masked]
Subject: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2447bis-00.txt 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Calendaring and Scheduling Standards Simplification Working Group of the IETF.

	Title		: iCalendar Message-Based Interoperability Protocol (iMIP)
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-calsify-rfc2447bis-00.txt
	Pages		: 20
	Date		: 2005-8-18
	
   This document, [iMIP], specifies a binding from the iCalendar
   Transport-independent Interoperability Protocol (iTIP) to Internet
   email-based transports. Calendaring entries defined by the iCalendar
   Object Model [iCAL] are composed using constructs from [RFC-2822],
   [RFC-2045], [RFC-2046], [RFC-2047], [RFC-2048] and [RFC-2049].

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

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

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

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-calsify-rfc2447bis-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-calsify-rfc2447bis-00.txt"; site="ftp.ietf.org";
	access-type="anon-ftp"; directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart--

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-calsify] Notes on the WG document sharing directory
Date: Wed, 17 Aug 2005 17:12:45 -0700
To: Sam Roberts <[email-masked]>
Cc: [email-masked]

Yeah, WebDAV compliance and interop is not perfect yet.  We're working 
on revising RFC2518 to improve that situation.  A trace of the network 
traffic might allow me or somebody else on the WebDAV list to diagnose 
at least whether the problem is client or server (Xythos WFS however is 
highly compliant) or server config.

lisa

On Aug 17, 2005, at 3:00 PM, Sam Roberts wrote:

> Quoting [email-masked], on Wed, Aug 03, 2005 at 
> 12:29:31AM +0200:
>> On 2. Aug 2005, at 10:58 Uhr, Lisa Dusseault wrote:
>>> - Use WebDAV to synchronize or view the directories with any
>>> WebDAV client (such as sitecopy, MacOs WebDAVFS, XP redirector or
>>> Windows "network places").
>>
>> Not that its important, but it doesn't seem to work with OSX 10.4.2
>> (times out).
>
> And hung for me, actually blocked any process that tried to look at the
> mount, like the desktop manager.... :-)
>
> Sam
>
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Date: Wed, 17 Aug 2005 18:00:45 -0400
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Notes on the WG document sharing directory
Mail-Followup-To: [email-masked]

Quoting [email-masked], on Wed, Aug 03, 2005 at 12:29:31AM +0200:
> On 2. Aug 2005, at 10:58 Uhr, Lisa Dusseault wrote:
> > - Use WebDAV to synchronize or view the directories with any  
> >WebDAV client (such as sitecopy, MacOs WebDAVFS, XP redirector or  
> >Windows "network places").
> 
> Not that its important, but it doesn't seem to work with OSX 10.4.2  
> (times out).

And hung for me, actually blocked any process that tried to look at the
mount, like the desktop manager.... :-)

Sam

From: Bill Wimer <[email-masked]>
To: [email-masked]
Date: Sat, 13 Aug 2005 16:22:43 -0400
Subject: [Ietf-calsify] Bill Wimer/Raleigh/IBM is out of the office.

I will be out of the office starting  08/12/2005 and will not return until
08/25/2005.

Please contact my manager Lenore Rowe ([email-masked]) for ESS project
items.

Date: Tue, 09 Aug 2005 22:38:41 -0400
To: [email-masked]
From: Tim Hare <[email-masked]>
Subject: [Ietf-calsify] re: Timezone registry - name only

I disagree with just having the names in a registry. Having the name of a 
timezone is useless, unless everyone has their own database to map timezone 
name to how the timezone is defined. Speaking as a user and not a 
developer, I'd feel better if there were one source for timezone 
definitions, at least as far as time-from-UTC and when daylight savings 
time starts and stops.

Actually, though, I'd really feel better if governmental entities would 
quit messing around with time - there ought to be 24 time zones, divided 
into 15 degree slices around the circumference of the earth on longitudinal 
lines, if we're going to have them at all. But that's not realistic in 
today's world, so the TZ database is my second choice.

Tim Hare
Interested Bystander, Non-Inc. 

Date: Tue, 09 Aug 2005 22:29:26 -0400
To: [email-masked], [email-masked]
From: Tim Hare <[email-masked]>
Cc: Calsify <[email-masked]>, CalDAV DevList <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Re: xCal - namespace URL

<html>
<body>
Actually, if I recall my XML rules, you can code:<br><br>
<br>
<pre>&lt;xCal:iCalendar
xmlns:xCal=&quot;http://ietf.org/rfc/rfcXXXX.txt&quot;&gt;

</pre>Namespaces apply to the containing element as well. And I agree
that the iCalendar element should be in a namespace. Just for
human-readability reasons it associates the iCalendar with the xCal
namespace, and that's a good thing to be reminded ot.<br><br>
At 04:52 PM 8/9/2005, Doug Royer wrote:<br><br>
<br>
<blockquote type=cite class=cite cite="">Julian Reschke wrote:<br>
<blockquote type=cite class=cite cite=""><br>
Just two quick formal comments...:<br>
1) Is it intentional that in the examples, the iCalendar container
element is in no namespace?</blockquote><br>
I think we need to have it in a namespace.<br>
I can go ether way.<br><br>
I think we need to define one so that mixed content can<br>
exist in an XML file.<br><br>
<blockquote type=cite class=cite cite="">2) I don't think the IETF will
let you use something like
&quot;<a href="http://ietf.org/rfc/rfcXXXX.txt" eudora="autourl">
http://ietf.org/rfc/rfcXXXX.txt</a>&quot; as namespace name; but if they
do, you probably should use
&quot;<a href="http://ietf.org/rfc/rfcXXXX" eudora="autourl">
http://ietf.org/rfc/rfcXXXX</a>&quot; (no extension)
instead.</blockquote><br>
:-)<br><br>
-- <br><br>
Doug
Royer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|
<a href="http://inet-consulting.com/" eudora="autourl">
http://INET-Consulting.com</a><br>
-------------------------------|-----------------------------<br><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
We Do Standards - You Need Standards<br><br>
<br><br>
<br>
</blockquote>
<x-sigsep><p></x-sigsep>
Tim Hare<br>
Interested Bystander, Non-Inc.</body>
</html>

Content-class: urn:content-classes:message
Date: Tue, 9 Aug 2005 17:59:37 -0700
From: "Cameron Stillion" <[email-masked]>
To: <[email-masked]>
Cc: Calsify <[email-masked]>, CalDAV DevList <[email-masked]>, [email-masked]
Subject: [Ietf-calsify] RE: [Ietf-caldav] Re: xCal - resubmitted - file name suffix

The multiple dots have no ill effects to users of Windows versions that
support long filenames (XP, 2000, and perhaps 98, though to a limited
degree) - only the final dot extension is meaningful when associating
application behaviors or displaying icons, etc. The rest of the string
is considered the filename sans extension. Like the .tar example, this
leaves further "unwrapping" of the file up to the application.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Doug Royer
Sent: Tuesday, August 09, 2005 1:47 PM
To: [email-masked]
Cc: Calsify; CalDAV DevList; [email-masked]
Subject: [Ietf-caldav] Re: xCal - resubmitted - file name suffix

[ I have set the REPLY-TO to the [email-masked] mailing
   list - This is of interest to CALSIFY and CALDAV users, but not
   really 'on topic' - Join at
   http://inet-consulting.com/mailman/listinfo/xcal ]

As to the file name suffix point . Many insisted (Mostly Microsoft and
Microsoft application developers) that iCal define a file extension.

And as I have noticed that MANY implementations store ICS files without
their text/calendar MIME header. I suspect many will for xCAL. So
without a MIME type in the file, many data typing engines would fail if
it were not for a file name suffix.

So xCal has a file extension. I do not care what it is.
And I do not care how many 'dots' are in the file name as long as the
OS's and their applications allow for it.

Cameron Stillion wrote:

> REBTW2: Extension "stacking" is not "unsupported" by most systems=20
> either. It works fine in Unix, Mac, and Windows.

It is supported by some POSIX (UNIX, Linux, BSD, and newer
Mac) applications, but not those OS's.

In fact on those POSIX OS's the 'dot' means nothing at all and it is
simply another character in the file name that can have zero to many
'dot's in the file name.

Cameron - Question: Can the windows registry handle multiple DOTs in
suffixes to files on what ever are the top most Windows versions in use?

My VERY LIMITED knowledge and testing says no, but I might not know what
I am doing as I use POSIX systems for almost everything.

--=20

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

Date: Tue, 09 Aug 2005 17:19:36 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Cc: Calsify <[email-masked]>, CalDAV DevList <[email-masked]>
Subject: [Ietf-calsify] draft-royer-timezone-registry-03.txt
Reply-To: [email-masked]

This is a multi-part message in MIME format.
--------------090908080802080608050808
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

[ REPLY-TO set to the time zone mailing list - see end of this message ]

I have started the change of removing the SERVER part
from the IANA registry.

In this draft, the TZID will list the official IANA
registry name for the time zone. And the TZURL will point to
the server that supplies the details.

Discussion takes place on [email-masked]

Copies of the draft at:

   http://INET-Consulting.com/draft-royer-timezone-registry-03.html
   http://INET-Consulting.com/draft-royer-timezone-registry-03.txt
   http://INET-Consulting.com/draft-royer-timezone-registry-03.xml

JOIN the TimeZone mailing list at:

     http://inet-consulting.com/mailman/listinfo/timezone

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------090908080802080608050808
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------090908080802080608050808--

Date: Tue, 09 Aug 2005 17:04:37 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: Timezone registration - authority
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Cc: "[email-masked]" <[email-masked]>
Reply-To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms010900070106040902080909
Content-Type: multipart/mixed; boundary="------------050704000300070708070904"

This is a multi-part message in MIME format.
--------------050704000300070708070904
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

As stated in the draft. It is not the goal of the TZ registry
to declare that it is authoritative. Its the goal to unify what
application use for time zones.

The Content of the registry is going to be initialized from
the TZ (Olson) database. That is about as official as exists
currently. And re-sync with it as the TZ database gets updated.

The TZ database people are about as official as it gets.

I am not sure how to declare the procedure in the spec. If the
self declared King of San Francisco can convince the TZ experts
that control the TZ registry to make a new entry. Then it would
be registered in an IANA sync with that database.

>> It may not be so easy for IANA to register timezones.  As was pointed 
>> out  to us in the CALSIFY meeting, timezones are defined by political 
>> processes  and that's not an easy thing for IETF or IANA to get a 
>> handle on.  Should  the IANA accept a new timezone registration by the 
>> King of San Francisco  on behalf of all of the San Francisco area?  
>> How would IANA verify a  timezone registration from Malheur county, 
>> Oregon?  If the government of  Canada does not bother registering its 
>> timezones directly with IANA, then  who is qualified to do so on its 
>> behalf?
>>
>> I know little about how to solve these problems, but I notice that 
>> the  LTRU draft  
>> (http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-10.txt)  
>> mentions special ISO advisory committees.
>>
>> Lisa
> 

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------050704000300070708070904
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------050704000300070708070904--

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

--------------ms010900070106040902080909--

Date: Tue, 09 Aug 2005 14:52:43 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Cc: Calsify <[email-masked]>, CalDAV DevList <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] xCal - namespace URL
Reply-To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms040408070303080807090907
Content-Type: multipart/mixed; boundary="------------030304040503050005060403"

This is a multi-part message in MIME format.
--------------030304040503050005060403
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Julian Reschke wrote:
> 
> 
> Just two quick formal comments...:
> 
> 1) Is it intentional that in the examples, the iCalendar container 
> element is in no namespace?

I think we need to have it in a namespace.
I can go ether way.

I think we need to define one so that mixed content can
exist in an XML file.

> 2) I don't think the IETF will let you use something like 
> "http://ietf.org/rfc/rfcXXXX.txt" as namespace name; but if they do, you 
> probably should use "http://ietf.org/rfc/rfcXXXX" (no extension) instead.

:-)

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------030304040503050005060403
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------030304040503050005060403--

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

--------------ms040408070303080807090907--

Date: Tue, 09 Aug 2005 14:47:10 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Cc: Calsify <[email-masked]>, CalDAV DevList <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Re: xCal - resubmitted - file name suffix
Reply-To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms010705010402090100040405
Content-Type: multipart/mixed; boundary="------------080208010200080206020103"

This is a multi-part message in MIME format.
--------------080208010200080206020103
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

[ I have set the REPLY-TO to the [email-masked] mailing
   list - This is of interest to CALSIFY and CALDAV users, but not
   really 'on topic' - Join at
   http://inet-consulting.com/mailman/listinfo/xcal ]

As to the file name suffix point . Many insisted (Mostly Microsoft and
Microsoft application developers) that iCal define a file extension.

And as I have noticed that MANY implementations store ICS files without
their text/calendar MIME header. I suspect many will for xCAL. So
without a MIME type in the file, many data typing engines would fail
if it were not for a file name suffix.

So xCal has a file extension. I do not care what it is.
And I do not care how many 'dots' are in the file name as
long as the OS's and their applications allow for it.

Cameron Stillion wrote:

> REBTW2: Extension "stacking" is not "unsupported" by most systems
> either. It works fine in Unix, Mac, and Windows. 

It is supported by some POSIX (UNIX, Linux, BSD, and newer
Mac) applications, but not those OS's.

In fact on those POSIX OS's the 'dot' means nothing at all
and it is simply another character in the file name that can
have zero to many 'dot's in the file name.

Cameron - Question: Can the windows registry handle multiple DOTs
in suffixes to files on what ever are the top most Windows
versions in use?

My VERY LIMITED knowledge and testing says no, but I might not
know what I am doing as I use POSIX systems for almost everything.

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------080208010200080206020103
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------080208010200080206020103--

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

--------------ms010705010402090100040405--

Date: Tue, 9 Aug 2005 13:22:10 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: [Ietf-calsify] Re: Timezone registration
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 9 Aug 2005, Doug Royer wrote:
> Is what changes frequently are the rules for time zones.
> The number of new or deleted time zones names does not change frequently.

Not necessarily true in the US.  I believe that the list of ruleset 
changes in the US is shorter than that of zones and the ruleset they 
followed.

Remember that prior to 1967, there was no uniform application of daylight 
savings time in the US.

> As I listened to Chris's suggestion, he proposed that the rules
> for time zones not be registered, just the names.

I agree about registering names, not rules; but the names that should be 
registered are the names of rulesets.

> And this is a service to implementors and vendors that are
> trying to keep up with what to call PST or US/Pacific or
> Americia/Los_Angles.

Careful.

The so-called "Pacific Time Zone" is not a single ruleset, although there 
certainly is a single ruleset for the majority of the regions that are now 
in the "Pacific Time Zone".

This is why names such as "PST" and "US/Pacific" should be avoided.

"America/Los_Angeles" should also be avoided in the registry (although it 
may be good for user interfaces) simply because such names do not scale.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Tue, 09 Aug 2005 14:18:30 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] RE: [Ietf-caldav] xCal - resubmitted.
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Cc: Calsify <[email-masked]>, CalDAV DevList <[email-masked]>, "[email-masked]" <[email-masked]>
Reply-To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms000505060505050205020801
Content-Type: multipart/mixed; boundary="------------030001070904020705060900"

This is a multi-part message in MIME format.
--------------030001070904020705060900
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

[ I have set the REPLY-TO the [email-masked] mailing
   list - This is of interest to CALSIFY and CALDAV users, but not
   really 'on topic' - Join at
   http://inet-consulting.com/mailman/listinfo/xcal ]

> Anyway, is there anyone else who feels as I do that enforcing both xcal
> and ical as multipart alternative is overkill?  Or is this also beyond
> the scope of this proposal?

This is left over from the CALSCH days.

When Frank, Surendra, and I did the first XCAL, we were told
by the AD's at the time that they would not endorse ANOTHER
calendar data format, unless it was an alternate view of
iCalendar data. So the agreed solution was that xCal objects
would be attached as an alternate view to iCal objects.

Currently iMIP requires that people use S/MIME. I do not recall
seeing many S/MIME iCalendar emails.

The danger here is that we re-invent the wheel breaking things.
The purpose of CALSIFY is to simplify and make a set of objects
and procedures that will enable iCal and vendors to have standard
calendaring objects. If we open up the debate to XML 'IS calendaring'
then all that is compatibility that we already have is lost.

There are many XML parsers out there and XML can be
transformed back into iCal (see my posting of the XSLT
translation on the xCal mailing list).

How do we enable XML and not disrupt iCal ?

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------030001070904020705060900
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------030001070904020705060900--

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

--------------ms000505060505050205020801--

Date: Tue, 09 Aug 2005 13:51:38 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: "[email-masked]" <[email-masked]>
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Subject: [Ietf-calsify] Re: Timezone registration
Reply-To: "[email-masked]" <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms040900070507070504080200
Content-Type: multipart/mixed; boundary="------------020703050708020003050401"

This is a multi-part message in MIME format.
--------------020703050708020003050401
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Is what changes frequently are the rules for time zones.
The number of new or deleted time zones names does not change frequently.

As I listened to Chris's suggestion, he proposed that the rules
for time zones not be registered, just the names.

And this is a service to implementors and vendors that are
trying to keep up with what to call PST or US/Pacific or
Americia/Los_Angles. With the just signed in US energy
bill that includes changes to US time zones, they did not
specify what to call those time zones in iCalendar.

Lisa Dusseault wrote:
> On Tue, 02 Aug 2005 16:14:09 -0700, Doug Royer <[email-masked]> wrote:
> 
>>
>>
>> Lisa Dusseault wrote:
>>
>>> I'm not sure what it means to say that IANA "wants to do" a registry.
>>> It's my understanding that IANA implements registries (provided they're
>>> technically able to) based on IETF recommendations resulting from IETF
>>> review of proposals.  So it would seem more important whether the IETF
>>> wants IANA to do a registry (and how) and the CALSIFY WG discussion
>>> raised  a few important questions about that.
>>
>>
>> I understand it to mean like Chris Newman described in the meeting.
>> Register the names, leave the details to the vendors or services.
> 
> 
> It may not be so easy for IANA to register timezones.  As was pointed 
> out  to us in the CALSIFY meeting, timezones are defined by political 
> processes  and that's not an easy thing for IETF or IANA to get a handle 
> on.  Should  the IANA accept a new timezone registration by the King of 
> San Francisco  on behalf of all of the San Francisco area?  How would 
> IANA verify a  timezone registration from Malheur county, Oregon?  If 
> the government of  Canada does not bother registering its timezones 
> directly with IANA, then  who is qualified to do so on its behalf?
> 
> I know little about how to solve these problems, but I notice that the  
> LTRU draft  
> (http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-10.txt)  
> mentions special ISO advisory committees.
> 
> Lisa

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------020703050708020003050401
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------020703050708020003050401--

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

--------------ms040900070507070504080200--

Content-class: urn:content-classes:message
Date: Tue, 9 Aug 2005 11:16:10 -0700
From: "Cameron Stillion" <[email-masked]>
To: "Helge Hess" <[email-masked]>
Cc: Calsify <[email-masked]>, CalDAV DevList <[email-masked]>
Subject: [Ietf-calsify] RE: [Ietf-caldav] xCal - resubmitted.

I appreciate your point Helge - still, the standard can scarcely avoid
using a filename (see attachments section) and actually, this seems like
a very simple and meaningful place to provide interoperability
guidelines. Most other "file format" standards cannot avoid it, or
choose instead to specify it. That's probably why it's here in the first
place.

Are you suggesting we remove all references to filenames/extensions from
this draft? And in general, would you say we should not suggest anything
outside the internals of the MIME type itself? =20
In practice, I find this incomplete - but if you think it belongs
elsewhere, that's fine.

REBTW1: the distinction between an encapsulated format and a
specialization of a format is a fine one.  I rather think extensions are
useful hints, not strictly delineations of encapsulation or (indeed) of
specialization.  But the similarities here are useful. I understand your
concern, but the purpose is merely informational, not a strict
non-repudiation of format, encoding, or schema.

REBTW2: Extension "stacking" is not "unsupported" by most systems
either. It works fine in Unix, Mac, and Windows.=20

Anyway, is there anyone else who feels as I do that enforcing both xcal
and ical as multipart alternative is overkill?  Or is this also beyond
the scope of this proposal?

-----Original Message-----
From: Helge Hess [mailto:[email-masked]]=20
Sent: Tuesday, August 09, 2005 9:54 AM
To: Cameron Stillion
Cc: Calsify; CalDAV DevList
Subject: Re: [Ietf-caldav] xCal - resubmitted.

now thats getting entirely off-topic, but anwyay ...

On 9. Aug 2005, at 18:12 Uhr, Cameron Stillion wrote:
> (interestingly enough, it seems MacOS is now, in many cases, favoring=20
> file extensions and "all the data in the 'data fork'" rather than=20
> using separate resource forks.  Fascinating...)

Its that way for a long time (~4 years?), since NeXTstep 5 aka MacOSX.

If you are interested on the topic:
   http://arstechnica.com/reviews/os/macosx-10.4.ars/11

> But philosophically, why not put "publisher's clearinghouse=20
> sweepstakes" on the OUTSIDE of the envelope as well?

You can, but you started to discuss clever ways of file extension
mapping which is not used that way anywhere (except for informational
purposes). This is IMHO out of scope of the RFC, better avoid the whole
issue.

BTW: the example of "file.xml.xcal" is _not_ the same thing like
"file.tar.gz". The latter forms no typing hierarchy but a stacking of
formats (converting a .gz will result in a .tar, its not a special type
or "subclass" of .tar). BTW2: Few systems support such stacking which is
why .tgz is not so unusual either.

> If we speak of attachments, we're going to have to pick something to=20
> use in our examples.

I don't see how this would matter for the xCal spec. It describes the
data format, not the transport and therefore doesn't include any
filenames (with or without extensions).
Do I miss something?

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

From: Helge Hess <[email-masked]>
Date: Tue, 9 Aug 2005 18:54:27 +0200
To: "Cameron Stillion" <[email-masked]>
Cc: Calsify <[email-masked]>, CalDAV DevList <[email-masked]>
Subject: [Ietf-calsify] Re: [Ietf-caldav] xCal - resubmitted.

now thats getting entirely off-topic, but anwyay ...

On 9. Aug 2005, at 18:12 Uhr, Cameron Stillion wrote:
> (interestingly enough, it seems MacOS is now, in many cases, favoring
> file extensions and "all the data in the 'data fork'" rather than  
> using
> separate resource forks.  Fascinating...)

Its that way for a long time (~4 years?), since NeXTstep 5 aka MacOSX.

If you are interested on the topic:
   http://arstechnica.com/reviews/os/macosx-10.4.ars/11

> But philosophically, why not put "publisher's
> clearinghouse sweepstakes" on the OUTSIDE of the envelope as well?

You can, but you started to discuss clever ways of file extension  
mapping which is not used that way anywhere (except for informational  
purposes). This is IMHO out of scope of the RFC, better avoid the  
whole issue.

BTW: the example of "file.xml.xcal" is _not_ the same thing like  
"file.tar.gz". The latter forms no typing hierarchy but a stacking of  
formats (converting a .gz will result in a .tar, its not a special  
type or "subclass" of .tar). BTW2: Few systems support such stacking  
which is why .tgz is not so unusual either.

> If we speak of attachments, we're going to have to pick something  
> to use in our
> examples.

I don't see how this would matter for the xCal spec. It describes the  
data format, not the transport and therefore doesn't include any  
filenames (with or without extensions).
Do I miss something?

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

Content-class: urn:content-classes:message
Date: Tue, 9 Aug 2005 09:12:14 -0700
From: "Cameron Stillion" <[email-masked]>
To: "Helge Hess" <[email-masked]>
Cc: Calsify <[email-masked]>, CalDAV DevList <[email-masked]>
Subject: [Ietf-calsify] RE: [Ietf-caldav] xCal - resubmitted.

Not instead of - just in addition to. It's just a hint.  Windows also
has "forested" files, and "structured" files, just like Mac's "resource
forks". I agree you'd never want to use a filename INSTEAD of the actual
annotations internally.  But philosophically, why not put "publisher's
clearinghouse sweepstakes" on the OUTSIDE of the envelope as well?=20

Perhaps it doesn't belong in this particular document, though it seems
many format documents have trouble avoiding it.  If we speak of
attachments, we're going to have to pick something to use in our
examples.

Design sneaks into implementation...

(interestingly enough, it seems MacOS is now, in many cases, favoring
file extensions and "all the data in the 'data fork'" rather than using
separate resource forks.  Fascinating...)

cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Helge Hess
Sent: Tuesday.09.August.2005 04.20
To: Cameron Stillion
Cc: Calsify; CalDAV DevList
Subject: Re: [Ietf-caldav] xCal - resubmitted.

On Aug 9, 2005, at 12:59, Cameron Stillion wrote:
> The idea here is to give processing software an idea what is inside=20
> the envelope.  If you are familiar with the envelope/letter approach=20
> to data abstraction, it is a very powerful metaphor.  This proposal=20
> mentions that it will NOT use .xml as an extensions - presumably for=20
> this same reason.  If all applications, MTAs, and processing software=20
> of all operating systems begin to name data files based on the use of=20
> xml, pretty soon all documents will have the .xml extension. Great. =20
> We might as well call everything data.xml, and go ahead with a full=20
> parse of the content to determine what to do next.  The performance=20
> implications of this are rather dismal, and the design I find not very

> useful.  Why NOT give a hint as to the content using an extension?

While I agree with all of that, I honestly think that it doesn't belong
into a specification on the xCal data format.

Standardizing content typing is a completely different story and
actually one which is already covered and widely implemented in RFCs:=20
MIME. This is used for both, transmitting iCal/xCal by mail and for
storing iCal/xCal content in HTTP servers.
How MIME is mapped to local storages (extensions, resource forks, FS
annotations, spotlight attributes etc) is entirely operating system
dependend.

So in my opinion you might want to document a file-extension "best
practice" for xCal, but it doesn't really belong into the RFC. The RFC
should just outline the MIME type.

> I do not know how a more simple and direct way of giving a hint to the

> processing software might be, than to annotate the name of the content
> -
> but I am always willing to learn.  What are these "better ways" you=20
> speak of?

Well, annotating the content instead of the name? Googling for MacOS
resource forks might be a starting point to find out why file extensions
are problematic ;-)

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

_______________________________________________
Ietf-caldav mailing list -- [email-masked] See
http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Date: Tue, 09 Aug 2005 16:29:07 +0200
From: Julian Reschke <[email-masked]>
To: Dan Connolly <[email-masked]>
Cc: [email-masked], Calsify <[email-masked]>, "[email-masked]" <[email-masked]>, CalDAV DevList <[email-masked]>, [email-masked]
Subject: [Ietf-calsify] Re: [Ietf-caldav] xCal - resubmitted.

Dan Connolly wrote:
> On Tue, 2005-08-09 at 11:08 +0200, Julian Reschke wrote:
> [...]
> 
>>>Copies of the draft at:
>>>
>>>    http://INET-Consulting.com/draft-royer-calsch-xcal-01.txt
>>>    http://INET-Consulting.com/draft-royer-calsch-xcal-01.html
>>>    http://INET-Consulting.com/draft-royer-calsch-xcal-01.xml
>>
>>Just two quick formal comments...:
>>
>>1) Is it intentional that in the examples, the iCalendar container 
>>element is in no namespace?
>>
>>2) I don't think the IETF will let you use something like 
>>"http://ietf.org/rfc/rfcXXXX.txt" as namespace name;
> 
> 
> Right; I gather Best Current Practice is...
> 
> [[[
> If the registrant wishes to
>    have a URI assigned, then a URN of the form
> 
>       urn:ietf:params:xml:<class>:<id>
> 
>    will be assigned where <class> is the type of the document being
>    registered (see below).
> ]]]
>  -- http://www.faqs.org/rfcs/rfc3688.html

One could probably also use: <urn:ietf:rfc:NNNN> (see 
<http://ietf.org/rfc/rfc2648>).

> ...

Best regards, Julian

From: Dan Connolly <[email-masked]>
To: Julian Reschke <[email-masked]>
Organization: World Wide Web Consortium (http://www.w3.org/)
Date: Tue, 09 Aug 2005 09:25:18 -0500
Cc: [email-masked], Calsify <[email-masked]>, "[email-masked]" <[email-masked]>, CalDAV DevList <[email-masked]>, [email-masked]
Subject: [Ietf-calsify] Re: [Ietf-caldav] xCal - resubmitted.

On Tue, 2005-08-09 at 11:08 +0200, Julian Reschke wrote:
[...]
> > Copies of the draft at:
> > 
> >     http://INET-Consulting.com/draft-royer-calsch-xcal-01.txt
> >     http://INET-Consulting.com/draft-royer-calsch-xcal-01.html
> >     http://INET-Consulting.com/draft-royer-calsch-xcal-01.xml
> Just two quick formal comments...:
> 
> 1) Is it intentional that in the examples, the iCalendar container 
> element is in no namespace?
> 
> 2) I don't think the IETF will let you use something like 
> "http://ietf.org/rfc/rfcXXXX.txt" as namespace name;

Right; I gather Best Current Practice is...

[[[
If the registrant wishes to
   have a URI assigned, then a URN of the form

      urn:ietf:params:xml:<class>:<id>

   will be assigned where <class> is the type of the document being
   registered (see below).
]]]
 -- http://www.faqs.org/rfcs/rfc3688.html

Meanwhile, you can get an http namespace name from W3C if you like:

"W3C provides the service of allocating and maintaining persistent URIs
so that those URIs remain stable during discussions. Allocation does not
imply any endorsement by W3C of the related specifications."
 -- http://www.w3.org/1999/10/nsuri

see for example http://www.w3.org/2005/Atom

>  but if they do, you 
> probably should use "http://ietf.org/rfc/rfcXXXX" (no extension) instead.

Actually I think the .txt form is more official:

[[
The full
   text of the specification is then available using the following URL:

      http://www.ietf.org/rfc/rfcNNNN.txt

   where "NNNN" is the number of the RFC being submitted.
]]
 -- section 3.4.2 Submitting IETF Documents to JTC1
http://www.ietf.org/rfc/rfc3563.txt

The /rfc/rfcXXXX form is supported by accident, as far as I can tell.

> Best regards, Julian

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Date: Tue, 09 Aug 2005 08:28:53 -0400
From: Cyrus Daboo <[email-masked]>
To: Lisa Dusseault <[email-masked]>, Mark Crispin <[email-masked]>
Subject: Re: [Ietf-calsify] Timezone registration
Cc: [email-masked]

Hi Lisa,

--On August 8, 2005 10:28:18 PM -0700 Lisa Dusseault 
<[email-masked]> wrote:

> I quite liked what I heard from Patrik at the meeting, that people
> actually schedule meetings with reference to the time in a particular
> *place* rather than in a particular timezone.  I've seen more software
> recently, probably based on the Olsen database, allow the user to pick a
> place like "America/San Francisco" rather than a timezone like PST.  I
> hope that means is that when I schedule recurring meetings in San
> Francisco the recurrence is always calculated according to the best known
> time in San Francisco even if San Francisco were to secede from PST.

That's not always true. A lot of 'schedules' in the real world do use 
timezone names and not location indicators, e.g. airline schedules. So we 
need a scheme that can map either a location or 'common timezone name' into 
a VTIMEZONE object reference.

-- 
Cyrus Daboo

From: Helge Hess <[email-masked]>
Date: Tue, 9 Aug 2005 13:20:22 +0200
To: "Cameron Stillion" <[email-masked]>
Cc: Calsify <[email-masked]>, CalDAV DevList <[email-masked]>
Subject: [Ietf-calsify] Re: [Ietf-caldav] xCal - resubmitted.

On Aug 9, 2005, at 12:59, Cameron Stillion wrote:
> The idea here is to give processing software an idea what is inside the
> envelope.  If you are familiar with the envelope/letter approach to 
> data
> abstraction, it is a very powerful metaphor.  This proposal mentions
> that it will NOT use .xml as an extensions - presumably for this same
> reason.  If all applications, MTAs, and processing software of all
> operating systems begin to name data files based on the use of xml,
> pretty soon all documents will have the .xml extension. Great.  We 
> might
> as well call everything data.xml, and go ahead with a full parse of the
> content to determine what to do next.  The performance implications of
> this are rather dismal, and the design I find not very useful.  Why NOT
> give a hint as to the content using an extension?

While I agree with all of that, I honestly think that it doesn't belong 
into a specification on the xCal data format.

Standardizing content typing is a completely different story and 
actually one which is already covered and widely implemented in RFCs: 
MIME. This is used for both, transmitting iCal/xCal by mail and for 
storing iCal/xCal content in HTTP servers.
How MIME is mapped to local storages (extensions, resource forks, FS 
annotations, spotlight attributes etc) is entirely operating system 
dependend.

So in my opinion you might want to document a file-extension "best 
practice" for xCal, but it doesn't really belong into the RFC. The RFC 
should just outline the MIME type.

> I do not know how a more simple and direct way of giving a hint to the
> processing software might be, than to annotate the name of the content 
> -
> but I am always willing to learn.  What are these "better ways" you
> speak of?

Well, annotating the content instead of the name? Googling for MacOS 
resource forks might be a starting point to find out why file 
extensions are problematic ;-)

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

Content-class: urn:content-classes:message
Date: Tue, 9 Aug 2005 03:59:08 -0700
From: "Cameron Stillion" <[email-masked]>
To: "Reinhold Kainhofer" <[email-masked]>
Cc: Calsify <[email-masked]>, CalDAV DevList <[email-masked]>
Subject: [Ietf-calsify] RE: [Ietf-caldav] xCal - resubmitted.

I'm glad there are others who remember such tools.

Surely there are more stringent mechanisms than looking at the file
extension - this is simply the first hint.  This is the reason that file
extensions were invented, to give the first hint as to what to do with
the file.  It treats the file as an object, and lends the file system an
object-oriented nature.  Applications, verbs, or actions can be
associated with extensions or schemes, or both. =20

Granted, it is not the last word.  I can rename a text file with .exe or
.tar, but in unix or windows or osx, this does not mean it will
execute... And this approach is not specific to any particular OS, to be
sure.

The idea here is to give processing software an idea what is inside the
envelope.  If you are familiar with the envelope/letter approach to data
abstraction, it is a very powerful metaphor.  This proposal mentions
that it will NOT use .xml as an extensions - presumably for this same
reason.  If all applications, MTAs, and processing software of all
operating systems begin to name data files based on the use of xml,
pretty soon all documents will have the .xml extension. Great.  We might
as well call everything data.xml, and go ahead with a full parse of the
content to determine what to do next.  The performance implications of
this are rather dismal, and the design I find not very useful.  Why NOT
give a hint as to the content using an extension?=20

I do not know how a more simple and direct way of giving a hint to the
processing software might be, than to annotate the name of the content -
but I am always willing to learn.  What are these "better ways" you
speak of?=20

Cameron

-----Original Message-----
From: Reinhold Kainhofer [mailto:[email-masked]]=20
Sent: Tuesday.09.August.2005 03.23
To: Cameron Stillion
Cc: Calsify; CalDAV DevList
Subject: Re: [Ietf-caldav] xCal - resubmitted.

On Tuesday 09 August 2005 11:35, Cameron Stillion wrote:
> 2.12
> 	how about using a double extension - <filename>.xml.xcs
> 	This is reminiscent of tar files for those who are ancient
enough to=20
> remember those

Sorry, but just because tar archives are not common under Windows,
doesn't mean they are ancient. In fact, they are the most common
compressed archive format in Linux and also on Unix systems, far more
popular than zip files!=20
E.g. almost all source code for Linux applications (if not accessed
through svn, cvs or some other versioning system) is distributed as
gzipped tar files or bziped tar files.=20

> - anytime to add another layer of
> schematization over a file, you add an extension.  Why don't we follow

> the same pattern? I can't think of a good reason not to.

File names (and thus also the part after a period in the file name) in
Linux don't really have such a strong binding to the file type than the
file name extensions in Windows.=20

> 	While you're at it - why not go another step further and specify
file=20
> extensions for the different types of iCals (which the ical standard=20
> unfortunately failed to do) - for instance, a meeting request=20
> "method=3D'request'" might have an extension of .xrc while a published =

> calendar "method=3D'publish'" might have an extension of .xcs - this=20
> gives everyone a much more tangible understanding of the data without=20
> having to crack it and parse it first. There's a thought.

As I said, in Linux and unix systems, the file name extension is
typically not associated with the file content as strong as Windows uses
them. Sure, they can be used to indicate the type of a file, but that's
noting more than an indication and doesn't mean it really has to be that
type of file. There are better means of determining the contents of a
file in Linux.

Cheers,
Reinhold
--
------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien,
http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: "Cameron Stillion" <[email-masked]>
Date: Tue, 9 Aug 2005 12:22:31 +0200
Cc: Calsify <[email-masked]>, CalDAV DevList <[email-masked]>
Subject: [Ietf-calsify] Re: [Ietf-caldav] xCal - resubmitted.

--nextPart3176406.cJ48L3No6I
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Tuesday 09 August 2005 11:35, Cameron Stillion wrote:
> 2.12
> 	how about using a double extension - <filename>.xml.xcs
> 	This is reminiscent of tar files for those who are ancient
> enough to remember those=20

Sorry, but just because tar archives are not common under Windows, doesn't=
=20
mean they are ancient. In fact, they are the most common compressed archive=
=20
format in Linux and also on Unix systems, far more popular than zip files!=
=20
E.g. almost all source code for Linux applications (if not accessed through=
=20
svn, cvs or some other versioning system) is distributed as gzipped tar fil=
es=20
or bziped tar files.=20

> - anytime to add another layer of=20
> schematization over a file, you add an extension.  Why don't we follow
> the same pattern? I can't think of a good reason not to.

=46ile names (and thus also the part after a period in the file name) in Li=
nux=20
don't really have such a strong binding to the file type than the file name=
=20
extensions in Windows.=20

> 	While you're at it - why not go another step further and specify
> file extensions for the different types of iCals (which the ical
> standard unfortunately failed to do) - for instance, a meeting request
> "method=3D'request'" might have an extension of .xrc while a published
> calendar "method=3D'publish'" might have an extension of .xcs - this gives
> everyone a much more tangible understanding of the data without having
> to crack it and parse it first. There's a thought.

As I said, in Linux and unix systems, the file name extension is typically =
not=20
associated with the file content as strong as Windows uses them. Sure, they=
=20
can be used to indicate the type of a file, but that's noting more than an=
=20
indication and doesn't mean it really has to be that type of file. There ar=
e=20
better means of determining the contents of a file in Linux.

Cheers,
Reinhold
=2D-=20
=2D-----------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.a=
t/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer

--nextPart3176406.cJ48L3No6I
Content-Type: application/pgp-signature

--nextPart3176406.cJ48L3No6I--

Content-class: urn:content-classes:message
Date: Tue, 9 Aug 2005 02:35:09 -0700
Priority: Non-Urgent
Importance: low
From: "Cameron Stillion" <[email-masked]>
To: "Doug Royer" <[email-masked]>
Cc: [email-masked], Calsify <[email-masked]>, CalDAV DevList <[email-masked]>, [email-masked], [email-masked]
Subject: [Ietf-calsify] RE: [Ietf-caldav] xCal - resubmitted.

2.2.1
	Are you minimizing the difference between the inherent unicode
capabilities of XML and the rather esoteric encoding requirements of
iCal? Simply wrapping the data in tags is not really enough...

2.2.2
	isomeric - I think you mean "isometric".  Ah, the difference one
character can make...

	also - why is it required to send an alternate MIME body part in
normal iCal format? Is this format designed to replace the old format?
Ultimately? If so, why should both be required? iCal readers of old can
read xcal via transform, and new applications can easily parse using a
standard xml parser... Why limit all uses of this to also implement the
old way of doing things? This seems counter productive to me.

2.11
	why not simply use "text/xcal" ?=20

	again, why the restriction for backwards compatability? This
sounds like you are enforcing client functionality. How about you allow
the MTA or client application to determine whether or not to send a
downlevel representation?

2.12
	how about using a double extension - <filename>.xml.xcs
	This is reminiscent of tar files for those who are ancient
enough to remember those - anytime to add another layer of
schematization over a file, you add an extension.  Why don't we follow
the same pattern? I can't think of a good reason not to.

	While you're at it - why not go another step further and specify
file extensions for the different types of iCals (which the ical
standard unfortunately failed to do) - for instance, a meeting request
"method=3D'request'" might have an extension of .xrc while a published
calendar "method=3D'publish'" might have an extension of .xcs - this =
gives
everyone a much more tangible understanding of the data without having
to crack it and parse it first. There's a thought.

Date: Tue, 09 Aug 2005 11:08:31 +0200
From: Julian Reschke <[email-masked]>
To: Doug Royer <[email-masked]>
Cc: [email-masked], Calsify <[email-masked]>, CalDAV DevList <[email-masked]>, [email-masked], "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Re: [Ietf-caldav] xCal - resubmitted.

Doug Royer wrote:
> 
> 
> The xCal draft has been rewritten and submitted to the IETF.
> 
> I have an XSLT translation file that I will be releasing
> soon on SourceForge that can translate an xCal object
> back to an iCal object. I am waiting for SourceForge
> to approve the project name.
> 
> Discussion takes place on [email-masked]
> 
> Copies of the draft at:
> 
>     http://INET-Consulting.com/draft-royer-calsch-xcal-01.txt
>     http://INET-Consulting.com/draft-royer-calsch-xcal-01.html
>     http://INET-Consulting.com/draft-royer-calsch-xcal-01.xml
> 
> 
> JOIN the xCal mailing list at:
> 
>     http://inet-consulting.com/mailman/listinfo/xcal
> 

Just two quick formal comments...:

1) Is it intentional that in the examples, the iCalendar container 
element is in no namespace?

2) I don't think the IETF will let you use something like 
"http://ietf.org/rfc/rfcXXXX.txt" as namespace name; but if they do, you 
probably should use "http://ietf.org/rfc/rfcXXXX" (no extension) instead.

Best regards, Julian

Date: Mon, 8 Aug 2005 22:40:24 -0700
From: Mark Crispin <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-calsify] Timezone registration
Organization: Networks & Distributed Computing
Sender: [email-masked]
Cc: "[email-masked]" <[email-masked]>

On Mon, 8 Aug 2005, Lisa Dusseault wrote:
> That's not a bad scheme but unnecessary with iCalendar.  In iCalendar you can 
> define a timezone that is -0800 from 1987 until 2007 and then something else 
> from 2007 onward.

Huh?  The US Pacific time zone will still be -0800 after 2007.  The only 
thing that changes is four additional weeks of summer time (at -0700).

> In fact it's necessary to put both the pre and post-2007 
> rules into one timezone because a meeting that recurs over a time period that 
> crosses from 2006 into 2007 needs to have its recurrences calculated out 
> according to both the old and the new DST rules.

Not necessarily so.  If a meeting takes place with attendees in multiple 
time zones, an adminstrative decision has to take place with each decree 
of a new rule to determine who has to adjust.

For example, if you have a regularly scheduled teleconference between New 
York and London, and the rule in the US changes, do the Londoners have to 
adjust or do the New Yorkers?  What if the rule in the UK changes?  Maybe 
it depends which city has the head office.

Hence the desirability to register a *rule*, independent of a timezone. 
Among other things, that means that that you only have to register 1 new 
rule for the US change in 2007, not one for each US time zone.

> I quite liked what I heard from Patrik at the meeting, that people actually 
> schedule meetings with reference to the time in a particular *place* rather 
> than in a particular timezone.

Correct.  "America/San Francisco" is in effect, what "-0800 US/1987" is; 
"the -0800 timezone with the US 1987 summer time rule".

However, I think that it is madness to register names such as "America/San 
Francisco" since it doesn't scale.  Such names are OK as friendly alias 
names; nothing prevents a program from having "San Francisco time" as 
adhering to a particular set of rules.  But those should not be the rule 
names themselves.

Otherwise, you have the situation where I'm forced to set a Seattle time 
rule as being "San Francisco" because some programmer didn't think that 
Seattle was important enough, and then if in the future there is a 
difference the schedule gets screwed up.  Worse, if I can't add Seattle 
separately I can't fix it because that would break the San Francisco 
schedules.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Tue, 09 Aug 2005 07:39:26 +0200
From: Eliot Lear <[email-masked]>
To: Tim Hare <[email-masked]>
Subject: Re: [Ietf-calsify] Timezone registration
Cc: "[email-masked]" <[email-masked]>

The general concern here is that while the countries are competent
authorities to set their timezones, they are not technically competent
to report this fact in some machine readable way.

But as Chris Newman pointed out to me, perhaps we can consider this in
terms of velocity of change.  The timezone names themselves do not
change very often at all.  It is the meaning behind them that changes
all of the time.  IANA is perfectly competent to keep the names, but
perhaps not so much for the information behind them.  One could have a
policy of IESG or ICANN approval if one wanted.

Chris' other point was that software/hardware vendors are perfectly
capable of updating the database through their normal sw update processes.

On the other hand, timezone names are really NOT hard to put into the
DNS, and we could distribute control to those who are already recognized
as competent, at the cost of having to eventually rename timezones from
what is now used.

Eliot

Date: Mon, 08 Aug 2005 22:28:18 -0700
To: "Mark Crispin" <[email-masked]>
Subject: Re: [Ietf-calsify] Timezone registration
From: "Lisa Dusseault" <[email-masked]>
Organization: OSAF
Cc: "[email-masked]" <[email-masked]>

That's not a bad scheme but unnecessary with iCalendar.  In iCalendar you  
can define a timezone that is -0800 from 1987 until 2007 and then  
something else from 2007 onward.  In fact it's necessary to put both the  
pre and post-2007 rules into one timezone because a meeting that recurs  
over a time period that crosses from 2006 into 2007 needs to have its  
recurrences calculated out according to both the old and the new DST rules.

I quite liked what I heard from Patrik at the meeting, that people  
actually schedule meetings with reference to the time in a particular  
*place* rather than in a particular timezone.  I've seen more software  
recently, probably based on the Olsen database, allow the user to pick a  
place like "America/San Francisco" rather than a timezone like PST.  I  
hope that means is that when I schedule recurring meetings in San  
Francisco the recurrence is always calculated according to the best known  
time in San Francisco even if San Francisco were to secede from PST.

Lisa

On Mon, 08 Aug 2005 18:51:50 -0700, Mark Crispin <[email-masked]>  
wrote:

> Suggestion:
>
> Consider the registry not of timezone, but of daylight savings time  
> rules.
>
> Thus, instead of my local time zone being "US Pacific time", it would be  
> -0800 with the "US/1987" daylight savings time rule (soon to be replaced  
> with the "US/2007" rule).
>
> There can also be some syntax (but not a registered rule!) that  
> indicates "contemporary rule for that time".  In other words, something  
> like "-0800 US" would mean something different in 1986 than today, and  
> in turn it would mean something different in 2007.
>
> It needs to be emphasize the latter is not a registered rule, but rather  
> a shorthand for a registered rule, and which generally can not be relied  
> upon (hence you should use a registered rule such as -0800 US/1987").
>
> Excuse me if this sort of this has already been considered and rejected.
>
> -- Mark --
>
> http://staff.washington.edu/mrc
> Science does not emerge from voting, party politics, or public debate.
> Si vis pacem, para bellum.

Date: Mon, 08 Aug 2005 22:30:56 -0400
To: "[email-masked]" <[email-masked]>
From: Tim Hare <[email-masked]>
Subject: Re: [Ietf-calsify] Timezone registration

>" Should  the IANA accept a new timezone registration by the King of San 
>Francisco
>on behalf of all of the San Francisco area?"
>
>Lisa
>_______________________________________________

No, of course not. Every San Franciscan knows you should only accept edicts 
from descendants of Emperor Norton: http://www.sfmuseum.org/hist1/norton.html

All kidding aside, though - don't most countries have the equivalent of our 
National Institute of Standards and Technology? An RFC which described 
timezones and their registration, it seems to me, could also designate what 
the official source is for such information, or could at least state that 
each national government should designate an official source. I realize 
that the zones are often set by smaller governmental entities such as 
states, but there's almost always some national body which keeps track of them.

Tim Hare
Interested Bystander, Non-Inc. 

Date: Mon, 8 Aug 2005 18:51:50 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-calsify] Timezone registration
Organization: Networks & Distributed Computing
Sender: [email-masked]
Cc: "[email-masked]" <[email-masked]>

Suggestion:

Consider the registry not of timezone, but of daylight savings time rules.

Thus, instead of my local time zone being "US Pacific time", it would be 
-0800 with the "US/1987" daylight savings time rule (soon to be replaced 
with the "US/2007" rule).

There can also be some syntax (but not a registered rule!) that indicates 
"contemporary rule for that time".  In other words, something like "-0800 
US" would mean something different in 1986 than today, and in turn it 
would mean something different in 2007.

It needs to be emphasize the latter is not a registered rule, but rather a 
shorthand for a registered rule, and which generally can not be relied 
upon (hence you should use a registered rule such as -0800 US/1987").

Excuse me if this sort of this has already been considered and rejected.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Mon, 08 Aug 2005 18:40:32 -0700
To: "Doug Royer" <[email-masked]>, "[email-masked]" <[email-masked]>
From: "Lisa Dusseault" <[email-masked]>
Organization: OSAF
Subject: [Ietf-calsify] Timezone registration

On Tue, 02 Aug 2005 16:14:09 -0700, Doug Royer <[email-masked]> wrote:

>
>
> Lisa Dusseault wrote:
>
>> I'm not sure what it means to say that IANA "wants to do" a registry.
>> It's my understanding that IANA implements registries (provided they're
>> technically able to) based on IETF recommendations resulting from IETF
>> review of proposals.  So it would seem more important whether the IETF
>> wants IANA to do a registry (and how) and the CALSIFY WG discussion
>> raised  a few important questions about that.
>
> I understand it to mean like Chris Newman described in the meeting.
> Register the names, leave the details to the vendors or services.

It may not be so easy for IANA to register timezones.  As was pointed out  
to us in the CALSIFY meeting, timezones are defined by political processes  
and that's not an easy thing for IETF or IANA to get a handle on.  Should  
the IANA accept a new timezone registration by the King of San Francisco  
on behalf of all of the San Francisco area?  How would IANA verify a  
timezone registration from Malheur county, Oregon?  If the government of  
Canada does not bother registering its timezones directly with IANA, then  
who is qualified to do so on its behalf?

I know little about how to solve these problems, but I notice that the  
LTRU draft  
(http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-10.txt)  
mentions special ISO advisory committees.

Lisa

Date: Mon, 08 Aug 2005 14:44:07 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Cc: Calsify <[email-masked]>, CalDAV DevList <[email-masked]>, [email-masked], "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] xCal - resubmitted.

This is a multi-part message in MIME format.
--------------040500060400060002010604
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

The xCal draft has been rewritten and submitted to the IETF.

I have an XSLT translation file that I will be releasing
soon on SourceForge that can translate an xCal object
back to an iCal object. I am waiting for SourceForge
to approve the project name.

Discussion takes place on [email-masked]

Copies of the draft at:

	http://INET-Consulting.com/draft-royer-calsch-xcal-01.txt
	http://INET-Consulting.com/draft-royer-calsch-xcal-01.html
	http://INET-Consulting.com/draft-royer-calsch-xcal-01.xml

JOIN the xCal mailing list at:

	http://inet-consulting.com/mailman/listinfo/xcal

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------040500060400060002010604
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------040500060400060002010604--

Date: Thu, 04 Aug 2005 09:30:29 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-calsify list <[email-masked]>
Subject: [Ietf-calsify] Errata on Calconnect Roundtable and Interop Announcement for September 2005
Reply-To: [email-masked]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
1.&nbsp; The registration fee for the Roundtable was mistakenly quoted as
$275 through 15 May 2005.&nbsp; The correct information is $275 through <u>31
August 2005</u>; the registration fee goes up to $325 on <u>1
September 2005</u>.<br>
<br>
2.&nbsp; Apparently there was some garbage HTML hidden before the beginning
of my announcement e-mail which was not visible when I composed it and
does not show in all e-mail clients.&nbsp; However, if it does show in your
client and you wish a revised version of the announcement please let me
know.&nbsp; I hesitate to send the whole thing out again to everybody.<br>
<br>
Dave Thewlis<br>
<br>
<div class="moz-signature">-- <br>
<b>Dave Thewlis, Executive Director<br>
Calconnect - The Calendaring and Scheduling Consortium</b><br>
+1 707 840 9391 (voice) &middot; +1 707 498 2238 (mobile)<br>
<a href="http://www.calconnect.org">http://www.calconnect.org</a> &middot; <a
 href="mailto:[email-masked]">[email-masked]</a>
</div>
</body>
</html>

Date: Thu, 04 Aug 2005 09:04:09 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-calsify list <[email-masked]>
Subject: [Ietf-calsify] Registration open for Calconnect Roundtable and Interop Testing Event,  September 2005 - The Calendaring and Scheduling Consortium
Reply-To: [email-masked]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<!-- Inserted by Calypso -->
<table id="_CalyPrintHeader_" style="display: none; color: black;"
 border="0" cellpadding="0" cellspacing="2" rules="none" width="100%">
  <tbody>
    <tr>
      <td colspan="3">
      <hr color="black" noshade="noshade" size="1"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
    <tr align="left" valign="top">
      <td nowrap="nowrap" width="1"><b>&nbsp;Date:</b><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td width="1"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td>&nbsp;12/2/2004 07:52<br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
    <tr align="left" valign="top">
      <td nowrap="nowrap" width="1"><b>&nbsp;From:</b><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td width="1"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td>&nbsp;David C. Thewlis<br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
    <tr align="left" valign="top">
      <td nowrap="nowrap" width="1"><b>&nbsp;To:</b><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td width="1"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td>&nbsp;"calconnect-l reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"ietf-caldav reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"IETF CALSCH" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"ietf-calsify reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"www-rdf-calendar reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
    <tr align="left" valign="top">
      <td nowrap="nowrap" width="1"><b>&nbsp;Copy:</b><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td width="1"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td>&nbsp;"Robert Tolmach - WellGood Group" <a
 class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"Brian Dear" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"John Carbone" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
      <a class="moz-txt-link-abbreviated"
 href="mailto:[email-masked]">[email-masked]</a>, <a
 class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
    <tr align="left" valign="top">
      <td nowrap="nowrap" width="1"><b>&nbsp;Subject:</b><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td width="1"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td>&nbsp;Call for Participantion -- Second Calconnect Interop - 11-12
January 2005 - Seattle, Washington<br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
    <tr>
      <td colspan="3">
      <hr color="black" noshade="noshade" size="1"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
  </tbody>
</table>
<!-- End Calypso --><!-- Inserted by Calypso -->
<table id="_CalyMsgHeader_" style="display: none; color: rgb(0, 0, 0);"
 bgcolor="#c0c0c0" border="1" cellpadding="2" cellspacing="2"
 rules="none" width="100%">
  <tbody>
    <tr bgcolor="#c0c0c0">
      <td><font color="#000000" face="VERDANA,ARIAL,HELVETICA" size="-2">Received:
from psmtp.com (exprod6mx6.postini.com [64.18.1.146]) by
home.humboldt1.com (8.12.10/8.12.10) with SMTP id iB2Fq3mR014814 for <a
 class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
Thu, 2 Dec 2004 07:52:03 -0800 (PST)<br>
Received: from source ([208.31.106.91]) by exprod6mx6.postini.com
([64.18.5.10]) with SMTP; Thu, 02 Dec 2004 07:52:02 PST<br>
Received: from aix2.egenconsulting.com (localhost [127.0.0.1]) by
aix2.egenconsulting.com (8.13.1/8.13.1) with ESMTP id iB2FlvWi018040
for <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
Thu, 2 Dec 2004
10:47:57 -0500<br>
Received: (from majordom@localhost) by aix2.egenconsulting.com
(8.13.1/8.13.1/Submit) id iB2FlvFI018426 for calconnect-l-list; Thu, 2
Dec 2004 10:47:57 -0500<br>
X-Authentication-Warning: aix2.egenconsulting.com: majordom set sender
to <a class="moz-txt-link-abbreviated"
 href="mailto:[email-masked]">[email-masked]</a>
using -f<br>
Received: from fed1rmmtao04.cox.net (fed1rmmtao04.cox.net
[68.230.241.35]) by aix2.egenconsulting.com (8.13.1/8.13.1) with ESMTP
id iB2FlcTM019480; Thu, 2 Dec 2004 10:47:38 -0500<br>
Received: from davet23 ([24.254.88.112]) by fed1rmmtao04.cox.net
(InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id
&lt;20041202154833.YTO5357.fed1rmmtao04.cox.net@davet23&gt; Thu, 2 Dec
2004 10:48:33 -0500<br>
Message-ID: <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a><br>
References: <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a><br>
X-Mailer: Calypso Version 3.30.00.00 (4)<br>
Date: Thu, 02 Dec 2004 07:48:00 -0800<br>
Reply-To: <a class="moz-txt-link-abbreviated"
 href="mailto:[email-masked]">[email-masked]</a><br>
From: "David C. Thewlis" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a><br>
To: "calconnect-l reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"ietf-caldav reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"IETF
CALSCH" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"ietf-calsify reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"www-rdf-calendar reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a><br>
Cc: "Robert Tolmach - WellGood Group" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"Brian Dear" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"John Carbone" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
      <a class="moz-txt-link-abbreviated"
 href="mailto:[email-masked]">[email-masked]</a>, <a
 class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a><br>
Subject: Call for Participantion -- Second Calconnect Interop - 11-12
January 2005 - Seattle, Washington<br>
Mime-Version: 1.0<br>
Content-Type: multipart/alternative; boundary="=====_11020024806334=_"<br>
Sender: <a class="moz-txt-link-abbreviated"
 href="mailto:[email-masked]">[email-masked]</a><br>
Precedence: bulk<br>
X-pstn-levels: (S:99.90000/99.90000 R:95.9108 P:95.9108 M:94.8624
C:98.9754 )<br>
X-pstn-settings: 5 (2.0000:2.0000) s gt3 gt2 gt1 r p m c <br>
X-pstn-addresses: from <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
forward
(user good) [2395/93] <br>
      </font><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
  </tbody>
</table>
<!-- End Calypso -->
<div><em>Please note that this announcement is being posted on multiple
calendaring-related reflectors and to the Calconnect mailing lists to
ensure as wide a distribution as possible.&nbsp; Our apologies if you
receive multiple copies.<br>
<br>
</em></div>
<div><em></em><br>
<strong>CALCONNECT ROUNDTABLE IV - 13-15 September 2005</strong> <br>
</div>
<div>&nbsp;</div>
<div><strong>CALCONNECT INTEROP TESTING EVENT -&nbsp;
13-14 September 2005<br>
<br>
</strong></div>
<div>&nbsp;<br>
CalConnect - The Calendaring and Scheduling Consortium - invites you to
our fourth Roundtable and to the associated Calendaring and Scheduling
Interop Testing Event on 13-15 September, 2005 in San Francisco, hosted
by OSAF, the Open Source Applications Foundation.&nbsp; <br>
<br>
<u>Registration is now open for these events as of 4 August 2005.</u><br>
</div>
<br>
<br>
The <b>Roundtable</b>, 13-15 September, will feature Technical
Committee meetings, ad hoc meetings, and a full Plenary of the
Consortium.&nbsp; You must represent a member of CalConnect to attend the
Roundtable <u>unless</u> your organization chooses to participate as
an Observer (a non-member who wishes to attend a Roundtable to evaluate
participation in the Consortium).<br>
<br>
The <b>Interop</b>, 13-14 September (at the same location), will offer
multiple Interop Testing Scenarios including <br>
<ul>
  <li>extensive CalDAV testing, <br>
  </li>
  <li>RFC (iCalendar, iMIP, iTIP) interoperability and RFC conformance
testing</li>
  <li>CALSIFY minimum interoperability testing.&nbsp; <br>
  </li>
</ul>
Participating organizations may choose one or more than one scenario
for testing -- however these scenarios will be going on
simultaneously so you will probably need a person for each scenario you
participate in.&nbsp; <br>
<br>
Interop participation is <u>open to all</u> interested organizations
that wish to test calendaring and scheduling implementations, and <u>is
not limited to members of the Consortium </u>(although members receive
a significant discount on the Interop participation fee). <br>
&nbsp;
<div><strong><br>
REGISTRATION FEES</strong></div>
<div>&nbsp;<br>
<b>Roundtable:</b>&nbsp; $275 per individual until 15
May and $325 thereafter.&nbsp; The Roundtable is limited to representatives
of Consortium members or declared Observers (an non-member that wishes
to attend a Roundtable to evaluate participation in the Consortium). &nbsp; <i>Registration
for the Roundtable does <b>not</b>
include Interop participation.</i><br>
&nbsp;</div>
<div><b>Interop:</b> $1500 for Consortium
members and $2500 for non-members.&nbsp; The registration fee covers two
individuals; additional individuals are $275 each for members or
non-members.&nbsp; (If you are planning to participate in more than one
Interop scenario, or participate in all the TC meetings, you <u>will</u>
need
more than one person and possibly more than two.)&nbsp; <strong></strong><i>The
Interop
Registration Fee <b>also covers participation in the&nbsp;Consortium
Roundtable</b>
for members or declared observers</i>.</div>
<div>&nbsp;<br>
<br>
</div>
<div><b>ADDITIONAL DETAILS AND REGISTRATION INFORMATION</b><br>
<br>
More information on the Roundtable, including logistics, current
schedule and agenda planning, and registration information is available
on the Consortium website at <a
 href="http://www.calconnect.org/roundtable4.html">http://www.calconnect.org/roundtable4.html</a>.&nbsp;
<br>
<br>
More information on the Interop including logistics, planning, and
registration information is available on the Consortium website at <a
 href="http://www.calconnect.org/iopsep2005.html">http://www.calconnect.org/iopsep2005.html</a>.<br>
<br>
You may also go to Consortium site at <a
 href="http://www.calconnect.org">http://www.calconnect.org</a>
and select "Coming Events" from the sidebar to find logistics,
planning and registration information for both the Roundtable and the
Interop.<br>
</div>
<br>
For questions and additional information please contact the
Consortium's Executive Director, Dave Thewlis, via the contact
information listed below. <br>
<div><br>
Space will be limited, so register as soon as possible. <br>
<br>
</div>
<div>Best Regards,</div>
<br>
Dave Thewlis<br>
<br>
<div class="moz-signature">-- <br>
<b>Dave Thewlis, Executive Director<br>
Calconnect - The Calendaring and Scheduling Consortium</b><br>
+1 707 840 9391 (voice) &middot; +1 707 498 2238 (mobile) &middot; +1 415 946 3454
(fax)<br>
<a href="http://www.calconnect.org">http://www.calconnect.org</a>
&middot; <a href="mailto:[email-masked]">[email-masked]</a><br>
<br>
</div>
</body>
</html>

Date: Tue, 02 Aug 2005 17:14:09 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Lisa Dusseault <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Ietf-calsify] Final(?) agenda for CALSIFY tomorrow
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean

This is a cryptographically signed message in MIME format.

--------------ms080704090909070309060506
Content-Type: multipart/mixed; boundary="------------070709050902080301020605"

This is a multi-part message in MIME format.
--------------070709050902080301020605
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Lisa Dusseault wrote:
> 
> Thanks for the clarifications Doug, and I can assure you there was no  
> intent to avoid communicating with you on your draft.

I have no problem with you or Ted.  I was just afraid that it was
going to get stalled or misunderstood forever.

>  I wanted to 
> discuss  timezone registries and services in CALSIFY independent of 
> Ted's  comments.  As the discussion in the WG meeting showed today, 
> although  CALSIFY's work may not block on timezone rationalization, 
> timezone work  certainly does affect CALSIFY work and the draft needed 
> to be pointed out  to CALSIFY participants.

I agree.

> I'm not sure what it means to say that IANA "wants to do" a registry.   
> It's my understanding that IANA implements registries (provided they're  
> technically able to) based on IETF recommendations resulting from IETF  
> review of proposals.  So it would seem more important whether the IETF  
> wants IANA to do a registry (and how) and the CALSIFY WG discussion 
> raised  a few important questions about that.

I understand it to mean like Chris Newman described in the meeting.
Register the names, leave the details to the vendors or services.

Even *IF* we were to remove recurrence rules from iCal, the clients
still need definitions so they could map to/from their UTC RDATE
properties when generating iCal objects or parsing received objects.

So I think a timezone server/service/whatever is still needed
to provide consistency across implementations.

In addition to to Pete Resnick's idea, I want to contact
some other government entities to peruse a server or
service.

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------070709050902080301020605
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------070709050902080301020605--

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

--------------ms080704090909070309060506--

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-calsify] Notes on the WG document sharing directory
Date: Wed, 3 Aug 2005 00:29:31 +0200
To: [email-masked]

On 2. Aug 2005, at 10:58 Uhr, Lisa Dusseault wrote:
>  - Use WebDAV to synchronize or view the directories with any  
> WebDAV client (such as sitecopy, MacOs WebDAVFS, XP redirector or  
> Windows "network places").

Not that its important, but it doesn't seem to work with OSX 10.4.2  
(times out).

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

To: "[email-masked]" <[email-masked]>
Date: Tue, 02 Aug 2005 16:54:39 +0200
From: "Lisa Dusseault" <[email-masked]>
Organization: OSAF
Subject: [Ietf-calsify] Meeting notes and chat log

Thanks Phillip and Bob for taking notes and scribing in the Jabber room

Meeting notes:
http://ietf.webdav.org/calsify/meetings/IETF63_meeting_notes.txt

Chat log:
http://www.xmpp.org/ietf-logs/[email-masked]/2005-08-02.html

Lisa

Date: Tue, 02 Aug 2005 10:58:46 +0200
To: "[email-masked]" <[email-masked]>
From: "Lisa Dusseault" <[email-masked]>
Organization: OSAF
Subject: [Ietf-calsify] Notes on the WG document sharing directory

I went ahead yesterday and set up a sharing directory on a WebDAV server  
for CALSIFY:

http://ietf.webdav.org/calsify

There are three main ways to get at the information on that share
  - Use HTTP and follow links in static documents
  - Use HTTP to access the WebUI with dynamic directory listings  
(http://ietf.webdav.org/xythoswfs/webui/calsify)
  - Use WebDAV to synchronize or view the directories with any WebDAV  
client (such as sitecopy, MacOs WebDAVFS, XP redirector or Windows  
"network places").

For CALSIFY contributors[1] I'm happy to create accounts that allow you to  
upload new documents or document changes.  We'll use this to make XML  
versions of WG documents available as well as HTML and text versions, and  
to post meeting presentation slides and meeting notes, and probably find  
more uses later too (e.g. issues lists).

The server itself is hosted by UCSC with software provided by Xythos and  
hardware provided by me, and it has gone down for a couple days a couple  
times in the last year or two but overall it's been quite stable.

thx,
Lisa

[1] And if you want to use this technology in another WG let me know.

Date: Tue, 02 Aug 2005 10:52:20 +0200
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Ietf-calsify] Final(?) agenda for CALSIFY tomorrow
From: "Lisa Dusseault" <[email-masked]>
Organization: OSAF

Thanks for the clarifications Doug, and I can assure you there was no  
intent to avoid communicating with you on your draft.  I wanted to discuss  
timezone registries and services in CALSIFY independent of Ted's  
comments.  As the discussion in the WG meeting showed today, although  
CALSIFY's work may not block on timezone rationalization, timezone work  
certainly does affect CALSIFY work and the draft needed to be pointed out  
to CALSIFY participants.

I'm not sure what it means to say that IANA "wants to do" a registry.   
It's my understanding that IANA implements registries (provided they're  
technically able to) based on IETF recommendations resulting from IETF  
review of proposals.  So it would seem more important whether the IETF  
wants IANA to do a registry (and how) and the CALSIFY WG discussion raised  
a few important questions about that.

Lisa

On Mon, 01 Aug 2005 18:57:04 +0200, Doug Royer <[email-masked]> wrote:

>
> There has been some misunderstanding here.
>
> 1) IANA does have the ability to register time zones and
>     they said they want that role.
>
> 2) They do NOT want to be a time zone 'server', just
>     a registration place.
>
> After emaling IANA and Ted I sent an email to CALSCH (where
> emails must go per 2445 for iCal registration processes) saying
> the next revision of the draft will remove all HTTP and FTP
> references making the draft an IANA registration process only.
> Something IANA says they want to do.
>
> And as soon as the ID submissions are allowed again (after meeting)
> I will submit a new additional 2nd draft: tz-server-00.
>
> And it would have been nice if Ted would have told me (the author
> of the independent draft) rather than talking to Lisa. In my last
> email to Ted I reminded him it was not a CALSIFY draft. Ted also
> talked to me in email about 'other ways' to do this, he was not
> specific. I want to move this draft forward. All communications
> need to be done with all knowledgeable persons.
>
> My 2nd 'SERVER' idea that is independent of the registration draft
> is to allow vendors to set up servers to allow any client that
> gets an iTIP message generated by their products to get
> the latest TZ information. So when you send an iTIP invitation
> to a user they will have the the ability to get the latest TZ
> information as used by that vendor, and not a snapshot of what
> was valid the time it was sent. As many in the U.S. know, our
> TZ info may be changing soon. All static VTIMEZONE
> entries sent with iCal object may be inaccurate soon for the US.
>
>>
>> 10 min: Timezone Registry Requirements -- new agenda item
>>    -
>> http://www.ietf.org/internet-drafts/draft-royer-timezone-registry-02.txt
>>    - Although this is not a WG chartered item, Ted Hardie (our Area
>> Director) and I discussed this
>> draft briefly, and we need to hear from implementors  whether it's a
>> requirement to have a TZ registry
>> and if so does it need to  be available in a format that's conducive to
>> clients automatically updating
>> their timezone descriptions.
>>    - I've also been told that IANA  doesn't have the ability to do a
>> registry with the features
>> specified in  this document.
>>

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Date: Mon, 1 Aug 2005 16:30:43 -0700
To: "[email-masked]" <[email-masked]>
From: John W Noerenberg II <[email-masked]>
Subject: Re: [Ietf-calsify] Final(?) agenda for CALSIFY tomorrow

At 3:14 PM -0700 8/1/05, John  W Noerenberg II wrote:
>At 12:40 PM +0200 8/1/05, Lisa Dusseault wrote:
>>CALSIFY is now scheduled for 9:00 am Tuesday.  That sucks for 
>>people in US  who want to join us for Jabbering,
>
>I don't know if I'll make it, but if I do, since I'm still ajabber 
>novice, where do I find you?

Nevermind.  I figured it out.

Date: Mon, 01 Aug 2005 16:57:56 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: "[email-masked]" <[email-masked]>
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Subject: [Ietf-calsify] Security and S/MIME draft-daboo-calsify-issues-00.txt

This is a cryptographically signed message in MIME format.

--------------ms050805000002010902080404
Content-Type: multipart/mixed; boundary="------------090006060107010909090301"

This is a multi-part message in MIME format.
--------------090006060107010909090301
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

It looks to me as if iMIP says to compare the fields as
described below and to use S/MIME.

Is the issue that almost no one uses S/MIME when
then send an iCal object?

> 6.2  Security
> 
>    Assuming that scheduling becomes more popular as more interoperable
>    products are deployed, the unpleasant possibility of 'calendar spam'
>    ('scam' ???) and malicious scheduling requests arises, as described
>    in [4].
> 
>    Currently [3] lacks appropriate text describing how security checks
>    for the various address elements should be done to verify the
>    authenticity of the message.  The possible sources of identity are
>    the email address headers, a certificate/key identity provided via a
>    multipart/signed email message and iCalendar ORGANISER/ATTENDEE/
>    SENDER values.

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------090006060107010909090301
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------090006060107010909090301--

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

--------------ms050805000002010902080404--

Date: Mon, 01 Aug 2005 16:47:14 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: "[email-masked]" <[email-masked]>
Subject: Re: [Ietf-calsify] UID issues hinted to in draft-daboo-calsify-issues-00.txt
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: "[email-masked]" <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms020205010900050302080509
Content-Type: multipart/mixed; boundary="------------070901040800060109000606"

This is a multi-part message in MIME format.
--------------070901040800060109000606
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Thanks!

I guess someone could put them in the UID value.
I never thought to test for those.

In other TEXT property values, this would only matter
if we had a SEARCH, correct?

Sam Roberts wrote:
> Quoting [email-masked], on Mon, Aug 01, 2005 at 02:57:47PM -0600:
> 
>>What EXACTLY are the issues?
>>
>>Over the years I have heard people say that charset conversions
>>might not be 1:1 in some charset.
>>
>>Does anyone 'KNOW' if this is true?
> 
> 
> See RFC3454 for examples, such as:
> 
>   The following characters are simply deleted from the input (that is,
>   they are mapped to nothing) because their presence or absence in
>   protocol identifiers should not make two strings different.
>   They are listed in Table B.1.
> 
>   Some characters are only useful in line-based text, and
>   are otherwise invisible and ignored.
> 
>   00AD; SOFT HYPHEN
>   1806; MONGOLIAN TODO SOFT HYPHEN
>   200B; ZERO WIDTH SPACE
>   2060; WORD JOINER
>   FEFF; ZERO WIDTH NO-BREAK SPACE
> 
> Section 9 discusses some security concerns.
> 
> Someone knowledgable would need to review iCal specs to see what implications
> this might have - they can be subtle.
> 
> Sam
> 
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------070901040800060109000606
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------070901040800060109000606--

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

--------------ms020205010900050302080509--

Date: Mon, 1 Aug 2005 18:32:21 -0400
From: Sam Roberts <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: [Ietf-calsify] UID issues hinted to in draft-daboo-calsify-issues-00.txt
Mail-Followup-To: "[email-masked]" <[email-masked]>

Quoting [email-masked], on Mon, Aug 01, 2005 at 02:57:47PM -0600:
> 
> What EXACTLY are the issues?
> 
> Over the years I have heard people say that charset conversions
> might not be 1:1 in some charset.
>
> Does anyone 'KNOW' if this is true?

See RFC3454 for examples, such as:

  The following characters are simply deleted from the input (that is,
  they are mapped to nothing) because their presence or absence in
  protocol identifiers should not make two strings different.
  They are listed in Table B.1.

  Some characters are only useful in line-based text, and
  are otherwise invisible and ignored.

  00AD; SOFT HYPHEN
  1806; MONGOLIAN TODO SOFT HYPHEN
  200B; ZERO WIDTH SPACE
  2060; WORD JOINER
  FEFF; ZERO WIDTH NO-BREAK SPACE

Section 9 discusses some security concerns.

Someone knowledgable would need to review iCal specs to see what implications
this might have - they can be subtle.

Sam

Date: Mon, 1 Aug 2005 15:14:29 -0700
To: "Lisa Dusseault" <[email-masked]>
From: John W Noerenberg II <[email-masked]>
Subject: Re: [Ietf-calsify] Final(?) agenda for CALSIFY tomorrow
Cc: "[email-masked]" <[email-masked]>

At 12:40 PM +0200 8/1/05, Lisa Dusseault wrote:
>CALSIFY is now scheduled for 9:00 am Tuesday.  That sucks for people 
>in US  who want to join us for Jabbering,

I don't know if I'll make it, but if I do, since I'm still ajabber 
novice, where do I find you?
-- 

john noerenberg
   ----------------------------------------------------------------------
   Statt des törichten Ignorabimus heiße im Gegenteil unsere Lösung:
   Wir müssen wissen, Wir werden wissen.
   -- David Hilbert, "Logic and the Understanding of Nature, Sep 1930
   ----------------------------------------------------------------------

Date: Mon, 01 Aug 2005 14:57:47 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: "[email-masked]" <[email-masked]>
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Subject: [Ietf-calsify] UID issues hinted to in draft-daboo-calsify-issues-00.txt
Reply-To: "[email-masked]" <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms070503030302010007070309
Content-Type: multipart/mixed; boundary="------------070709020307020304000509"

This is a multi-part message in MIME format.
--------------070709020307020304000509
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

What EXACTLY are the issues?

Over the years I have heard people say that charset conversions
might not be 1:1 in some charset.

Does anyone 'KNOW' if this is true?
And if true, what exactly are the issues?

> From http://www.ietf.org/internet-drafts/draft-daboo-calsify-issues-00.txt 

> 6.1  Internationalization
> 
>    The iCalendar data format recommends use of UTF8 for all textual
>    data, but goes no further than that in terms of internationalization
>    issues.  However, some textual values in the iCalendar data are used
>    for comparisons which may take place in different clients or servers.
> 
>    For example, iCalendar processors are likely to attempt matches of
>    the UID of a component arriving via iTIP with any existing components
>    in a store.  The iCalendar specs do not explicitly point out the
>    issues with this with respect to different unicode normalisations
>    that may occur.  Whilst it is probably not necessary to define a
>    stringprep [11] profile for iCalendar, there should at least be an
>    'Internationalization Considerations' section that makes it clear
>    that clients may need to 'normalise' certain text values that can be
>    used in comparisons.

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------070709020307020304000509
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------070709020307020304000509--

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

--------------ms070503030302010007070309--

Date: Mon, 01 Aug 2005 10:57:04 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Lisa Dusseault <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Ietf-calsify] Final(?) agenda for CALSIFY tomorrow
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: "[email-masked]" <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms060704050705050509030801
Content-Type: multipart/mixed; boundary="------------020103080305060409000604"

This is a multi-part message in MIME format.
--------------020103080305060409000604
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

There has been some misunderstanding here.

1) IANA does have the ability to register time zones and
    they said they want that role.

2) They do NOT want to be a time zone 'server', just
    a registration place.

After emaling IANA and Ted I sent an email to CALSCH (where
emails must go per 2445 for iCal registration processes) saying
the next revision of the draft will remove all HTTP and FTP
references making the draft an IANA registration process only.
Something IANA says they want to do.

And as soon as the ID submissions are allowed again (after meeting)
I will submit a new additional 2nd draft: tz-server-00.

And it would have been nice if Ted would have told me (the author
of the independent draft) rather than talking to Lisa. In my last
email to Ted I reminded him it was not a CALSIFY draft. Ted also
talked to me in email about 'other ways' to do this, he was not
specific. I want to move this draft forward. All communications
need to be done with all knowledgeable persons.

My 2nd 'SERVER' idea that is independent of the registration draft
is to allow vendors to set up servers to allow any client that
gets an iTIP message generated by their products to get
the latest TZ information. So when you send an iTIP invitation
to a user they will have the the ability to get the latest TZ
information as used by that vendor, and not a snapshot of what
was valid the time it was sent. As many in the U.S. know, our
TZ info may be changing soon. All static VTIMEZONE
entries sent with iCal object may be inaccurate soon for the US.

> 
> 10 min: Timezone Registry Requirements -- new agenda item
>    -  
> http://www.ietf.org/internet-drafts/draft-royer-timezone-registry-02.txt
>    - Although this is not a WG chartered item, Ted Hardie (our Area  
> Director) and I discussed this
> draft briefly, and we need to hear from implementors  whether it's a  
> requirement to have a TZ registry
> and if so does it need to  be available in a format that's conducive to  
> clients automatically updating
> their timezone descriptions.
>    - I've also been told that IANA  doesn't have the ability to do a  
> registry with the features
> specified in  this document.
> 
-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------020103080305060409000604
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------020103080305060409000604--

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

--------------ms060704050705050509030801--

To: "[email-masked]" <[email-masked]>
Date: Mon, 01 Aug 2005 12:40:44 +0200
From: "Lisa Dusseault" <[email-masked]>
Organization: OSAF
Subject: [Ietf-calsify] Final(?) agenda for CALSIFY tomorrow

CALSIFY is now scheduled for 9:00 am Tuesday.  That sucks for people in  
US  who want to join us for
Jabbering, so if you don't manage to  join us online then we'll try to  
make sure the notes are good and
promptly  available (early scribe volunteers welcome).  We will have to  
run through the agenda rather
aggressively anyway, because  there have been new agenda items added and  
we're also down to 1 hr
meeting  time.  Read the drafts ahead of time.

There aren't any WG drafts officially because CALSIFY was approved as a WG  
after the draft submission
cutoff date so I encouraged Chris Stoner and  Cyrus Daboo to submit their  
drafts as individual
submissions even though these are planned as WG documents and the next  
versions will look like draft-
ietf-calsify-<foo>-00. Read these anyway.

--- Revised agenda ---

5 minutes: WG Overview
    - Very quick agenda bash
    - Quick reminder of chartered items
    - Overview of WG roles and responsibilities
    - Notice of planned US timezone changes (Daylight savings time)

30 min: Interop Problems
    - Minimal interoperability work already done: Jeff McCullough
    - Known problems  
(http://www.ietf.org/internet-drafts/draft-daboo-calsify-issues-00.txt and  
Chris
Stoner's list)
    - Proposals to address problems?

10 min: Document plans
    - Organization and editing of RFC2445bis  
(http://www.ietf.org/internet-drafts/draft-cstoner-
rfc2445bis-00.txt), Chris Stoner
    - plans for iMIP document, Alexey Melnikov

10 min: Timezone Registry Requirements -- new agenda item
    -  
http://www.ietf.org/internet-drafts/draft-royer-timezone-registry-02.txt
    - Although this is not a WG chartered item, Ted Hardie (our Area  
Director) and I discussed this
draft briefly, and we need to hear from implementors  whether it's a  
requirement to have a TZ registry
and if so does it need to  be available in a format that's conducive to  
clients automatically updating
their timezone descriptions.
    - I've also been told that IANA  doesn't have the ability to do a  
registry with the features
specified in  this document.

5 min: Comments, forgotten items

--- Non Agenda Items ---

CalDAV status:  Cyrus asked for CalDAV status to be discussed on the  
Agenda but I'm afraid we don't
have much time in this meeting for announcements.  Please announce CalDAV  
status on the CALSIFY mailing
list and people who are here in Paris are welcome to come talk to me (et  
naturellement Bernard
Desruisseaux aussi)

SIP and calendaring related work:
    -  
http://www.ietf.org/internet-drafts/draft-niemi-sipping-cal-events-00.txt
    - Not currently a WG draft in either CALSIFY or SIPPING but Aki plans  
to pursue anyway.  Discussion
on CALSIFY list is welcome.

Lisa