Subject: [Ietf-calsify] AD Review of RFC2446bis

From: Lisa Dusseault <[email-masked]>
Date: Tue, 26 Aug 2008 09:15:46 -0700

Here's my review of version -07.  I have no high-level problems except  
a suggestion for formatting the constraints tables throughout the  
document if Cyrus is willing.

----

Section 1.4
Says that ADD can be used to add one or more new instances to an  
existing VEVENT, VTODO or VJOURNAL.  However, I'm not entirely clear  
how an iTIP recipient would get the VTODO or VJOURNAL in the first  
place.  PUBLISH includes any type of calendar entry -- what does  
"calendar entry" define and include (It's mentioned only once that I  
can find in 2445bis)?  Any iCalendar component?

Section 3
First table says that PUBLISH can be used for VEVENT, VTODO, VJOURNAL  
and VFREEBUSY, but that REQUEST can be used for all except VJOURNAL.   
This doesn't appear consistent with the text in Section 1.4 which  
implies that REQUEST can schedule any calendar entry.  Maybe we're  
back to the missing definition of "calendar entry".

Section 3.2
Main table says that the PUBLISH method constraints include 0 VTODO or  
VJOURNAL components.  In section 3.2.2,  REQUEST also has 0 , and in  
section 3.2.4, ADD has 0 VTODOs or VJOURNALs.  Isn't this in  
contradiction to section 1.4's description of ADD?  Doesn't this mean  
you can't send a VTODO or VJOURNAL out in iTIP at all?  ... It turns  
out I need to interpret the tables of constraints in a narrower  
context.  I suggest that the context be part of the title or first row  
of the table.

Section 3.2.2.6
The event flow seems incomplete.  It describes how a request can be  
forwarded to a new CU that wasn't invited, and then the organizer  
decides whether or not to add the uninvited CU to the attendee list.   
We're missing the step in between where the organizer learns that the  
new CU was invited. Is this by receiving a response from the uninvited  
CU, being cc'ed on the forwarded REQUEST, or receiving a separate copy  
of the REQUEST or a COUNTER, or any of the above?

Same section: phrases like "a new ATTENDEE property is added" are in  
passive voice, aren't very clear about who is responsible.  In this  
case it should be something like
	If the "Organizer" decides to add an uninvited CU, the CU
	of the "Organizer" adds a new "ATTENDEE" property with
	the uninvited CU with its property parameters set as the
	"Organizer" deems appropriate.
Section 3.2.3:
    The "REPLY" method may also be used to respond to an unsuccessful
    "REQUEST" method.

Is there something missing here?  I read "unsuccessful" as a request  
that was not received.  Hard to know how to reply to a request that  
was not received.

Section 3.3
   "FREEBUSY" properties should be sorted such that their values are in
    ascending order, based on the start time, and then the end time,  
with
    the earliest periods first.

Is there a reason why the SHOULD isn't capitalized?  Is there a reason  
why it's not a MUST?

    The busy time information within the iCalendar object MAY be grouped
    into more than one "VFREEBUSY" calendar component.

This requirement does not seem consistent with the tables in 3.3.2 or  
3.3.3, where the "Presence" column says that only one VFREEBUSY  
component is allowed.  If it's only true for PUBLISH, then this  
statement quoted above should be moved into the section on PUBLISH  
(3.3.1) or even called out.

Section 3.4.2:
    The originator of a "REQUEST" is the "Organizer" of the to-do.  The
    recipient of a "REQUEST" is the "Calendar User" assigned the to-do.

The REQUEST method is also used by the delegator as explained in  
3.4.2.3.  Maybe we should just add a prefix:  "In the most typical  
case, the originator of a REQUEST is..."

Next question in this same text:  How do user agents check that they  
are in fact the Calendar User assigned the to-do, and not just being  
cc'ed?

Section 3.4.4

	If an "Attendee" implementation does not support the "ADD"
    method it should respond with a "REQUEST-STATUS" value of 5.3 and  
ask
    for a "REFRESH".

Shouldn't this be 3.14 error instead of 5.3?  Section 3.2.4 for ADD  
uses a REQUEST-STATUS of 3.14 for the same case.

Section 3.4.6

I'm going to suggest a rewrite of these paragraphs -- sent separate  
mail.

Section 3.6, table, row for code 5.0 says:

	"Request MAY supported"

Something must be missing here?

Section 3.7.3:
	Clients are not required to save X-Tokens or use them
    in replies.

It seems curious to have this anti-requirement, where there is no  
requirement of this sort for ordinary properties.  I couldn't find any  
requirement that standard properties in iCalendar methods must be  
saved or used in replies.

Section 4.2.4: The example in this section claims that the COUNTER  
requests a change to time and place of the meeting.  However, it looks  
like the LOCATION field has "Green Conference Room" in both the  
original REQUEST and in the COUNTER.

Section 4.2.5 says:

   It is not required that the "Delegate" include the "Delegator" in
    their "REPLY" method.  However, it is strongly advised since this
    will inform the "Delegator" whether the "Delegate" plans to attend
    the meeting.

However, Section 4.2.7 says:

    In this example the "Delegate" declines the meeting request and sets
    the "ATTENDEE" property "PARTSTAT" parameter to "DECLINED".  The
    "Organizer" SHOULD resend the "REQUEST" to "C" with the "PARTSTAT"
    parameter of the "Delegate" set to "DECLINED".  This lets the
    "Delegator" know that the "Delegate" has declined and provides an
    opportunity to the "Delegator" to either accept the request or
    delegate it to another CU.

These are inconsistent because section 4.2.5 indicates that the  
Delegate is responsible for letting the "Delegator" know if they've  
accepted.  Section 4.2.7, however, does not say that the Delegate does  
so (it is silent) but it does say that the "Organizer" sends an  
update  that lets the "Delegator" know if the delegate accepted.   Is  
it the Delegate, the Organizer or both that are responsible for  
letting the Delegator know the accept status?

Section 4.5.5:

    A reply indicating that "D" completed "D's" part of the assignment.

Section 4.5.6 continues the example, however:

      ATTENDEE;PARTSTAT=IN- 
PROCESS;CUTYPE=INDIVIDUAL:mailto:[email-masked]

Shouldn't "D"'s PARTSTAT be COMPLETED rather than "IN-PROCESS"?

Section 5.1.1:

    +---------------- 
+--------------------------------------------------+
    | Method         |  
Fallback                                         |
    +---------------- 
+--------------------------------------------------+
    | PUBLISH        |  
Required                                         |
    | REQUEST        |  
PUBLISH                                          |
    | REPLY          |  
Required                                         |
    | ADD            |  
Required                                         |
    | CANCEL         |  
Required                                         |
    | REFRESH        |  
Required                                         |
    | COUNTER        | Reply with Not  
Supported                         |
    | DECLINECOUNTER | Required if EVENT-COUNTER is  
implemented;        |
    |                | otherwise reply with Not  
Supported               |
    +---------------- 
+--------------------------------------------------+

In this table, the "Fallback" context is inconsistent.  Saying that  
the fallback if you don't support REQUEST is to send a PUBLISH is an  
instruction to the sender.  However, saying that the fallback if you  
don't support COUNTER is to reply with Not Supported, is an  
instruction to the receiver.

Isn't there a difference between "Required to be able to send" and  
"Required to be able to handle on receiving"?   Thus, all iTIP clients  
MUST be able to receive PUBLISH requests but obviously aren't required  
to send them.   COUNTER is not required to be sent or received.  REPLY  
is required to be both sent and handled on receiving.

Section 7.  IANA Considerations

I do not see any existing IANA registry for the iCalendar "METHOD"  
property values.  If there is a registry, please provide the URL to  
help IANA.  They will also need to be instructed to update the  
reference for these methods from 2446 to 2446bis.

if, on the other hand there is no such registry and we are trying to  
create one, then IANA needs more clear instructions on creating the  
new registry and what fields it has and how entries are added (IETF  
consensus, expert assignment, First-come-first-served)

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

---

From: Eliot Lear <[email-masked]>
Date: Wed, 27 Aug 2008 14:33:10 +0200

Lisa,

Thanks very much for your review.  Would the WG like to comment?

Eliot

Lisa Dusseault wrote:
>    ascending order, based on the start time, and then the end time, with
>    method it should respond with a "REQUEST-STATUS" value of 5.3 and ask
>    for a "REFRESH".
>
> I'm going to suggest a rewrite of these paragraphs -- sent separate mail.
>
> requests a change to time and *place* of the meeting.  However, it 
> looks like the LOCATION field has "Green Conference Room" in both the 
> so (it is silent) but it does say that the "Organizer" sends an update 
>  that lets the "Delegator" know if the delegate accepted.   Is it the 
> Delegate, the Organizer or both that are responsible for letting the 
> Delegator know the accept status?
>
>
> Section 4.5.5:
>
>      ATTENDEE;PARTSTAT=IN-PROCESS;CUTYPE=INDIVIDUAL:mailto:[email-masked]
>
>    +----------------+--------------------------------------------------+
>    | Method         | Fallback                                         |
>    +----------------+--------------------------------------------------+
>    | PUBLISH        | Required                                         |
>    | REQUEST        | PUBLISH                                          |
>    | REPLY          | Required                                         |
>    | ADD            | Required                                         |
>    | CANCEL         | Required                                         |
>    | REFRESH        | Required                                         |
>    | COUNTER        | Reply with Not Supported                         |
>    | DECLINECOUNTER | Required if EVENT-COUNTER is implemented;        |
>    |                | otherwise reply with Not Supported               |
>    +----------------+--------------------------------------------------+
>
> ------------------------------------------------------------------------
>

Date: Wed, 27 Aug 2008 14:33:10 +0200
From: Eliot Lear <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-calsify] AD Review of RFC2446bis
Cc: ietf-calsify list <[email-masked]>

Lisa,

Thanks very much for your review.  Would the WG like to comment?

Eliot

Lisa Dusseault wrote:
>    ascending order, based on the start time, and then the end time, with
>    method it should respond with a "REQUEST-STATUS" value of 5.3 and ask
>    for a "REFRESH".
>
> I'm going to suggest a rewrite of these paragraphs -- sent separate mail.
>
> requests a change to time and *place* of the meeting.  However, it 
> looks like the LOCATION field has "Green Conference Room" in both the 
> so (it is silent) but it does say that the "Organizer" sends an update 
>  that lets the "Delegator" know if the delegate accepted.   Is it the 
> Delegate, the Organizer or both that are responsible for letting the 
> Delegator know the accept status?
>
>
> Section 4.5.5:
>
>      ATTENDEE;PARTSTAT=IN-PROCESS;CUTYPE=INDIVIDUAL:mailto:[email-masked]
>
>    +----------------+--------------------------------------------------+
>    | Method         | Fallback                                         |
>    +----------------+--------------------------------------------------+
>    | PUBLISH        | Required                                         |
>    | REQUEST        | PUBLISH                                          |
>    | REPLY          | Required                                         |
>    | ADD            | Required                                         |
>    | CANCEL         | Required                                         |
>    | REFRESH        | Required                                         |
>    | COUNTER        | Reply with Not Supported                         |
>    | DECLINECOUNTER | Required if EVENT-COUNTER is implemented;        |
>    |                | otherwise reply with Not Supported               |
>    +----------------+--------------------------------------------------+
>
> ------------------------------------------------------------------------
>

From: Lisa Dusseault <[email-masked]>
To: ietf-calsify list <[email-masked]>
Date: Tue, 26 Aug 2008 09:15:46 -0700
Subject: [Ietf-calsify] AD Review of RFC2446bis

--Apple-Mail-1-941977697
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

----

Section 1.4

Section 3

Section 3.2

Section 3.2.2.6

Section 3.3

Section 3.4.2:

Section 3.4.4

Section 3.4.6

	"Request MAY supported"

Section 3.7.3:

Section 4.2.5 says:

Section 4.5.5:

      ATTENDEE;PARTSTAT=IN- 

Section 5.1.1:

    +---------------- 

