Re: [apps-review] secdir/apps-area/last-call review of draft-ietf-vcarddav-vcardrev-19

[Simon Perreault <[e-mail]>]

On 2011-04-18 12:59, Barry Leiba wrote:
> ------------------------------
>    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).

Yes, more precise wording is better. Applied verbatim.

> ------------------------------
> 
>    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.

Applied.

> ------------------------------
> 
> 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.

Added.

> ------------------------------
> 
> 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).

Fixed.

> ------------------------------
> 
>    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.

Yeah it looks like it's allowed in XML Schema (not exactly sure though),
and I know it's parsed correctly by just about any programming language
standard library, so I'd prefer to leave it the way it is.

> ------------------------------
> 
> 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.

Fixed.

> ------------------------------
> 
>    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.

Agreed, but I don't know how to create such formatting with xml2rfc. So
I just created a regular, non-compact list:

   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'....

HA! I'll remove it. It contained an example of the URL property that was
not in my vCard, so I just added a URL property to my vCard.

> ------------------------------
> 
>    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 <[e-mail]>
> 
> Section 10.2.1 specifies the creation of a mailing list,
> <[e-mail]>.  Perhaps that should be the contact email address
> for the MIME type registration as well.

Agreed. I put "vCard discussion mailing list <[e-mail]>".

> ------------------------------
> 
>    10.2.1.  Registration Procedure
> 
> Nit: change "Standard Tracks RFC" to "Standards Track RFC", throughout.

Fixed.

> ------------------------------
> 
> That's all....

Thanks a lot!

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca