Skip to main content

vCard Format Specification
draft-ietf-vcarddav-vcardrev-22

Yes

(Peter Saint-Andre)

No Objection

(Adrian Farrel)
(Gonzalo Camarillo)
(Jari Arkko)
(Ralph Droms)
(Ron Bonica)
(Stewart Bryant)
(Wesley Eddy)

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

Pete Resnick Former IESG member
Yes
Yes (2011-05-24) Unknown
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 Former IESG member
Yes
Yes () Unknown

                            
Adrian Farrel Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Dan Romascanu Former IESG member
(was Discuss) No Objection
No Objection (2011-05-24) Unknown
I support the issues raised by Stephen Farrell in his COMMENT.  
David Harrington Former IESG member
No Objection
No Objection (2011-05-25) Unknown
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)
Gonzalo Camarillo Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection () Unknown

                            
Ralph Droms Former IESG member
No Objection
No Objection () Unknown

                            
Robert Sparks Former IESG member
(was Discuss) No Objection
No Objection (2011-05-24) Unknown
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?
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (2011-05-24) Unknown
  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.
Sean Turner Former IESG member
(was Discuss) No Objection
No Objection (2011-05-24) Unknown
#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?
Stephen Farrell Former IESG member
No Objection
No Objection (2011-05-23) Unknown
(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?
Stewart Bryant Former IESG member
No Objection
No Objection () Unknown

                            
Wesley Eddy Former IESG member
No Objection
No Objection () Unknown