Subject: Re: [Ietf-calsify] AD Review of RFC2446bis

From: Cyrus Daboo <[email-masked]>
Date: Sun, 07 Sep 2008 22:38:40 -0400

Hi Lisa,
Thanks for the review. Comments in line. Most of your issues I have 
addressed by fixes to my working copy.

--On August 26, 2008 9:15:46 AM -0700 Lisa Dusseault 
<[email-masked]> wrote:

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

OK - the term "calendar entry" is specific to this spec. It is not formally 
defined and frankly it is not clear precisely what it means, though section 
2.1 kind of introduces it. I have replaces it with "iCalendar object" with 
some suitable re-wording in places where it is used.

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

So section 1.4 now just describes "generic" iCalendar objects, and the 
existing table in section 3 now gives the specific restrictions for the 
components defined in 2445. So I think no change is needed here.

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

It needs to be clear that there is only one primary component type allowed 
per iTIP message. Hence when a VEVENT is present in an iTIP message, VTODO, 
VJOURNAL can't be. I have added some text to the end of 1.4 to indicate 
that.

In addition I will add an extra caption above each restriction table to 
make it clear what is being described.

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

OK, that piece is missing. I've added the missing step of the uninvited CU 
replying to the organizer.

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

"Unsuccessful" in this case means received but processing failed for some 
reason. I'll change the text to:

The "REPLY" method is also used when processing of a "REQUEST" fails.

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

Frankly it shouldn't matter. The client processing the data is going to 
have to do its own sorting anyway as part of its processing. Really the 
only benefit of sorting here is for humans reading the raw iCalendar data.

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

I will move that statement into the PUBLISH section. The third sentence 
will be removed because that refers to REPLY behavior which is not allowed 
to return multiple VFREEBUSY's.

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

Changed.

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

Well the calendar user using the CUA would be listed as an ATTENDEE if that 
user is being assigned the to-do. If it is a cc that calendar user's 
address would not appear in any ATTENDEE property.

Actually there is a weakness overall here in that it is not possible to 
include details about who might have been cc'd or bcc'd on an invite in the 
calendar data itself. It can be done by the transport (e.g. email headers). 
But not all transports have that capability by default. Plus that 
information is lost when the calendar data is extracted from the transport 
"wrapper". I don't propose we do anything about that in 2446bis, but I 
expect that we will need some new properties for this in the near future.

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

Changed to 3.14.

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

Have not seen the separate email...

> Section 3.6, table, row for code 5.0 says:
>
>
> "Request MAY supported"
>
>
>
> Something must be missing here?

I think that should be "Request not supported". I have changed the text to 
reflect that.

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

Actually this brings up an important point. Not only do we have X- tokens, 
but we also have IANA registered tokens that may extend the base set. Since 
2445bis calls out "iana-prop" as a separate item in its formal syntax, we 
should use IANA-PROPERTY etc in 2446bis to correspond to those. But we need 
to make some kind of statement about how the IANA- items should be treated 
as per 3.7.3. Really "IANA tokens SHOULD be saved and MAY be returned 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.

Fixed.

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

In section 4.2.5 there is an "Editor's Note" left over from the original 
spec! The fact is there is no offical way for the delegate to include the 
delagator in their REPLY. Therefore I propose removing the text in 4.2.5 - 
the text in 4.2.7 is correct - the Organizer must push the notifications 
out.

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

Fixed.

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

OK, the whole fallback thing needs some major revisions. Looking at it now 
smethings are clearly wrong. e.g. ignoring the VERSION property is totally 
wrong, as is defaulting CALSCALE to GREGORIAN. That would make it all but 
impossible to do a significant revision to 2445 in the future. Your other 
point that the fallbacks need to be treated separately for send and 
receiver is also valid. Maybe we need to split the Fallback column into two 
for that?

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

The "Methods Registry" is defined in Section 8.3.12 of 2445bis. I have 
added a reference to that in the IANA section to clarify where the METHOD 
registrations are supposed to go.

-- 
Cyrus Daboo

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