--Apple-Mail-1-941977697
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><div>Here's my review of =
version -07. &nbsp;I have no high-level problems except a suggestion for =
formatting the constraints tables throughout the document if Cyrus is =
willing.</div><div><br></div><div>----</div><div><br>Section =
1.4</div><div>Says that ADD can be used to add one or more new instances =
to an existing VEVENT, VTODO or VJOURNAL. &nbsp;However, I'm not =
entirely clear how an iTIP recipient would get the VTODO or VJOURNAL in =
the first place. &nbsp;PUBLISH includes any type of calendar entry -- =
what does "calendar entry" define and include (It's mentioned only once =
that I can find in 2445bis)? &nbsp;Any iCalendar =
component?<br><br>Section 3</div><div>First table says that PUBLISH can =
be used for VEVENT, VTODO, VJOURNAL and VFREEBUSY, but that REQUEST can =
be used for all except VJOURNAL. &nbsp;This doesn't appear consistent =
with the text in Section 1.4 which implies that REQUEST can schedule any =
calendar entry. &nbsp;Maybe we're back to the missing definition of =
"calendar entry".<br><br>Section 3.2</div><div>Main table says that the =
PUBLISH method constraints include 0 VTODO or VJOURNAL components. =
&nbsp;In section 3.2.2, &nbsp;REQUEST also has 0 , and in section 3.2.4, =
ADD has 0 VTODOs or VJOURNALs. &nbsp;Isn't this in contradiction to =
section 1.4's description of ADD? &nbsp;Doesn't this mean you can't send =
a VTODO or VJOURNAL out in iTIP at all? &nbsp;... It turns out I need to =
interpret the tables of constraints in a narrower context. &nbsp;I =
suggest that the context be part of the title or first row of the table. =
&nbsp;</div><div><br>Section 3.2.2.6&nbsp;</div><div>The event flow =
seems incomplete. &nbsp;It describes how a request can be forwarded to a =
new CU that wasn't invited, and then the organizer decides whether or =
not to add the uninvited CU to the attendee list. &nbsp;We're missing =
the step in between where the organizer learns that the new CU was =
invited. Is this by receiving a response from the uninvited CU, being =
cc'ed on the forwarded REQUEST, or receiving a separate copy of the =
REQUEST or a COUNTER, or any of the above?<br><br>Same section: phrases =
like "a new ATTENDEE property is added" are in passive voice, aren't =
very clear about who is responsible. &nbsp;In this case it should be =
something like<br><span class=3D"Apple-tab-span" style=3D"white-space: =
pre; ">	</span>If the "Organizer" decides to add an uninvited CU, the =
CU<br><span class=3D"Apple-tab-span" style=3D"white-space: pre; ">	=
</span>of the "Organizer" adds a new "ATTENDEE" property with<br><span =
class=3D"Apple-tab-span" style=3D"white-space: pre; ">	</span>the =
uninvited CU with its property parameters set as the<br><span =
class=3D"Apple-tab-span" style=3D"white-space: pre; ">	=
</span>"Organizer" deems appropriate.</div><div><div>Section =
3.2.3:</div><div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; ">&nbsp;&nbsp;&nbsp;The "REPLY" method may also =
be used to respond to an unsuccessful</div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: =
normal normal normal 12px/normal Helvetica; ">&nbsp;&nbsp; "REQUEST" =
method. &nbsp;</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Helvetica; ">Is there something missing here? =
&nbsp;I read "unsuccessful" as a request that was not received. =
&nbsp;Hard to know how to reply to a request that was not received. =
&nbsp;</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Helvetica; ">Section 3.3</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
"><div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
">&nbsp;&nbsp;"FREEBUSY" properties should be sorted such that their =
values are in</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; ">&nbsp;&nbsp; ascending order, based on the =
start time, and then the end time, with</div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: =
normal normal normal 12px/normal Helvetica; ">&nbsp;&nbsp; the earliest =
periods first. &nbsp;</div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Helvetica; ">Is there a reason why the SHOULD =
isn't capitalized? &nbsp;Is there a reason why it's not a =
MUST?&nbsp;</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Helvetica; "><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Helvetica; ">&nbsp;&nbsp;&nbsp;The busy time =
information within the iCalendar object MAY be grouped</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
">&nbsp;&nbsp; into more than one "VFREEBUSY" calendar component. =
&nbsp;</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Helvetica; ">This requirement does not seem =
consistent with the tables in 3.3.2 or 3.3.3, where the "Presence" =
column says that only one VFREEBUSY component is allowed. &nbsp;If it's =
only true for PUBLISH, then this statement quoted above should be moved =
into the section on PUBLISH (3.3.1) or even called out.</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
"><br></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; ">Section 3.4.2:</div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: =
normal normal normal 12px/normal Helvetica; "><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: =
normal normal normal 12px/normal Helvetica; ">&nbsp;&nbsp;&nbsp;The =
originator of a "REQUEST" is the "Organizer" of the to-do.&nbsp; =
The</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; ">&nbsp;&nbsp; recipient of a "REQUEST" is the =
"Calendar User" assigned the to-do.</div><div><br></div><div>The REQUEST =
method is also used by the delegator as explained in 3.4.2.3. =
&nbsp;Maybe we should just add a prefix: &nbsp;"In the most typical =
case, the originator of a REQUEST =
is..."&nbsp;</div><div><br></div><div>Next question in this same text: =
&nbsp;How do user agents check that they are in fact the Calendar User =
assigned the to-do, and not just being cc'ed? =
&nbsp;</div><div><br></div><div>Section =
3.4.4</div><div><br></div><div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Helvetica; "><span class=3D"Apple-tab-span" =
style=3D"white-space: pre; ">	</span>If an "Attendee" implementation =
does not support the "ADD"</div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Helvetica; ">&nbsp;&nbsp; method it should =
respond with a "REQUEST-STATUS" value of 5.3 and ask</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
">&nbsp;&nbsp; for a "REFRESH".</div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Helvetica; "><br></div><div style=3D"margin-top:=
 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: =
