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
