vCard Format Specification
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 good. (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
I support the issues raised by Stephen Farrell in his COMMENT.
(Robert Sparks) (was Discuss) No Objection
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
#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: KEY:http://www.example.com/keys/jdoe.cer?