normal normal normal 12px/normal Helvetica; ">Shouldn't this be 3.14 =
error instead of 5.3? &nbsp;Section 3.2.4 for ADD uses a REQUEST-STATUS =
of 3.14 for the same case.</div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Helvetica; "><br></div><div style=3D"margin-top:=
 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: =
normal normal normal 12px/normal Helvetica; ">Section =
3.4.6&nbsp;</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Helvetica; ">I'm going to suggest a rewrite of =
these paragraphs -- sent separate mail.</div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: =
normal normal normal 12px/normal Helvetica; "><br></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
">Section 3.6, table, row for code 5.0 says:</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
"><br></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; "><span class=3D"Apple-tab-span" =
style=3D"white-space: pre; ">	</span>"Request MAY =
supported"<br></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Helvetica; ">Something must be missing =
here?</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Helvetica; ">Section 3.7.3:</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
"><div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
"><span class=3D"Apple-tab-span" style=3D"white-space: pre; ">	=
</span>Clients are not required to save X-Tokens or use them</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
">&nbsp;&nbsp; in replies.</div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Helvetica; "><br></div><div style=3D"margin-top:=
 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: =
normal normal normal 12px/normal Helvetica; ">It seems curious to have =
this anti-requirement, where there is no requirement of this sort for =
ordinary properties. &nbsp;I couldn't find any requirement that standard =
properties in iCalendar methods must be saved or used in replies. =
&nbsp;</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Helvetica; ">Section 4.2.4: The example in =
this section claims that the COUNTER requests a change to time =
and&nbsp;<b>place</b>&nbsp;of the meeting. &nbsp;However, it looks like =
the LOCATION field has "Green Conference Room" in both the original =
REQUEST and in the COUNTER.</div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Helvetica; "><br></div><div style=3D"margin-top:=
 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: =
normal normal normal 12px/normal Helvetica; "><br></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
">Section 4.2.5 says:</div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Helvetica; "><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Helvetica; ">&nbsp;&nbsp;It is not required =
that the "Delegate" include the "Delegator" in</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
">&nbsp;&nbsp; their "REPLY" method.&nbsp; However, it is strongly =
advised since this</div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; ">&nbsp;&nbsp; will inform the "Delegator" =
whether the "Delegate" plans to attend</div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: =
normal normal normal 12px/normal Helvetica; ">&nbsp;&nbsp; the meeting. =
&nbsp;</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Helvetica; ">However, Section 4.2.7 =
says:</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Helvetica; "><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Helvetica; ">&nbsp;&nbsp;&nbsp;In this example =
the "Delegate" declines the meeting request and sets</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
">&nbsp;&nbsp; the "ATTENDEE" property "PARTSTAT" parameter to =
"DECLINED".&nbsp; The</div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; ">&nbsp;&nbsp; "Organizer" SHOULD resend the =
"REQUEST" to "C" with the "PARTSTAT"</div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Helvetica; ">&nbsp;&nbsp; parameter of the =
"Delegate" set to "DECLINED".&nbsp; This lets the</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
">&nbsp;&nbsp; "Delegator" know that the "Delegate" has declined and =
provides an</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; ">&nbsp;&nbsp; opportunity to the "Delegator" to =
either accept the request or</div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Helvetica; ">&nbsp;&nbsp; delegate it to =
another CU.</div><div><br></div><div><br></div><div>These are =
inconsistent because section 4.2.5 indicates that the Delegate is =
responsible for letting the "Delegator" know if they've accepted. =
&nbsp;Section 4.2.7, however, does not say that the Delegate does so (it =
is silent) but it does say that the "Organizer" sends an update =
&nbsp;that lets the "Delegator" know if the delegate accepted. &nbsp; Is =
it the Delegate, the Organizer or both that are responsible for letting =
the Delegator know the accept =
status?</div><div><br></div><div><br></div><div>Section =
4.5.5:</div><div><br></div><div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Helvetica; ">&nbsp;&nbsp;&nbsp;A reply =
indicating that "D" completed "D's" part of the assignment.</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
"><br></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; ">Section 4.5.6 continues the example, =
however:</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Helvetica; "><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Helvetica; ">&nbsp;&nbsp; =
&nbsp;&nbsp;ATTENDEE;PARTSTAT=3DIN-PROCESS;CUTYPE=3DINDIVIDUAL:<a =
href=3D"mailto:[email-masked]">mailto:[email-masked]</a></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
"><br></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; ">Shouldn't "D"'s PARTSTAT be COMPLETED rather =
than "IN-PROCESS"?</div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Helvetica; "><br></div><div style=3D"margin-top:=
 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: =
normal normal normal 12px/normal Helvetica; ">Section 5.1.1:</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
"><br></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; "><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; =
">&nbsp;&nbsp;&nbsp;+----------------+------------------------------------=
--------------+</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; ">&nbsp;&nbsp; | Method &nbsp; &nbsp; &nbsp; =
&nbsp; | Fallback &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; |</div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; ">&nbsp;&nbsp; =
+----------------+--------------------------------------------------+</div=
><div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
">&nbsp;&nbsp; | PUBLISH&nbsp; &nbsp; &nbsp; &nbsp; | Required &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
|</div><div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: =
0px; margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
">&nbsp;&nbsp; | REQUEST&nbsp; &nbsp; &nbsp; &nbsp; | PUBLISH&nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
|</div><div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: =
0px; margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
">&nbsp;&nbsp; | REPLY&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | Required =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
|</div><div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: =
0px; margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
">&nbsp;&nbsp; | ADD&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | Required =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
|</div><div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: =
0px; margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
">&nbsp;&nbsp; | CANCEL &nbsp; &nbsp; &nbsp; &nbsp; | Required &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
|</div><div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: =
0px; margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
">&nbsp;&nbsp; | REFRESH&nbsp; &nbsp; &nbsp; &nbsp; | Required &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
|</div><div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: =
0px; margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
">&nbsp;&nbsp; | COUNTER&nbsp; &nbsp; &nbsp; &nbsp; | Reply with Not =
Supported &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; |</div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; ">&nbsp;&nbsp; | DECLINECOUNTER | Required if =
EVENT-COUNTER is implemented;&nbsp; &nbsp; &nbsp; &nbsp; |</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
">&nbsp;&nbsp; |&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
| otherwise reply with Not Supported &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; |</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; ">&nbsp;&nbsp; =
+----------------+--------------------------------------------------+</div=
><div><br></div><div>In this table, the "Fallback" context is =
inconsistent. &nbsp;Saying that the fallback if you don't support =
REQUEST is to send a PUBLISH is an instruction to the sender. =
&nbsp;However, saying that the fallback if you don't support COUNTER is =
to reply with Not Supported, is an instruction to the =
receiver.</div><div><br></div><div>Isn't there a difference between =
"Required to be able to send" and "Required to be able to handle on =
receiving"? &nbsp; Thus, all iTIP clients MUST be able to receive =
PUBLISH requests but obviously aren't required to send them. &nbsp; =
COUNTER is not required to be sent or received. &nbsp;REPLY is required =
to be both sent and handled on =
receiving.&nbsp;</div><div><br></div><div><br></div><div>Section 7. =
&nbsp;IANA Considerations</div><div><br></div><div>I do not see any =
existing IANA registry for the iCalendar "METHOD" property values. =
&nbsp;If there is a registry, please provide the URL to help IANA. =
&nbsp;They will also need to be instructed to update the reference for =
these methods from 2446 to 2446bis.</div><div><br></div><div>if, on the =
other hand there is no such registry and we are trying to create one, =
then IANA needs more clear instructions on creating the new registry and =
what fields it has and how entries are added (IETF consensus, expert =
assignment, =
First-come-first-served)</div><div><br></div><div><br></div></div></div></=
div></div></div></div></div></div></div></div></div></div></body></html>=

--Apple-Mail-1-941977697--

From: Lisa Dusseault <[email-masked]>
To: ietf-calsify list <[email-masked]>
Date: Tue, 26 Aug 2008 07:02:23 -0700
Subject: [Ietf-calsify] Proposed new text for 3.4.6

I was looking at the first few paragraphs of 3.4.6 and I couldn't  
quite figure out how the sending of a REFRESH, by the Organizer or an  
Attendee, combined with specifying a RECURRENCE-ID or not, and what  
the appropriate replies were for all cases.  Here's proposed new text.

------------

The "REFRESH" method in a "VTODO" calendar component is used either by  
"Attendees" or by the "Organizer" of an existing "VTODO" calendar  
component.  When an "Attendee" sends a "REFRESH" method, it's to  
request an updated description of the "VTODO" from the "Organizer".   
When an "Organizer" sends a "REFRESH" method, it's to request updated  
status from one or more "Attendees".

The "REFRESH" method MUST specify the "UID" property corresponding to  
the "VTODO" calendar component needing update.  It MAY specify the  
"RECURRENCE-ID" property also, to identify a specific instance.

Appropriate success responses to a "REFRESH" method:
  - If an attendee sends the "REFRESH" method with a UID but not a  
RECURRENCE-ID, the "Organizer" responds with a "REQUEST" method and  
the entire "VTODO" to bring the attendee up to date.
  - If an attendee sends the "REFRESH" method and it identifies a  
RECURRENCE-ID, the "Organizer" responds with a "REQUEST" method and  
the "VTODO"  instance.
  - If an "Organizer" sends the "REFRESH" method with a UID but not a  
RECURRENCE-ID, each recipient attempts to identify themselves in the  
"Attendee" list (possibly in several "Attendee" lists if there are  
exception instances), and checks their "PARTSTAT" to see if any update  
on their participation status is required.  If it is, they respond  
with a REPLY that includes each new status.
  - If an "Organizer" sends the "REFRESH" method and it identifies a  
RECURRENCE-ID, then the recipient attempts to identify itself in the  
"Attendee" list for that instance, and if their PARTSTAT needs  
refreshing, responds with a REPLY including only the instance in  
question.

Date: Fri, 22 Aug 2008 19:20:27 +0200
From: Julian Reschke <[email-masked]>
To: Helge Hess <[email-masked]>
Subject: Re: [Ietf-calsify] embedding the iCalendar URI (a	late	proposal	related to 2445bis)
Cc: IETF-iCalendar <[email-masked]>

Helge Hess wrote:
> On 22.08.2008, at 18:51, Julian Reschke wrote:
>> The default is that the browser stores the content into a local 
>> temporary file, and then invokes the application with the file name.
>>
>> I do recall that MS IE has a way to actually pass the URL instead of 
>> the document, but when I researched this a long time ago, I couldn't 
>> figure out how that works.
> 
> I couldn't find it in a quick search either, but I'm pretty sure its 
> supposed to work. But then maybe not :-):
> 
>   http://bitworking.org/news/Atom_Auto_Sub_How_To

Yes. That one inspired me to do RFC 4709.

> OK. Another way would be to deliver a different content-type which 
> contains the iCal URL. Something like this:
> --snip--
> Content-type: application/x-url-to-open
> 
> http://site/file.ics
> --snap--
> Could be a generic 'URL reference' MIME type, or something text/calendar 
> specific.

It would need to be specific, otherwise you can't dispatch to the right 
application. See RFC 4709 :-).

>>> Well, maybe the hack is worth it. But in this case I would prefer a 
>>> webcal:// scheme over an iCal embedded URL, to preserve the layering 
>>> between content and transport.
>>
>> <http://www.w3.org/TR/2004/REC-webarch-20041215/#URI-scheme>:
>>
>> "Good practice: Reuse URI schemes
>>
>> A specification SHOULD reuse an existing URI scheme (rather than 
>> create a new one) when it provides the desired properties of 
>> identifiers and their relation to resources."
> 
> Its also good practice not to mix transport with content :-)
> 
> OK, what about my special-reference entity suggestion then?

That would work as well, and this is what I've been using for launching 
WebDAV clients (successfully).

The "embed-the-source" approach works as well if content is being 
transferred anyway, and this is what Atom (RFC4287) uses.

