[Geopriv] draft-ietf-geopriv-civic-address-recommendations-00

Hi Karl-Heinz, Alex,

The civic address recommendations document is an excellent reference. It's well written, which I must say is difficult considering how complicated Austrian addresses appear to be.

Two things that I think would greatly help with this document:

1. Discussions of the spectrum of usage models from the most rigorous and formal to informal uses. In general, civic addresses are intended for human consumption, which allows for a fair degree of leniency. Stricter definitions are convenient because they more readily enable machine use. However, without great effort, this tends to lead to the adoptions of codes, inflexible interpretations, validation processes, etc... To my eyes, this document is about strict definitions for formal use, which ultimately will enable things like emergency calling, better dispatch. In this circumstances, there is a real need for unambiguous representations.

On the other hand, I still see a good case for more informal uses of the format. As with other things, it's a matter of degree--I can't see someone passing a PIDF-LO in an IM session, but as a convenient container the PIDF-LO could be used elsewhere. For instance, the place I grew up now has a new official suburb name that no-one except uses unless some damned machine insists that the address doesn't exist.

My suggestion is that you make a note to the effect that this document is about formal uses with the goal of a canonical format for a particular country (noting that this goal may be unrealizable). In making this clear you can also "bless" informal use of the format; that is, make it clear that the formal definition is not intended to constrain the use of the format and that informal uses are permitted.

This extends to the choice of names over codes, and so forth. I have no problem with the country code - such a thing is easily handled because the space is relatively small and static. I'm less enthusiastic about the A1 decision in retrospect, simply because of the way choosing to use codes compromises accessibility in favour of easier machine interpretation. Already the format has too many fields, which is a major usability problem.

2. In a similar vein, it would be useful to provide general guidance on using existing fields for unusual addresses. For instance, it might not be clear to someone that you can use all of the existing fields to adequately describe some quite tricky locations. You mention that some addresses are tricky, but don't provide enough guidance on how to address the problem. Your illustration by example is stronger by far than any text, but text can still help.

A real example that someone presented to me (translated to a place that I'm more familiar with...): Gate 49a, Terminal 4, Los Angeles International Airport. There is a natural tendency to look for <terminal>, <gate> and (to a lesser extent) <airport> elements. However, this could be adequately addressed by using: <BLD>Terminal 4</BLD>, <ROOM>Gate 49a</ROOM> and <NAM>Los Angeles International Airport</NAM>

  (Incidentally, this is a prime example of an opportunity to use informal address: <NAM>LAX</NAM> - to many, the shorter form has greater currency.)

A small note on this would greatly help others. For instance:

  "Civic address fields are designed to be generic containers for similar information. Identifying the correct container for a particular piece of information is a process that can require some approximation. When attempting to fit all aspects of a particular address, finding an approximately appropriate field for each element of the address.

  "For instance, the RD element does not have to be limited to information on roads and streets. People live on a wide range of thoroughfares: this could indicate a waterway like a canal or river, other similar structures like bridges and piers, indoor pedestrian thoroughfares and tunnels. Other elements, such as BLD, ROOM and SEAT can be used to mean a range of things, depending on the particular circumstance.

  "Care should be taken to ensure that conflicts don't occur. It might be necessary to identify the type of the element in the data component to adequately distinguish a canal from a similarly named street. For instance, if you were to choose to identify gates at an airport as ROOMs within a terminal (BLD), the gate might be identified as <ROOM>Gate 49a</ROOM> to avoid a potential conflict with other types of rooms (such as stores, service closets, lounges and so forth...) and to make the special meaning clear to a person that receives the information."

Minor things:

Some examples show things that you prohibit (e.g. Section 5.4.6 shows an example that uses the HNS element). In context, this isn't a problem, but a comment on this line that identifies this as "bad" might be useful:

   <HNO>13</HNO> <HNS>A</HNS> <!-- bad example -->

Use of codes and names. The semi-colon delimiter is good, but I wonder if there needs to be a preference for one over the other. What happens if the two don't match?

Cheers,
Martin
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Received on Fri, 31 Oct 2008 00:15:06 -0500