Only one minor adjustment to your example. I'd suggest that instead of:
urn:service:address-correction, we use, instead,
Other non-emergency use cases exist for similar error corrections in
location, which might be performed by a municipal planning dept.,
location company, etc.
Sounds like a good use (reuse) of the mechanisms we've got.
> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@xxxxxxxxxxxxxxx]
> Sent: Friday, July 06, 2007 2:55 PM
> To: ECRIT
> Subject: [Ecrit] NENA requirement: contact URI for resolving
> errors indatabase
> In going through the NENA i3 requirements, I noticed that
> they require for address validation:
> "If it is determined that an address is invalid, an error
> diagnosis should be supplied if appropriate, as well as a
> contact URI for resolving errors in the database".
> We do the former, but not the latter. One possible solution
> that fits into the generic LoST model is to define a new
> service URN, say urn:service:address-correction, that can be
> resolved if the querier has an interest in doing so. It would
> then yield any number of tel, mailto and http URLs that a
> user could contact to fix problems. This avoids any special
> new protocol constructs.
> Any opinions?
> Ecrit mailing list
The information contained in this message may be privileged and/or
confidential. If you are not the intended recipient, or responsible for
delivering this message to the intended recipient, any review, forwarding,
dissemination, distribution or copying of this communication or any
attachment(s) is strictly prohibited. If you have received this message in
error, please so notify the sender immediately, and delete it and all
attachments from your computer and network.
Ecrit mailing list