Subject: Guide to Internet Calendaring Pass 01

From: [email-masked]
Date: Mon, 19 Mar 2001 14:34:51 -0500

Bob and George put some work into the Guide but in doing at least a first 
or second pass on it I I have some comments/questions.  (Of course I do, 
otherwise I wouldnt be sending this, no??)

This is going to be long but each item is brief.  I will put large issues 
in separate documents; Im only putting small stuff in this 1 big posting 
since I expect little need for followup discussion on the items below. 
There are 21 tidbits, mostly small but a couple that require more than a 
simple typo fix.

#1: Status or TOC?

>Status of this Memo
>   1.  Introduction
>       Terminology
>   2.  Requirements

There is no Status text; there is a Table of Contents though...

#2: Page numbers?

The TOC is simply entries:
>   1.  Introduction
>       Terminology
>   2.  Requirements
>       Fundamental Need
>       Protocol Requirements
>   3.  Standards Solution
>       Examples
>       Systems
>       Standalone single-user system
>       Single-user systems communicating

There are no line numbers that are normally found in Drafts and RFCs... 
Please add 'em so I can index faster on paper.

#3: Sub-items are not numbered:

Look at the snippet above and you will see that only the top sections have 
numbers.  There is no 1.1 or 2.3, etc. (unless you read the body and find "1.1 Terminology", etc).  This is necessary for proper discussion and publishing beyond Draft. It 
may be an artifact of your text editor but it needs fixing...

#4: Internet only?

>   understanding, and potentially help implementors in the design of
>   their internet calendaring and scheduling systems.

Since C&S is intranet as well as internet the phrase "their internet" in 
the last line is misleaing.  How about "their standards based" (or 
'oriented') instead?

#5: Bibliography nits:

>   [IRIP] draft-ietf-calsch-irip iCalendar Real-time Interoperability
>   Protocol
>   [CAP] draft-ietf-calsch-cap Calendar Access Protocol

It is normal draft practice to cite actual revision numbers for drafts if 
known.  Since iRIP is expired, it should be noted as such in the 
Bibliography.  The CAP draft is now at 04 so it should be reflected in its 
entry.

#6: Bibliography nits 02:

>   [ICAL] [RFC-2445] Calendaring and Scheduling Core Object
>   Specification
>   [ITIP] [RFC-2446] iCalendar Transport-Independent Interoperability
>   Protocol
>   [IMIP] [RFC-2447] iCalendar Message-Based Interoperability Protocol

3 nits:

1: There are no references to "[RFC-244x]" anywhere in the draft so they 
do not belong in the index as notations.  In fact there are NO RFC 
citations ANYWHERE in the draft so why are there any for MIME, etc if they 
are not referenced??
2: Why are our RFCs cited differently than the others like MIME?  The 
reference format is not the 'standard' one Ive always seen.  Normally it 
would look like:
   [RFC 2045] Freed, N. and N. Borenstein, " Multipurpose Internet Mail
              Extensions (MIME) - Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.
We should be consistant.
3: In the text we should use "iCalendar [RFC 2445]" instead of "[ICAL]" 
and remove the non-semi-standard [ICAL], etc refs in favor of [RFC 2445], 
etc.  This also applies to "[ITIP]" and "[IMIP]".

#7: Definition nit

If "Delegate" is defined then "Delegator" should also be defined.  As it stands now, 
both are defined under 1 heading.

#8: Definition nit 2

"Local Store" is defined starting with "A CS which" but the abreviation "CS" is not clearly indicated.  The same can be said 
for CU and others.  Only CUA is properly notated next to the term in the 
definitions. The same goes for "Remote Store".  Add all abreviations to 
the proper defintions!

#9: Definition nit 3

"Remote Store" is defined but never used.  Remove it or use it in the 
text.

#10: Unclear phrasing/description:

The phrase:
      iMIP is "expressing it in email terminology" an
      EMAIL dictionary
is unclear.  I assume some punctuation after the last DQUOTE is missing or 
the "an EMAIL dictionary" is residual.  Clarify and fix up the analogy.

#11: Bibliography nit 03:

"RFC822" is used often but never clearly defined in the Bibliography.  Add it and 
use the "[RFC 822]" format in the text...

#12: Slightly askew Relationship text:

The text:

      iTIP is how you use the language.
      iMIP is further definition for use over email.
      iRIP is the language used over a real-time transport

is slightly misleading when describing iMIP and iRIP.  iMIP is not a 
"further definition" of iCalendar; it is the "definition of how to send 
iTIP messages over eMail".  iRIP is (or was) "how to send iTIP messages 
over a real-time transport".  iMIP does not extend iTIP, it 'instanciates' 
it.  The same for iRIP.

Also, the description:
      CAP is how to use the language, in real-time, to access a
      calendar server
is also slightly misleading.  CAP describes not only how to _access_ the 
server but also data stored on the server (in the store in various 
calendars or on entries in the store).

Finally, the text:
  (scheduling not booking)
is not grammatically correct in its context.  Should it have a comma 
before the "not"?  If you are drawing a line between Calendaring and 
Scheduling (or booking) then you need to define these terms.

#13: Unclear "it" usage:

The analogy text:

      iMIP is "expressing it in email terminology" an
      EMAIL dictionary
      CAP/iRIP is "expressing it for use in a Real Time transport"

