Last Call Review of draft-ietf-vcarddav-vcardrev-
review-ietf-vcarddav-vcardrev-secdir-lc-leiba-2011-04-21-00

This is a "triple-play" review -- I've been asked to review
draft-ietf-vcarddav-vcardrev-19 by the security directorate and the
applications area review team, and I'd planned to do my own review as
well.

SECDIR boilerplate:
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

APPS-REVIEW boilerplate:
I have been selected as the Applications Area Review Team reviewer for
this draft (for background on apps-review, please see


http://www.apps.ietf.org/content/applications-area-review-team

).
Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

My plat du jour:
I should note that I've participated in the vcarddav working group,
and have made comments on and contributed text to this document.  That
said, I'm looking at this with a "from scratch" mind, to be sure I'm
considering things afresh.

General comments:

The document is pretty much ready to ship.  The comments I make below
are minor, non-controversial, and easily fixed.  This is a mature spec
that's had quite a lot of review already.  Also, I see no
security-related issues with the document.

Reviewers of the companion document, draft-ietf-vcarddav-vcardxml,
will have to make sure the properties and parameters match up
correctly.  There is a general issue that this "legacy" vCard format
does not have a hierarchy that allows nested elements, which limits
its extensibility somewhat.  The working group did consider whether to
abandon this format in favour of using XML *only* for v4.0, and that
was deemed infeasible: there remains extensive use of this format, and
it needs to be retained, at least for now.

Specific comments:

------------------------------
   3.1.  Character Set

   The character set for vCard is UTF-8 as defined in [RFC3629].  There
   is no way to override this.  It is invalid to specify a different
   character set in the "charset" MIME parameter (see Section 10.1).

This isn't consistent with section 10.1.  UTF-8 is an encoding, not a
character set.  Section 10.1 says this, in reference to parameters on
the media type:

      "charset": as defined for text/plain [RFC2046]; encodings other
      than UTF-8 [RFC3629] MUST NOT be used.

That is the correct characterization.  The problem is that this is
used inconsistently in general, and there's been an extended
controversy in EAI about this very thing.  RFC 3536 specifies
internationalization terminology, and that's currently being updated
by draft-hoffman-rfc3536bis.  From that document:

   charset

      A charset is a method of mapping a sequence of octets to a
      sequence of abstract characters.  A charset is, in effect, a
      combination of one or more CCSs with a CES.  Charset names are
      registered by the IANA according to procedures documented in
      [RFC2978]. <NONE>

      Many protocol definitions use the term "character set" in their
      descriptions.  The terms "charset" or "character encoding scheme"
      and "coded character set" are strongly preferred over the term
      "character set" because "character set" has other definitions in
      other contexts and this can be confusing.

I suggest re-wording 3.1 thus (and an informative reference to RFC
3536 would be reasonable):

NEW
   3.1.  Charset

   The charset [see RFC3536 for internationalization terminology] for vCard
   is UTF-8 as defined in [RFC3629].  There is no way to override this.  It is
   invalid to specify a value other than "UTF-8" in the "charset" MIME
   parameter (see Section 10.1).
------------------------------

   3.3.  ABNF Format Definition

OLD
     ; When parsing a content line, folded lines must first
     ; be unfolded according to the unfolding procedure
     ; described above.
     ; When generating a content line, lines longer than 75
     ; characters SHOULD be folded according to the folding
     ; procedure described above.

NEW
     ; When parsing a content line, folded lines must first
     ; be unfolded according to the unfolding procedure
     ; described in section 3.2.
     ; When generating a content line, lines longer than 75
     ; characters SHOULD be folded according to the folding
     ; procedure described in section 3.2.

OLD
   A line that begins with a white space character is a continuation of
   the previous line, as described above.

NEW
   A line that begins with a white space character is a continuation of
   the previous line, as described in section 3.2.
------------------------------

