HTTP-Enabled Location Delivery (HELD)
RFC 5985

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

(Cullen Jennings) Yes

(Robert Sparks) Yes

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Ralph Droms) No Objection

(Lisa Dusseault) No Objection

(Adrian Farrel) No Objection

(Russ Housley) (was Discuss) No Objection

Alexey Melnikov (was Discuss) No Objection

(Tim Polk) (was No Record, Discuss) No Objection

Comment (2009-07-16)
No email
send info
I found the last statement in section 5.1 confusing:

   The LIS MUST ignore any part of a location request message that it
   does not understand, except the document element.

This begs the obvious question, if you don't recognize the document element and
do not ignore it, what do you do?  I eventually sorted it out from the following code
parameter definition in section 6.3:

   unsupportedMessage:  This code indicates that an element in the XML
      document for the request, was not supported or understood by the
      LIS.  This error code is used when a HELD request contains a
      document element that is not supported by the receiver.

I would suggest either covering this case in the first sentence of section 5.3
or adding a note in 5.1 that points to 6.3.

(Dan Romascanu) (was Discuss) No Objection

Comment (2009-07-29 for -)
No email
send info
The document lacks completely any information about how LIS's supporting HELD would be managed. What needs to be configured on a LIS? are there any statistics kept on the number of requests, number of succesful requests, errors, errors distribution, etc. made available to operators that need to include a LIS in his/her network? How can an operator know when a LIS gets near to its capacity and the resulting performance starts to degrade? It would be useful to add a short section to explain these issues, or to refer to other documents that do fill in this task.

Magnus Westerlund No Objection