has a dangling 'it' in the dquoted phrases.  Please clarify the reference 
or expand the phrasing a bit.

#14: Under 2.1 Fundamental Needs:

Some examples do not quite demonstrate the stated need.  For example, 'a' 
does not really describe the need for "with only one CUA."   It describes a need to be able to access a calendar w/any CUA, not 
just 1 CUA.

Examples 'a' and 'b' could easily be combined into 1 "Need", the one that 
'b' currently has.  At best, the real difference between 'a' and 'b' is 
that one is Intranet and the other is Internet...

Example 'd' is not quite gramatically correct; "to book time slot" should be "to book a time slot".  Also, the need is too narrowing.  "Schedule calendar events and todos" precludes a teacher having the students send 'progress reports' (ala 
VJOURNALs) to him.  Why not use the more generic phrase "Schedule calendar entries" instead? The same comment applies to example 'f'.

Example 'e' is the logical opposite of 'c' and 'd' is the opposite of 'f' 
so why not swap 'd' and 'e' so that the "Share" cases are together and the 
"Schedule" cases are too?

Since all the examples really have a "possibly from different vendors" clause that is applicable but only some have it, why not put a statement 
about ALL the examples being in both a homogeneous and heterogenous 
enviorment?  For example, 'a' could easily be a Palm handlheld accessing 
his Domino server.  Its a single CUA accessing a single calendar but it is 
not simply a Notes CUA accessing a Domino calendar server...

#15: Bad iTIP example in 2.2 Protocol requirements

The example is missing a DTSTAMP, METHOD, UID and maybe more.  If the 
example is not supposed to be iTIP then a frame of reference is needed. At 
least include the normally "mandatory" stuff like UID and DTSTAMP even if 
its not iTIP so we dont get "Is the example wrong?" questions later in 
last call or beyond.

For the labeled iTIP example, the missing UID MUST be put in

#16: Editorial nit:

The phrase "decline counters to, the various" does not require a comma in it.

#17: Editoral nit:

Is there any need for the phrase "
         Both CUAs and calendar services may have [ITIP]
         interpreters."
where it currently is??  I dont think so...

#18: Odd/misleading CAP descriptions

         [CAP] also provides a real-time binding for the calendar
         management messages.

is misleading as we currently have no calendar management messages in iTIP 
or iCal.  I think the phrase should have been something like:

         [CAP] also provides a real-time binding for the [ITIP]
         messages.

Also, above that is a very misleading paragraph:

         [CAP] describes the messages used to manage calendars. These
         messages are represented in [ICAL], and have semantics such as
         being a search for data, being data in response to a search or
         the being the creation of a meeting.

Again, nothing CAP uses for managing calendars is currently in 2445.  We 
are working on extensions to 2445 to do this.  The comments above about 
phrasing to include "[ICAL] and extentensions to [ICAL]" apply here too. 
It also applies to the rest of the CAP description paragraphs in this 
section.

#19: Bad C/S example:

The C:/S: example is bad.  The example has:

            C:content-transfer-encoding: 7bit
            C:BEGIN:VCALENDAR

but there should be a "C:" between them (to have a CRLF in the stream 
between the header and the body).  Also the server response is illegal 
since it has:

            S: END:VCALENDAR
            S: Content-Type:text/calendar; method=RESPONSE;

which blurs the header of the second response into the body of the 1st. 
KISS the example and make it simply create the entry on one calendar. 

The text "Furthermore, CAP
         is still a draft, thus the details of one can create
         such an event may change."
has a dangling "one" reference that needs a home.  Its unclear if the 
reference is to the example is in flux for CAP or what...

#20 Editorial nit:

      When specified using correct iCalendar grammar, we refer to these
      event representations or operation requests as " calendar object
      representations 

is missing a final dquote.

#21 What did they say???

After reading and then rereading the following paragraph:

      A system may implement the first methodology only. The second one
      is dependent on iTIP. It requires understanding of iTIP and the
      ability to communicate with other CAP servers using iTIP. Since,
      currently, iMIP is the only binding of iTIP, the second method
      is also dependent on iMIP.

I just had to say "Huh?!?". Questions I have include:

1: What are you referring to with "A system"?  This is all in the context 
of the ICAL/ITIP/CAP and so I assume its "A calendaring system" but thats 
not a defined term so Im still assuming...
2: Both methodologies (not shown above) are dependent on iTIP, NOT just 
"the second one".  Ya cant implement iMIP w/o knowing iTIP.  So why single 
out "the second one"??
3: Why does the CAP require "the ability to communicate with other CAP servers using iTIP" instead of requiring the ability to speak CAP to other CAP servers??? 
One server does not speak iMIP to another CAP server (unless you are 
trying to tie in CRISP here but I dont think it works that way.)
4: The entire last line is circular reasoning and wrong.  CAP is new but 
so are CAP servers so there wont be any that only speak iMIP (they will 
speak CAP from the start!).  There is nothing in CAP (last I read it end 
to end) that mandates iMIP support so the last tidbit about dependence on 
iMIP is wrong.  A CAP server should speak CAP to another CAP server, NOT 
iMIP or some other "store and forward" binding.

Thats enough for now.  My 9 fingers are cramping up and I have other tasks 
I need to focus on for now.  More comments later...

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