> PS: hey! you are supposed to do CalDAV anyways! and download of full 
> vcals via HTTP ;-)

But, as far as I can tell, this has the same problem. How do you send a 
URL to a CalDAV calendar in an email? How does a Web server implement 
the "subscribe this with Caldav" functionality?

As a matter of fact, my original proposal would work in that case as well.

A CalDAV-aware client could do OPTIONS on the URI first, and check for 
CalDAV support, and then do "the right thing".

BR, Julian

Date: Fri, 22 Aug 2008 19:14:08 +0200
From: Julian Reschke <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-calsify] embedding the iCalendar URI (a	late	proposal	related to 2445bis)
Cc: IETF-iCalendar <[email-masked]>

Cyrus Daboo wrote:
>> Well, it would only happen once: you GET the calendar resource with your
>> browser, which passes it to the calendar application. That application
>> can then discover the "self" link, and offer to subscribe to the
>> calendar. From there on, you would always use the calendar application to
>> access the calendar.
> 
> By this argument then, any data handed off from a browser to another 
> application should include the original URL embedded in it because the 
> other app may want to re-fetch. So I think this is more an issue for the 
> OS/Application URL hand-off process. The URL where the data originally 
> came from ought to be attached to the file, or data stream, as meta-data.

I agree that it would be totally cool if it worked that way. But as far 
as I can tell, it doesn't.

I'd love to learn how to configure IE/FF/Safari to do this. Maybe this 
is something for the (gasp) HTML5 WG to consider?

BR, Julian

Date: Fri, 22 Aug 2008 13:10:10 -0400
From: Cyrus Daboo <[email-masked]>
To: Lisa Dusseault <[email-masked]>, ietf-calsify list <[email-masked]>
Subject: Re: [Ietf-calsify] ADD is really optional --?

Hi Lisa,

--On August 21, 2008 4:29:16 PM -0700 Lisa Dusseault 
<[email-masked]> wrote:

> I'm doing AD Review of iTIP and the way I read specs like this by default
> is that if there are a bunch of methods that can be sent around between
> agents, all of them must be supported.
>
> However, for the ADD method, iTIP specifies a way for a receiving client
> not to really support it -- return a REQUEST-STATUS of 3.14 followed by a
> REFRESH request.

Well that procedure can also be used for CANCEL and partial REQUESTs (ones 
that send only overridden instances). So this is not specific to ADD.

> Is ADD routinely supported by iTIP implementations or is this exception
> used in practice?

I believe there are some clients out there that let users add instances to 
a recurring set, and I would expect them to use ADD. But I have no firm 
evidence of

-- 
Cyrus Daboo

From: Helge Hess <[email-masked]>
To: IETF-iCalendar <[email-masked]>
Subject: Re: [Ietf-calsify] embedding the iCalendar URI (a late	proposal	related to 2445bis)
Date: Fri, 22 Aug 2008 19:07:38 +0200

On 22.08.2008, at 18:51, Julian Reschke wrote:
> The default is that the browser stores the content into a local  
> temporary file, and then invokes the application with the file name.
>
> I do recall that MS IE has a way to actually pass the URL instead of  
> the document, but when I researched this a long time ago, I couldn't  
> figure out how that works.

I couldn't find it in a quick search either, but I'm pretty sure its  
supposed to work. But then maybe not :-):

   http://bitworking.org/news/Atom_Auto_Sub_How_To

OK. Another way would be to deliver a different content-type which  
contains the iCal URL. Something like this:
--snip--
Content-type: application/x-url-to-open

http://site/file.ics
--snap--
Could be a generic 'URL reference' MIME type, or something text/ 
calendar specific.

>> Well, maybe the hack is worth it. But in this case I would prefer a webcal:// 
>>  scheme over an iCal embedded URL, to preserve the layering between  
>> content and transport.
>
> <http://www.w3.org/TR/2004/REC-webarch-20041215/#URI-scheme>:
>
> "Good practice: Reuse URI schemes
>
> A specification SHOULD reuse an existing URI scheme (rather than  
> create a new one) when it provides the desired properties of  
> identifiers and their relation to resources."

Its also good practice not to mix transport with content :-)

OK, what about my special-reference entity suggestion then?

Thanks,
   Helge

PS: hey! you are supposed to do CalDAV anyways! and download of full  
vcals via HTTP ;-)
-- 
Helge Hess
http://helgehess.eu/

Date: Fri, 22 Aug 2008 13:03:05 -0400
From: Cyrus Daboo <[email-masked]>
To: Julian Reschke <[email-masked]>, Helge Hess <[email-masked]>
Subject: Re: [Ietf-calsify] embedding the iCalendar URI (a	late	proposal	related to 2445bis)
Cc: IETF-iCalendar <[email-masked]>

Hi Julian,

--On August 22, 2008 6:51:35 PM +0200 Julian Reschke 
<[email-masked]> wrote:

>> Yes, but in what case would you download a calendar via URL and then use
>> the same URL again to re-download the same entity. That just doesn't
>> make a lot sense? :-)
>
> Well, it would only happen once: you GET the calendar resource with your
> browser, which passes it to the calendar application. That application
> can then discover the "self" link, and offer to subscribe to the
> calendar. From there on, you would always use the calendar application to
> access the calendar.

By this argument then, any data handed off from a browser to another 
application should include the original URL embedded in it because the 
other app may want to re-fetch. So I think this is more an issue for the 
OS/Application URL hand-off process. The URL where the data originally came 
from ought to be attached to the file, or data stream, as meta-data.

-- 
Cyrus Daboo

Date: Fri, 22 Aug 2008 18:51:35 +0200
From: Julian Reschke <[email-masked]>
To: Helge Hess <[email-masked]>
Subject: Re: [Ietf-calsify] embedding the iCalendar URI (a late	proposal	related to 2445bis)
Cc: IETF-iCalendar <[email-masked]>

