The vast majority of my comments are minor editorial nits. This is a
clear, well-written, document.
1. Introduction
Line 132: an object that includes a user's privacy
It may be better to say "an object that includes some aspects (those
that are not themselves sensitive) of a user's privacy"
Lines 162, 180, 207, 384, 417, 431, 534, 847, 880: -
Should use two hyphens to represent a dash ("--") instead of one ("-").
Line 177: However
Since it follows the "only" clause, this sentence extends, rather
than contradicts the train, and hence it may be better to use
"Therefore" instead of "However"
Section 2.1
Line 190: that location information
Suggest adding "the": "that the location information"
Line 216: in the very broad terms
Suggest deleting "the": "in very broad terms"
Section 2.2 Extensions to PIDF for Location and Usage Rules
Line 243: By composing this two subelements
Suggest changing "this" to "these": By composing these two subelements
Lines 247-248: any other subelements
Suggest using either "any other subelement" (singular) or "other
subelements" (plural)
Section 2.2.1 'location-info' element:
Line 262: Schema(s) that will be used
Suggest changing to "Schema(s) that are used", since we're talking
about objects at the point where they exist ("All PIDF documents that
contain")
Line 298: has defined by
Change "has" to "as".
Line 374: MUST be support by
Change "support" to "supported": MUST be supported by
Line 375: specification, and the
Suggest changing the comma to a semicolon and deleting "and":
specification; the
Section 2.2.2 'usage-rules' element
Lines 406, 415, 427, 452:
Suggest adding a blank line before each element description.
Lines 412-414: Implementations MUST
include this field, with a value of 'no', if the Rule Maker
specifies no preference.
Lines 383-386: Each 'geopriv'
element SHOULD contain one 'usage-rules' element - Location
Generators MAY opt not to include this element if the Rule Maker has
requested that all sub-elements given below have their default
The combination of the SHOULD and MAY in lines 383-386 is itself
potentially confusing; combined with the MUST in 412-414 the risk of
misunderstanding increases. Suggest clarifying when the elements
must appear in an object.
Section 2.2.3 'method' element
Line 474: (i.e.
The abbreviations "i.e." and "e.g." should be written with a comma
afterwards; it should be changed to "(i.e.," except that in this
situation perhaps "e.g." may be what is intended, since the text
seems to be listing two examples rather than rewording the concept;
I'm not sure though. It might also be better to spell out the
intended phrase, "for example" or "that is".
Section 2.2.4 'provided-by' element
Lines 471-481:
It may be a good idea to follow this text with a normative directive
to omit the 'method' directive in most cases (a "SHOULD omit"), since
using it when the location has been coarsened can reveal this fact,
and using it only when the location has not been coarsened will also
reveal the coarsening.
Section 4. Securing PIDF
Line 868: i.e. to a Location Recipient
"i.e." should have a comma afterwards: "i.e., to a Location
Recipient". Or spell out: "that is, to a Location Recipient."
Line 878: i.e mail transfer agents
"i.e " should be "i.e.,"
Line 889: decrypted the Location Server
I suggest "decrypted by the Location Server" (or perhaps "decrypted
at the Location Server")
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Sat, 31 Jul 2004 19:15:00 -0700
This archive was generated by hypermail 2.1.8 : Sun Aug 01 2004 - 00:59:25 EDT