Simon, I am fine with the changes. The last is not a Gen-ART, but was put there for adding considerations to the security section. I just meant that it should state that there may be privacy concerns with some of the information. I listed the regulations to give examples, but not to have them entered into the document. You mention the use of encryption for protection against spoofing, it would also be used for confidentiality in protecting privacy of the information.
Best regards, Kathleen -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Simon Perreault Sent: Saturday, April 09, 2011 6:51 AM To: Moriarty, Kathleen Cc: [email protected]; [email protected] Subject: Re: [Gen-art] Gen-ART review of draft-ietf-vcarddav-vcardrev On 04/08/2011 11:21 PM, [email protected] wrote: > Section 3.2, paragraph 2: > It reads as a 4 element list instead of 2, here is one option: > Change from: (space, ASCII decimal 32, or horizontal tab, ASCII decimal 9). > To: (space (ASCII decimal 32) or horizontal tab (ASCII decimal 9)). Changed. > Section 5.2: > Consider changing from: The VALUE parameter is optional, and is used to > identify the value > type (data type) and format of the value. > To: The VALUE parameter is optional, used to identify the value > type (data type) and format of the value. Changed. > Section 5.2: > Although it is a preference to have a comma before the last value in a list, > the IETF prefers it according to the Gent-ART guidance. The usage would also > be consistent with the other comma separated lists in the document. > Change from: value lists except within the N, NICKNAME, ADR and CATEGORIES > properties. > To: value lists except within the N, NICKNAME, ADR, and CATEGORIES properties. Changed. > Section 5.3: > Remove the comma in the first sentence, it is not necessary. Removed. > Section 5.5: > Comma is not necessary in the following sentence (only when the list has 3 or > more values): > Its value is either a single small positive integer, or a pair of small > positive integers separated by a dot. Removed. > Section 6.1.4: > Second paragraph of 'location' section > Change from: All properties in an location > To: All properties in a location Changed. > Iana-token section: > Change from: A new value's specification document MUST > specify which properties make sense for that new kind of vCard, and > which do not. > To: A new value's specification document MUST > specify which properties make sense for that new kind of vCard and > which do not. Changed. > Section 9: > Birthday, address, and phone information could be sensitive. In the third > bullet, you may want to protect certain information if required by > regulations (country, state specific, and industry - FERPA for universities) > The cryptographic keys would just be the public key for the user in the card > if it was shared. I'm sorry, I disagree with that. IETF protocols should not be concerned with local regulations [RFC2804]. Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