Helge Hess wrote:
> On 22.08.2008, at 10:46, Julian Reschke wrote:
>> No, not a feed. Just the current state of the calendar. Exactly what 
>> you get when you subscribe (for instance) to a Google Calendar in 
>> Thunderbird, using "http" (not caldav).
> 
> OK.
> 
>>>
>> But it's the only way of opening the calendar in an application other 
>> than the browser *and* giving that application the original URL (at 
>> least in the operating systems I'm aware of).
> 
> I still don't get it. Can't you configure the browser to open your 
> calendaring application for the text/calendar content type? The browser 
> can invoke the application with the URL?
> (I'm pretty sure that Mozilla allows that, and IE definitely does open 
> by URL when you invoke a Word document for example, so it should also 
> work there, somehow)

The default is that the browser stores the content into a local 
temporary file, and then invokes the application with the file name.

I do recall that MS IE has a way to actually pass the URL instead of the 
document, but when I researched this a long time ago, I couldn't figure 
out how that works.

So let me know if you can convince one of these UAs to pass the URL, 
that would be an interesting outcome of this discussion as well.

>> It addresses exactly this problem. If the iCalendar object doesn't 
>> contain the URL it came from, the calendar application lacks that 
>> essential piece of information.
> 
> Yes, but in what case would you download a calendar via URL and then use 
> the same URL again to re-download the same entity. That just doesn't 
> make a lot sense? :-)

Well, it would only happen once: you GET the calendar resource with your 
browser, which passes it to the calendar application. That application 
can then discover the "self" link, and offer to subscribe to the 
calendar. From there on, you would always use the calendar application 
to access the calendar.

> Its really just a hack around an improper configuration of the URL/app 
> activation system.

It's a workaround for a missing feature in current UAs.

> Well, maybe the hack is worth it. But in this case I would prefer a 
> webcal:// scheme over an iCal embedded URL, to preserve the layering 
> between content and transport.

<http://www.w3.org/TR/2004/REC-webarch-20041215/#URI-scheme>:

"Good practice: Reuse URI schemes

A specification SHOULD reuse an existing URI scheme (rather than create 
a new one) when it provides the desired properties of identifiers and 
their relation to resources."

BR, Julian

From: Helge Hess <[email-masked]>
To: IETF-iCalendar <[email-masked]>
Subject: Re: [Ietf-calsify] embedding the iCalendar URI (a late proposal	related to 2445bis)
Date: Fri, 22 Aug 2008 18:27:47 +0200

On 22.08.2008, at 10:46, Julian Reschke wrote:
> No, not a feed. Just the current state of the calendar. Exactly what  
> you get when you subscribe (for instance) to a Google Calendar in  
> Thunderbird, using "http" (not caldav).

OK.

