[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
- [Gen-art] Gen-ART LC Review of draft-jennings-imp… Spencer Dawkins