Calendar Access Protocol (CAP)
draft-royer-calsch-cap-03

IANA Comments:
IANA Considerations section needs to be more clear.
Are there initial assignments defined in this document?
There is no description of what happens after requests
go to the mailing list.
We understand there to be 1 beep profile registration.

[Ballot comment]
This is a somewhat existential abstain: if you ask for fixed ABNF and give specific examples, and get back a document that has similar specific problems, did you make a sound?

[Ballot comment]
This is a somewhat existential abstain: if you ask for fixed ABNF and point to a checker, and get back a document that fails that checker, did you make a sound?

[Ballot comment]
Reviewed by Joel Halpern, Gen-ART

His re-review of -01:

This draft is basically ready for publication as an Experimental RFC,
but has items that should be fixed before publication.

Yes, that is the same state I assigned the previous draft.  The one
moderate comment (included here) has not in my opinion been adequately
addressed.  The comment is:

moderate:
    UID is used without including a definition.  I had assumed "User
    ID", but then I got to the example in 3.3.1 where the command
    requests the server to return 10 UIDs, and I concluded that I had
    misunderstood.  There was also some earlier text that did not make
    sense about numbers of booked objects for a UID, but probably is
    fine once one knows what a UID is.

The revision attempts to address this by adding a parenthetical at the
first use of UID which reads "(UID is defined in [iCAL])".  This
leaves the reader still unable to determine what the heck a UID is
from reading this document.  All I am asking for is a simple
definition in the list of terms.  It is fine for it to say after the
definition "for more details see [iCAL]".

[Note]: 'This document is the successor to the draft-calsch-cap-13. As part of the closure of the CALSCH working group, the chairs, author, and I agreed that it should go forward as experimental to document the point the group reached.' added by Amy Vezza

[Ballot comment]
I think the community would benefit, given there's to be a revision, from a brief statement of
why this is experimental rather than standards track - to get implementation experience?

[Ballot comment]
top of page 26
      values are not case sensitive (e.g., "fanfeedback@redsox.com" is
      the same as "FANFEEDBACK@REDSOX.COM").
should that be fanfeedback@resdsocks.example.com or some such?

[Ballot comment]
Reviewed by Joel Halpern, Gen-ART

His review:

This draft is basically ready for publication as an Experimental RFC,
but has items that should be fixed before publication.

moderate:
    UID is used without including a definition.  I had assumed "User
    ID", but then I got to the example in 3.3.1 where the command
    requests the server to return 10 UIDs, and I concluded that I had
    misunderstood.  There was also some earlier text that did not make
    sense about numbers of booked objects for a UID, but probably is
    fine once one knows what a UID is.

minor:
  In section 3.1, the text says that the CUA builds a MIME
  encapsulated command command, and sends it to the CS.  However, the
  example in 3.3,1 shows that what is MIME encapsualted is rather
  more than the command.  It is a sequence of information, including
  CMD lines.  It would probably be better if 3.1 refered to a MIME
  encapsulated message, rather than a MIME encapsulated command.


Nit:
    2026 boilerplate and old intellectual property statement.

[Ballot discuss]
The ABNF has lots of blank lines in rules, which are not allowed.

The other-props rule is recursive.

The cap-factor rule has apparently-accidental trailing double-quotes on a couple of cap-calval

csid is defined twice, differently.

agendaprop has two adjacent "/" characters between "last-mod" and "owner"

agendacprop "" between "default-tzid" and "owner"

cmd has an extra "/" at the beginning of the grouping

I didn't do any checking of whether the grammar matches what the document describes.

[Ballot comment]
There are a few examples that use domain names not listed in RFC 2606, such as "redsox.com" (section 4.1.1), "foo.com" (section 4.3), "host.com" (section 6.1.1.3.2).

[Ballot discuss]
The Security Considerations say:
  :
  : The "IDENTIFY" command should be carefully implemented.
  :
  What are the concerns?  What are the potential consequences if the
  implementor isn't careful?

[Note]: 'This document is the successor to the draft-calsch-cap-13.  As part of the closure of
the CALSCH working group, the chairs, author, and I agreed that it should go forward as experimental
to document the point the group reached.' added by Ted Hardie