>>
> But it's the only way of opening the calendar in an application  
> other than the browser *and* giving that application the original  
> URL (at least in the operating systems I'm aware of).

I still don't get it. Can't you configure the browser to open your  
calendaring application for the text/calendar content type? The  
browser can invoke the application with the URL?
(I'm pretty sure that Mozilla allows that, and IE definitely does open  
by URL when you invoke a Word document for example, so it should also  
work there, somehow)

> It addresses exactly this problem. If the iCalendar object doesn't  
> contain the URL it came from, the calendar application lacks that  
> essential piece of information.

Yes, but in what case would you download a calendar via URL and then  
use the same URL again to re-download the same entity. That just  
doesn't make a lot sense? :-)
Its really just a hack around an improper configuration of the URL/app  
activation system.

Well, maybe the hack is worth it. But in this case I would prefer a webcal:// 
  scheme over an iCal embedded URL, to preserve the layering between  
content and transport.

Thanks,
   Helge
-- 
Helge Hess
http://helgehess.eu/

Date: Fri, 22 Aug 2008 14:21:54 +0200
From: Julian Reschke <[email-masked]>
To: Tim Hare <[email-masked]>
Subject: Re: [Ietf-calsify] embedding the iCalendar URI (a lateproposal	related to 2445bis)
Cc: 'IETF-iCalendar' <[email-masked]>

Tim Hare wrote:
> If you want a subscription experience, you could embed the URL of the .ics
> file in an Atom feed, couldn't you, and take advantage of the "self"
> property for the feed?

Not sure how that would help - I want to subscribe to the calendar, not 
a feed, after all.

> ...

BR, Julian

From: "Tim Hare" <[email-masked]>
To: "'Julian Reschke'" <[email-masked]>, "'Helge Hess'" <[email-masked]>
Subject: RE: [Ietf-calsify] embedding the iCalendar URI (a lateproposal	related to 2445bis)
Date: Fri, 22 Aug 2008 08:06:31 -0400
Cc: 'IETF-iCalendar' <[email-masked]>

If you want a subscription experience, you could embed the URL of the .ics
file in an Atom feed, couldn't you, and take advantage of the "self"
property for the feed?

As an aside, there's a TC-XML at Calconnect.org which is discussing XML
representation of iCalendar; this sort of thing might be of interest to
them.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Julian Reschke
Sent: Friday, August 22, 2008 4:47 AM
To: Helge Hess
Cc: IETF-iCalendar
Subject: Re: [Ietf-calsify] embedding the iCalendar URI (a lateproposal
related to 2445bis)

Helge Hess wrote:
> Julian,
> 
> I'm not sure what you mean by 'subscribe' in the context. Do you want 
> some kind of feed which is based on the iCal format? That is, 
> subsequent GETs on that feed URL only return changed items?

No, not a feed. Just the current state of the calendar. Exactly what you get
when you subscribe (for instance) to a Google Calendar in Thunderbird, using
"http" (not caldav).

> Subscribe in the iCal-over-HTTP context is just using that URL, cache 
> it and do proper if-none-match: etag requests to keep it up to date. 
> Thats no different to the subscription of regular RSS feeds.
> 
> I don't think that adding such URLs to the content format is good. It 
> blurs the boundaries between protocol (HTTP) and the payload (iCal).

But it's the only way of opening the calendar in an application other than
the browser *and* giving that application the original URL (at least in the
operating systems I'm aware of).

> Greets,
>   Helge
> 
> PS: I never understood why Apple needed the 'webcal' URI scheme. I 
> guess it was just a quick hack. It was probably easier to activate an 
> OSX application by URL than by the content-type of the URL entity.

It addresses exactly this problem. If the iCalendar object doesn't contain
the URL it came from, the calendar application lacks that essential piece of
information.

BR, Julian

Date: Fri, 22 Aug 2008 10:46:44 +0200
From: Julian Reschke <[email-masked]>
To: Helge Hess <[email-masked]>
Subject: Re: [Ietf-calsify] embedding the iCalendar URI (a late proposal	related to 2445bis)
Cc: IETF-iCalendar <[email-masked]>

Helge Hess wrote:
> Julian,
> 
> I'm not sure what you mean by 'subscribe' in the context. Do you want 
> some kind of feed which is based on the iCal format? That is, subsequent 
> GETs on that feed URL only return changed items?

No, not a feed. Just the current state of the calendar. Exactly what you 
get when you subscribe (for instance) to a Google Calendar in 
Thunderbird, using "http" (not caldav).

> Subscribe in the iCal-over-HTTP context is just using that URL, cache it 
> and do proper if-none-match: etag requests to keep it up to date. Thats 
> no different to the subscription of regular RSS feeds.
> 
> I don't think that adding such URLs to the content format is good. It 
> blurs the boundaries between protocol (HTTP) and the payload (iCal).

But it's the only way of opening the calendar in an application other 
than the browser *and* giving that application the original URL (at 
least in the operating systems I'm aware of).

> Greets,
>   Helge
> 
> PS: I never understood why Apple needed the 'webcal' URI scheme. I guess 
> it was just a quick hack. It was probably easier to activate an OSX 
> application by URL than by the content-type of the URL entity.

It addresses exactly this problem. If the iCalendar object doesn't 
contain the URL it came from, the calendar application lacks that 
essential piece of information.

BR, Julian

From: Helge Hess <[email-masked]>
To: IETF-iCalendar <[email-masked]>
Subject: Re: [Ietf-calsify] embedding the iCalendar URI (a late proposal related to 2445bis)
Date: Fri, 22 Aug 2008 10:24:43 +0200

Julian,

I'm not sure what you mean by 'subscribe' in the context. Do you want  
some kind of feed which is based on the iCal format? That is,  
subsequent GETs on that feed URL only return changed items?

Subscribe in the iCal-over-HTTP context is just using that URL, cache  
it and do proper if-none-match: etag requests to keep it up to date.  
Thats no different to the subscription of regular RSS feeds.

I don't think that adding such URLs to the content format is good. It  
blurs the boundaries between protocol (HTTP) and the payload (iCal).

Greets,
   Helge

PS: I never understood why Apple needed the 'webcal' URI scheme. I  
guess it was just a quick hack. It was probably easier to activate an  
OSX application by URL than by the content-type of the URL entity.

On 22.08.2008, at 10:11, Julian Reschke wrote:
> I've got a quick question about the iCalendar format, or actually an  
> idea.
>
> If I serve an iCalendar resource through HTTP, what I really want is  
> to allow the client not only to read it (display it in a calendar  
> application), but also to *subscribe* to it, for which I obviously  
> need the URI.
>
> Apple, years ago, "solved" this (and potentially some other use  
> cases) with their custom "webcal" URI scheme. (I note that this URI  
> scheme hasn't been registered with IANA.)
>
> The Atom WG was smarter, by allowing the format to carry a "self"  
> URI, for subscription (see <http://greenbytes.de/tech/webdav/rfc4287.html#rfc.section.4.2.7.2 
> >).
>
> Bernard already pointed me to the URL property (<http://tools.ietf.org/html/rfc2445#section-4.8.4.6 
> >), but what I'm looking for is a Calendar property, not a Component  
> property (I think).
>
> Is something like that possible in iCalendar? If not, could/should  
> it be added? (Separate document?)

-- 
Helge Hess
http://helgehess.eu/

Date: Fri, 22 Aug 2008 10:11:44 +0200
From: Julian Reschke <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] embedding the iCalendar URI (a late proposal related to 2445bis)

Hi,

I've got a quick question about the iCalendar format, or actually an idea.

If I serve an iCalendar resource through HTTP, what I really want is to 
allow the client not only to read it (display it in a calendar 
application), but also to *subscribe* to it, for which I obviously need 
the URI.

Apple, years ago, "solved" this (and potentially some other use cases) 
with their custom "webcal" URI scheme. (I note that this URI scheme 
hasn't been registered with IANA.)

The Atom WG was smarter, by allowing the format to carry a "self" URI, 
for subscription (see 
<http://greenbytes.de/tech/webdav/rfc4287.html#rfc.section.4.2.7.2>).

Bernard already pointed me to the URL property 
(<http://tools.ietf.org/html/rfc2445#section-4.8.4.6>), but what I'm 
looking for is a Calendar property, not a Component property (I think).

Is something like that possible in iCalendar? If not, could/should it be 
added? (Separate document?)

BR, Julian

From: Lisa Dusseault <[email-masked]>
To: ietf-calsify list <[email-masked]>
Date: Thu, 21 Aug 2008 16:29:16 -0700
Subject: [Ietf-calsify] ADD is really optional --?

I'm doing AD Review of iTIP and the way I read specs like this by  
default is that if there are a bunch of methods that can be sent  
around between agents, all of them must be supported.

However, for the ADD method, iTIP specifies a way for a receiving  
client not to really support it -- return a REQUEST-STATUS of 3.14  
followed by a REFRESH request.

Is ADD routinely supported by iTIP implementations or is this  
exception used in practice?

Lisa

From: Aki Niemi <[email-masked]>
To: "[email-masked]" <[email-masked]>
Organization: Nokia Devices R&D
Date: Tue, 05 Aug 2008 09:20:52 +0300
Subject: [Ietf-calsify] FYI: Nomcom 2008-9 Call for Volunteers

If you are qualified (have attended 3 out of past 5 meetings), please
consider volunteering for the Nomcom:
https://datatracker.ietf.org/ann/nomcom/1617/

Cheers,
Aki

-- 
Aki Niemi
Maemo Software, Nokia Devices R&D