Subject: Editing nits in CAP document

From: John Stracke <[email-masked]>
Date: Sun, 11 Jul 1999 07:38:06 -0400

It's formatted at 63 lines/page instead of 58.

There are some terms in the definitions that are never used in the
document, and should therefore be struck:

Connected Mode
Disconnected Mode
Delegate
Designate
High Bandwidth Connection
Local Store
Low Bandwidth Connection

And maybe Calendar Policy--it's not clear whether this term is the
same as the POLICY parameter that appears in the definition of VCAR.
(Calendar Policy sounds more like a rule that applies to all users,
regardless of access rights.) If these are the same, then the example
given is inappropriate; it should be taken from the list of possible
POLICIES in section 13.1.  Otherwise, the definition should be struck,
as it is not used anywhere else in the document.

The definition of Calendar Properties says, "For example, CALSCALE
specifies the calendar scale (e.g., GREGORIAN) for the whole
calendar."; but the words "calscale", "scale", and "gregorian" do not
appear anywhere else in the document, so this is probably not a useful
example.

The definitions of Calendar Service and Calendar Store reference each
other.

The definition of Hierarchical Calendars is odd--rather than saying,
"a calendar may have children", it says, "a calendar may have a
child, and a child may have siblings".

The definitions of Qualified Calendar Identifier and Relative Calendar
Identifier imply that they are URLs; but the definition of Calendar
Identifier does not.

From the definition of Realm: "The name of the realm is only used in
UPNs."--that should be "is used only in UPNs".  Subtle difference; "is
only used in UPNs" means "UPNs only use it" (i.e., they don't, say,
abuse it).  Similarly, in 2.5.2, "The Calendar Service only permits
the operation if" should be "The Calendar Service permits the
operation only if".  (Yeah, it's obscure.  What can I say? My dad's an
English professor.  :-)

The definition of Remote Store is used, but it shouldn't be.  It's
used only in the first sentence of 5.1, Searching and Filtering: "This
section describes CAPs searching and filtering entities within a
remote store."--but, of course, it should apply also to a Local Store.
I believe this sentence should be changed to say "calendar store", and
the definition of Remote Store should be struck.

The definition of Sub-calendars is not grammatically parallel
("calendars" does not agree in number with "another calendar, its
parent").

In the definition of User Principal Name (UPN): change "it's" to
"its".

From section 2.1: "The CUA prepares an MIME encapsulated": change "an"
to "a".

Later in 2.1, there's some text that I believe is (unnecessarily)
confusing: "CS1 MUST be able play the role of a CUA and use [RFC2447]
to interoperate with other CUAs."  This took me a couple of readings
before I realized that the term CUA had been overloaded: it means both
a CAP client and an iMIP endpoint.  Since a CUA (in the sense of "a
calendaring application used by a human") may implement either or both
of these protocols, I believe we should have separate names for the
implementations.  (Perhaps just "CAP CUA" and "iMIP CUA", which would
allow us to guess from context in most cases; then most of the CAP
document could survive unchanged, and this particular sentence could
be rephrased as "play the role of an iMIP CUA".)

From 2.4: 'such as "chair", "REQ-PARTICIPANT" or NON-PARTICIPANT"':
missing quotation marks before NON, I think.

2.5.2: "assocatied" to "associated".

2.8 ends abruptly, and 2.9 starts with a whole bunch of blank space
(and no title).

2.11 is empty.

3: "State names shown with first letter capitalized.": we need a
verb.

3: the diagram needs to be fixed; it's got some regions that are
shifted right.

3: "The capabilities the server offers in the Authenticated state may
be different than those in the Connected state." (a) Why? (b) That
should be "different from".

3: "The DISCONNECT command can also be issued from the Receive state."
Fine, but what happens then? Is the outstanding command implicitly
ABORTed? What happens if the CUA drops the connection gracelessly?

4.2: "The CS listens for connections on port <xyz>."--in 2.6, port
5226 was specified.

4.3: "No other tagged command sequence can be sent..."--the term
"tagged" is not defined.  (Same problem in 7: "the possible tagged
status responses to a command".)

6.1: "By implication, calendar access rights specified in a
sub-calendar are inherited as default calendar access rights for any
calendars that are hierarchically below the sub-calendar.": I have no
problem with this feature, but it's not "by implication", because the
previous sentences discuss inheritance of rights specified in a
calendar, not all rights that apply to a calendar.

7.1.1: Needs a line break after "Data: none".

7.1.2: "whoselatency" to "whose latency", "onthe" to "on the".

7.1.3: "Data: continuation data may be requested": by whom? Does this
mean it may be included with the command?

7.1.3: "T capabilities of the CS...": "T" to "The".

7.1.3: "All implementations MUST support Digest-MD5 authentication
using DES and 3DES": this will prevent CAP from being used in France,
where encryption software is banned.  (Or maybe the ban's been lifted
and I haven't heard.  But there will probably be other such bans in
the future.)

7.1.3: "CAP does not provide support for SASL authorization
identities.": I'm not sure this is legitimate; RFC-2222 says that
authorization identities are a key feature of SASL.  (I'm also not
sure why we would want to forbid them: the IDENTIFY command is an
on-the-fly equivalent, and so authorization identities could be
implemented by a subset of the IDENTIFY code.) In any event, though,
even if it is legitimate, this sentence should phrased differently,
since it implies that the SASL syntax has to be changed to omit the
authorization identity altogether.  Perhaps something like, "The SASL
authorization identity must be either the empty string or the same as
the identity in the client's authentication credentials".

7.1.3: "A CAP session does not have an identity until the CUA has
issued the "AUTHENTCATE" command.": misspelled AUTHENTICATE.

7.2.1.*: "container" doesn't seem to be defined anywhere.

7.2.2: "[Editors Note: This section needs to be completed by adding
the restriction tables for each of these iTIP methods. The basis for
the text is to be taken from [RFC2446].]": it's usually a bad idea to
copy text around (it's just like copying code).  Better to include a
reference to the appropriate section(s) of 2446.

8: "[Editors Note: Do we want to use the same set of codes?]": yeah,
probably; it makes it easier to implement error-to-string functions
(for UI purposes).

8: "9.0 An unrecongnized command was received.": "unrecongnized" to
"unrecognized".

9.1: "An implementation may not actually have a VFREEBUSY table as the
information may be produced dynamicly.": "dynamicly" to
"dynamically".

14: The definition of "entity" should be moved from 14.2 to 14, for
clarity.

17: There's no bibliography entry for SASL.

18: Not all the authors are listed--Paul Hill is missing.

-- 
/=============================================================\
|John Stracke    | My opinions are my own | S/MIME & HTML OK  |
[email-masked]|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/