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

Simon Perreault <simon.perreault@viagenie.ca> Thu, 19 May 2011 13:31 UTC

Return-Path: <simon.perreault@viagenie.ca>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A589E0656; Thu, 19 May 2011 06:31:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TScwLhNi+L2P; Thu, 19 May 2011 06:31:31 -0700 (PDT)
Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 2A872E066A; Thu, 19 May 2011 06:31:29 -0700 (PDT)
Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D4A0520D2C; Thu, 19 May 2011 09:31:27 -0400 (EDT)
Message-ID: <4DD51BAF.7070505@viagenie.ca>
Date: Thu, 19 May 2011 09:31:27 -0400
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110320 Fedora/3.1.9-4.fc16 Lightning/1.0b3pre Thunderbird/3.1.9
MIME-Version: 1.0
To: Barry Leiba <barryleiba@computer.org>
References: <BANLkTin_t2SbY5V3yb_8gG26s31bf47_iw@mail.gmail.com>
In-Reply-To: <BANLkTin_t2SbY5V3yb_8gG26s31bf47_iw@mail.gmail.com>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Fri, 20 May 2011 08:21:45 -0700
Cc: apps-review@ietf.org, secdir@ietf.org, iesg@ietf.org, vcarddav@ietf.org, draft-ietf-vcarddav-vcardrev.all@tools.ietf.org
Subject: Re: [secdir] secdir/apps-area/last-call review of draft-ietf-vcarddav-vcardrev-19
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 May 2011 13:31:32 -0000

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 <simon.perreault@viagenie.ca>
> 
> Section 10.2.1 specifies the creation of a mailing list,
> <vcard@ietf.org>.  Perhaps that should be the contact email address
> for the MIME type registration as well.

Agreed. I put "vCard discussion mailing list <vcarddav@ietf.org>".

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