[Geopriv] Comments on pidf-lo-02

From: Randall Gellens ^lt;rg+ietf@qualcomm.com>
Date: Sat Jul 31 2004 - 22:15:00 EDT

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

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
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