cap-10 section 2. comments

[slh@xxxxxxxxxxxxxxxxxx]

below are some suggested changes to and questions about
section 2. of the cap-10 draft.
a lot of it is minor text fixes or possible abnf problems.
but I also have some questions about some of the abnf.
I believe there is nothing reguarding the actual function of the spec.


(same format as my previous msg about section 1.).


<PRE>
----------------------------------------
[13;707]

    other-props  = *(x-prop) *(iana-prop) *(x-prop)
    ***********************************************
[
does this give anything more than:
	other-props  = *(x-prop / iana-prop)
would (which seems simpler and more straight-forward)?
or maybe better yet:
	other-props  = *(other-prop)
	other-prop   = x-prop / iana-prop
and then usually using other-prop and
only using other-props when necessary and non-redundant?
]
----------------------------------------
[14;757]

   alarmseqparams = other-params [";" local-param] other-params
                    *******************************************
[
is this construct different than usual
just because, due to the single (non other-param) parameter,
the syntax can be expressed w/o qualifications in comments?
the usual construct is a repeating list of alternatives w/comments
indicating the allowable number of occurrences of each.
]

                  ; Where DIGIT is defined in [iCAL]
                  ;
    posint0     = 1*DIGIT
    posint1     = posintfirst 1*DIGIT
    *********************************
[
this would make posint1 a 2+ digit number?
should it be:
	posint1     = posintfirst *DIGIT
?
]

                  ; A number starting with 1 through 9.
                  ;
    posintfirst = %x31-39

    other-params = *(";" xparam) *(";" iana-params) *(";" xparam)
    *************************************************************
[
similar comment to other-props...
]
----------------------------------------
[15;795]

   trigger    = "TRIGGER" 1*(";" enable-param) (trigrel / trigabs)
                          ********************
[
should this be able to occur multiple times or just be optional?
]
----------------------------------------
[15;822]

   ENABLE -  The "ENABLE" parameter in CAP is used to tag a "TRIGGER"
      property in a component as disabled or enabled.  (Section 7.2).
                                                       **************
[
it seems constructs like ``(Section 7.2)''
should either all or none be followed by a period
(I do not know which is more correct,
 but it seems it should all be done the same)
]

   ID -  The "ID" parameter specifies a unique identifier to be used for
      any outstanding commands.
                               ^  (Section 7.3).
----------------------------------------
[16;844]

      in error and warning messages.
                                    ^  (Section 7.6).

   OPTIONS -  The "OPTIONS" parameter passes optional information for
      the command being sent.
                             ^  (Section 7.7).

   SEQUENCE -  When the "SEQUENCE" parameter is used in a "VALARM"
                                   ---------property
      component it uniquely identifies the instances of the "VALARM"
      within a component.
                         ^  (Section 8.?).
   *****************************************************************
[
this paragraph should be in the subsection 2.1.2 since it is a property.
there does not seem to be a subsection in section 8. for SEQUENCE.
]
----------------------------------------
[16;856]

   ALLOW-CONFLICT -  Some entries in a calendar might not be valid if
      other entries were allowed to overlap the same time span.
      (Section 8.1)
   ******************************************************************
[
is this the way this should be summarized?
]
----------------------------------------
[17;939]
   OWNER -  Each calendar has at least one "OWNER" property.  (xref
                                                              *****
      target="OWNER"/>) Related to the "CAL-OWNERS()" (Section 6.1.1.1)
      *****************************************************************
      query clause.
      *************
[
looks like something happened in the rendering of this sentence?
]

   PERMISSION -  This property specifies the permission being granted or
      denied.  Examples are the "SEARCH" and "MODIFY" values.  (Section
      8.25)

   QUERY -  Used to hold the CAL-QUERY (Section 8.26) for the component.
                                       XXXXXXXXXXXXXXX                  ^  (Section 8.25)
----------------------------------------
[18;985]

   TARGET -  The new "VCALENDAR" component property "TARGET" (Section
                                                             XXXXXXXX
      8.36) is used to specify which calendar(s) will be the subject of
      XXXXXX
      the CAP command.
                      ^(Section 8.36)
[
to be consistent with the other paragraphs
]
----------------------------------------
[20;1104]

   There MUST NOT BE more than one "BOOKED" state object in a calendar
   for the same "UID".  The "ADD" method value may create multiple
                                         XXXXXX
   objects all in the "BOOKED" state for the same UID, however for the
   purpose of this memo, they are the same object that simply have
   multiple "VCALENDAR" components.
----------------------------------------
</PRE>