HTTP-Enabled Location Delivery (HELD)
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
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 -)
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.