A Presence-based GEOPRIV Location Object Format
RFC 4119

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

(Allison Mankin; former steering group member) Yes

Yes ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Ted Hardie; former steering group member) Yes

Yes ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Bert Wijnen; former steering group member) No Objection

No Objection (2004-08-19 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Quite a set of lines occur which are (much) longer than 72 characters

Oterhwise no further objections

(Bill Fenner; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(David Kessens; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Harald Alvestrand; former steering group member) No Objection

No Objection (2004-08-19 for -** No value found for 'p.get_dochistory.rev' **)
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.)

(Jon Peterson; former steering group member) (was Recuse) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Margaret Cullen; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection (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.

(Scott Hollenbeck; former steering group member) (was No Record, Discuss) No Objection

No Objection (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.

(Steven Bellovin; former steering group member) No Objection

No Objection (2004-08-15 for -** No value found for 'p.get_dochistory.rev' **)
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?

(Thomas Narten; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info