A Presence-based GEOPRIV Location Object Format
RFC 4119

Note: This ballot was opened for revision 03 and is now closed.

(Ted Hardie) Yes

(Allison Mankin) Yes

(Harald Alvestrand) No Objection

Comment (2004-08-19 for -)
No email
send info
Reviewed by John Loughney, Gen-ART
IANA considerations section for "method" token should say FCFS explicitly.
Password-based encryption is a MUST, so reference should be normative.
(No opinion stated on whether the WG is right in making passwords MUST and certificates SHOULD - this is a WG decision that I won't second-guess.)

(Steven Bellovin) No Objection

Comment (2004-08-15 for -)
No email
send info
Certificates are a SHOULD; shared secret is a MUST.  Is that compatible with likely deployment patterns?  What about obtaining the other party's certificate?  Is that likely to be an issue here?

(Margaret Cullen) No Objection

(Bill Fenner) No Objection

(Scott Hollenbeck) (was No Record, Discuss) No Objection

Comment (2004-08-12)
No email
send info
For what it's worth, it's not necessary to specify minOccurs="1" and maxOccurs="1" in the element definitions listed in the schemas.  Those are the default values.

(Russ Housley) (was Discuss) No Objection

Comment (2004-08-17)
No email
send info
  It would be nice if the Abstract said what new features are provided
  in the enhanced PDIF.  In short, what was it extended.  I think the
  Introduction tells us, and I think the Abstract should say something
  like: "This document extends the XML-based Presence Information Data
  Format (PIDF) to allow the encapsulation of location information
  within a presence document."

  The document uses "GEOPRIV requirements" and "geopriv requirements."
  Please pick one.

  Does civilLoc A5 also include subdivisions?  Perhaps this is a synonym
  for neighborhood.

  In section 2.2.2, some white space between each field description would
  help the reader.

  In section 4, it should read: "... EnvelopedData and SignedData content
  types, ..."

  Reference [5] should point to RFC 3851.

  Reference [6] should point to RFC 3852.

  Reference [17] should point to RFC 3850, which includes S/MIME-specific
  certificate conventions.  If you also want a more general reference, I
  strongly prefer RFC 3280.

  Appendix seems to be truncated.  It stops in the middle of a sentence.

(David Kessens) No Objection

(Thomas Narten) No Objection

(Jon Peterson) (was Recuse) No Objection

(Bert Wijnen) No Objection

Comment (2004-08-19 for -)
No email
send info
Quite a set of lines occur which are (much) longer than 72 characters

Oterhwise no further objections