vCard Format Specification
RFC 6350

Note: This ballot was opened for revision 22 and is now closed.

(Pete Resnick) Yes

Comment (2011-05-24 for -)
3.3 -
     NON-ASCII = %x80-FF
        ; Use is restricted by UTF-8
Why not use UTF8-char and reference RFC 3629?
4 - 
     TEXT-CHAR = "\\" / "\," / "\n"
               / <any VALUE-CHAR except , or \>
        ; Backslashes, commas, and newlines must be encoded.

Is it so bad to expand this out?

     TEXT-CHAR = "\\" / "\," / "\n" / WSP / NON-ASCII
               / %x21-2B / %x2D-5B / %x5D-7E
        ; Backslashes, commas, and newlines must be encoded.

6.1.2/6.1.3 - 

     BEGIN-param = 0dummy  ; no parameter allowed
     END-param = 0dummy  ; no parameter allowed
     BEGIN-param = 0" "  ; no parameter allowed
     END-param = 0" "  ; no parameter allowed

That looks neater to me.

6.5.1 - Is it worth an informative reference to
draft-lear-iana-timezone-database (approved BCP)?

(Peter Saint-Andre) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) (was Discuss) No Objection

(Stephen Farrell) No Objection

Comment (2011-05-23 for -)
(1) I'm surprised that there is no security considerations text about
the fact that you might run into trouble if you blindly follow URLs
that are embedded in vCards. There's probably easily copied text
somewhere on that.

(2) Similar point about embedded images and audio - again security 
considerations about parsing/rendering these carefully would be 

(3) You can specify a key but no signature? That's a pity but
I guess would be another spec entirely. Just wondering if anyone's
developing that.

(4) This allows a whole bunch of things to be included (e.g.
PGP keys, URLs etc.) but there are no conformance requirements
for what has to be supported. I guess that's in some other 
spec somewhere?

(David Harrington) No Objection

Comment (2011-05-25 for -)
1) in xCard,
New XML vCard property and parameter element names MUST be lower-case. This is necessary to ensure that round-tripping between XML and plain-text vCard works correctly. 
in vCard,
Based on experience with vCard 3 interoperability, it is RECOMMENDED that property and parameter names be upper-case on output. 
are these consistent?
2) references need updating (see id-nits)

(Russ Housley) No Objection

Comment (2011-05-24 for -)
  The discussion following the Gen-ART Review by Kathleen Moriarty on
  8-Apr-2011 lead to the following proposed text:
  o  vCards often carry information that can be sensitive (e.g.
     birthday, address, and phone information).  Although vCards have no
     inherent authentication or privacy provisions, they can easily be
     carried by any security mechanism that transfers MIME objects to
     address authentication or privacy (e.g.  S/MIME [RFC5751], OpenPGP
     [RFC4880]).  In cases where the privacy or authenticity of
     information contained in vCard is a concern, the vCard SHOULD be
     transported using one of these secure mechanisms.  The KEY
     property (Section 6.8.1) can be used to transport the public key
     used by these mechanisms.

  I would prefer the use of "confidentiality" instead of "privacy".
  That would better align with the definitions in RFC 2828.

(Dan Romascanu) (was Discuss) No Objection

Comment (2011-05-24)
I support the issues raised by Stephen Farrell in his COMMENT.  

(Robert Sparks) (was Discuss) No Objection

Comment (2011-05-24)
It would help to point to Appendix A earlier in the document, perhaps with a very high-level overview of what's been updated. An implementer will use Appendix A as a checklist of items to check against code - is it complete? There are changes called out in B (which will be deleted before being published) that don't seem to be reflected in A.

Were there any changes to what 4770 specified?

(Sean Turner) (was Discuss) No Objection

Comment (2011-05-24)
#1) Section 5.2 & 5.3: r/parameter is optional/parameter is OPTIONAL

#2) Sometimes the document uses ASCII and other it uses US-ASCII.  Was this intentional?

#3) Sec 6.8.1: lots of people use .cer or .pem for X.509 certificates can we change the example to: