[Gen-art] Gen-ART LC Review of draft-jennings-impp-vcard-07

"Spencer Dawkins" <spencer@mcsr-labs.org> Tue, 01 August 2006 23:52 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G842g-00021e-4E; Tue, 01 Aug 2006 19:52:54 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G842e-00021Z-UJ for gen-art@ietf.org; Tue, 01 Aug 2006 19:52:52 -0400
Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G842c-0001bX-MJ for gen-art@ietf.org; Tue, 01 Aug 2006 19:52:52 -0400
Received: from s73602 (futurewei.com?[65.104.224.98]) by comcast.net (sccrmhc13) with SMTP id <20060801235249013009j88me>; Tue, 1 Aug 2006 23:52:50 +0000
Message-ID: <16fc01c6b5c5$690c0ce0$0400a8c0@china.huawei.com>
From: Spencer Dawkins <spencer@mcsr-labs.org>
To: General Area Review Team <gen-art@ietf.org>
Date: Tue, 01 Aug 2006 18:51:24 -0500
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Cc: ext Cullen Jennings <fluffy@cisco.com>, Lisa Dusseault <lisa@osafoundation.org>, Derek Atkins <derek@ihtfp.com>, Mark Day <mday@alum.mit.edu>, julian.reschke@greenbytes.de
Subject: [Gen-art] Gen-ART LC Review of draft-jennings-impp-vcard-07
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
Errors-To: gen-art-bounces@ietf.org

Hi, Cullen and Julian,

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.

Summary - this draft is almost ready for publication as a Proposed Standard 
RFC. I have two questions, which may very well be my own confusions, but 
wanted to ask before Last Call ended...

Please look at these comments along with any other Last Call comments you
may receive.

Thanks,

Spencer Dawkins

p.s. I have no editorial nits for this draft - thanks! It was clean and easy 
to understand...

-----------------

1.  Overview

   The normative definition of this new vCard type is given in
   Section 2, and an informational ABNF is provided in Section 3.

I may be more confused than usual, but section 3 looked fairly "normative" 
to me. At the very least, I was confused because the following text:

2.  IANA Considerations

   Type special notes: The type can include the type parameter "TYPE" to
   specify an intended use for the URI.  The TYPE parameter values can
   include:

   o  An indication of the type of communication for which this URI is
      appropriate.  This can be a value of PERSONAL or BUSINESS.
   o  An indication of the location of a device associated with this
      URI.  Values can be HOME, WORK, or MOBILE.
   o  The value PREF indicates this is a preferred address and has the
      same semantics as the PREF value in a TEL type.

seemed to say "or can include other values, not described here, and they 
happen to be described in the informative ABNF", and

   Additional information can be found in _RFCAAAA_.

   _[Note to IANA: Please replace AAAA with the RFC number for this
   specification.]_

seemed to say that the normative text (from section 2) pointed outside the 
normative text (presumably including section 3) - is this making any sense?

5.  Security Considerations

   This does not introduce additional security issues beyond the current
   vCard specification.  It is worth noting that many people consider
   their presence information more sensitive than other address
   information.  Any system that stores or transfers vCards needs to
   carefully consider the privacy issues around this information.

I understand the problem here, and there's probably not anything else you 
can do, but would it make sense to explicitly say "deployed applications 
that process vCards as blobs won't know that vCards now contain more 
sensitive information than previously, and system administrators should be 
aware of this"? 



_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art