Section 3.3 says this:
   Parameter values
   MAY be case sensitive or case insensitive, depending on their
   definition.  Based on experience with vCard 3 interoperability, it is
   RECOMMENDED that property and parameter names be upper-case on
   output.

Some of the parameter definitions ("value" (5.2) and "type" (5.6), for
example) use text strings for their values, and give no guidance on
case.  I suggest changing the paragraph in section 3.3:

NEW
   Parameter values
   MAY be case-sensitive or case-insensitive, depending on their
   definitions.  Parameter values that are not explicitly defined
   as being case-sensitive are case-insensitive. Based on
   experience with vCard 3 interoperability, it is RECOMMENDED
   that property names and parameter names be upper-case on output.

------------------------------

3.4. Property Value Escaping

OLD
   Finally, BACKSLASH characters in values MUST be escaped with a
   BACKSLASH character.  NEWLINE (ASCII decimal 10) characters in values
   MUST be encoded by two characters: a BACKSLASH followed by an 'n'
   (ASCII decimal 110).

This is inconsistent with section 4.1.

NEW
   Finally, BACKSLASH characters in values MUST be escaped with a
   BACKSLASH character.  NEWLINE (ASCII decimal 10) characters in values
   MUST be encoded by two characters: a BACKSLASH followed by either an
   'n' (ASCII decimal 110) or an 'N' (ASCII decimal 78).
------------------------------

   4.5.  INTEGER

I note that the ABNF allows "-0" (and, in fact, "-00000000") as a
valid integer.  If that's intended, that's fine; I just wanted to
point it out.
------------------------------

5.9.  SORT-AS

Is this parameter value intended to be case-sensitive?  I think so,
and that should be specified.  Let's fix the "less/fewer" error, while
we're here.

OLD
   This parameter's value is a comma-separated list which MUST have as
   many or less elements as the corresponding property value has
   components.

NEW
   This parameter's value is a comma-separated list which MUST have as
   many or fewer elements as the corresponding property value has
   components.  This parameter's value is case-sensitive.
------------------------------

   6.3.1.  ADR

   Special notes:  The structured type value consists of a sequence of
      address components.  The component values MUST be specified in
      their corresponding position.  The structured type value
      corresponds, in sequence, to the post office box; the extended
      address (e.g. apartment or suite number); the street address; the
      locality (e.g., city); the region (e.g., state or province); the
      postal code; the country name (full name in the language specified
      in Section 5.1).  When a component value is missing, the
      associated component separator MUST still be specified.

SUGGESTION:
I think this would be easier to read and get right as a compact list,
rather than as a paragraph of text.  Maybe like this:

NEW
   Special notes:  The structured type value consists of a sequence of
      address components.  The component values MUST be specified in
      their corresponding position.  The structured type value
      corresponds, in sequence, to
         the post office box;
         the extended address (e.g. apartment or suite number);
         the street address;
         the locality (e.g., city);
         the region (e.g., state or province);
         the postal code;
         the country name (full name in the language specified in
            Section 5.1).
      When a component value is missing, the associated component
      separator MUST still be specified.
------------------------------

   8.  Example: Authors' vCards

There's nothing wrong with leaving Pete Resnick's vCard in there as an
example, but I'll point out that he hasn't been a document editor
since -16 was posted.  I'll also point out that these are not
"authors", but "editors".  Just sayin'....
------------------------------

   9.  Security Considerations

I believe the specified security considerations are adequate, and I
have no issues with them.
------------------------------

   10.1.  MIME Type Registration

   Person & email address to contact for further information:  Simon
      Perreault <simon.perreault at viagenie.ca>

Section 10.2.1 specifies the creation of a mailing list,
<vcard at ietf.org>.  Perhaps that should be the contact email address
for the MIME type registration as well.
------------------------------

   10.2.1.  Registration Procedure

Nit: change "Standard Tracks RFC" to "Standards Track RFC", throughout.
------------------------------

That's all....

Barry