LoST service boundaries (as opposed to the validation we've already
discussed). I think that this is another consideration we need to deal
with in designing a solution.
Ultimately, questions of the effect of our decisions on other protocols
and users of the civic address format are the most important.
Discussions on registries and associated concerns is - at this stage -
an wasteful distraction.
Service boundary evaluation is a simple process that treats each address
label as opaque (see draft-thomson-ecrit-civic-boundary for a more
thorough discussion). This would make things easy if there were only
one possible way an extension could find its way into the system.
Here are my collected thoughts on the real problem.
--
There are two formats that can be used to introduce an extension: DHCP
and XML.
Those two entry points could lead to an increased number of
representations for extensions.
Most of the problems occur at the point where conversions occur between
formats. If an originator (LG) and ultimate recipient both understand
the extension, conversions between different formats are the only
serious cause of problems.
If all intermediaries understood all extensions, we have no problem.
That's not a reasonable precondition though. We have to deal with
certain intermediaries who are ignorant of extensions.
An extension that finds its way into the system by way of DHCP (or
DHCP-based formats) is going to appear as a new, unknown CAtype to
recipients. This can be translated to an XML format in two ways: when
the translator understands the DHCP form and the equivalent XML form;
and when the translator does not. We need to deal with both cases.
An extension that finds its way into the system by way of an XML format
has a similar problem. The specific qualified name that identifies the
type of the extension can't be carried by DHCP. The same concerns apply
to this sort of conversion.
Though a specific piece of location information might not need to be
converted to DHCP format, it's genesis in XML might ultimately
dictate that DHCP clients be able to convey this to clients for it to
be represented in XML. The idea being that data is forced to go XML
-> DHCP -> XML and the goal is not to lose the extension.
This leads to the following truth table for converting intermediaries:
| Intermediary | Intermediary
| Understands | Ignorant
------------+--------------+--------------
DHCP -> XML | A | B
XML -> DHCP | C | D
Note: Existing software is forced to discard extensions when
translating in either direction. Thus, it's safe to ignore that in
this analysis. I assume that software is compliant with whatever
specification we produce.
-local-civic allows for two expressions of the same data in either basic
format to deal with the problem cases "B" and "D". This does add two
different representations of the same information in both XML and DHCP;
one representation for each of the four cases.
This could cause a problem for LoST service boundaries (or any other
application that uses civic addresses). If a particular extension can
be represented in different ways, the LoST server that relies on an
extension for its boundaries has to produce 2^n different service
boundaries if it wants to be understood (where 2 = the number of
different representations for each extension, and n = the number of
extensions).
In practice, I expect that such reliance on extensions will be rare
for LoST. This problem is rendered moot if the extensions are safely
ignored, but it's something we need to consider for the general case.
If we want to solve the problem of multiple representations - and we
should really evaluate the impact if we do not - then we need to
legislate to remove one of the options. Since we can do nothing to
rectify the ignorance (or not) of translators, the only real option is
to restrict where extensions are defined.
Removing the XML extension point would force all civic address
extensions to acquire a CAtype from the registry. Extensions are only
ever natively defined as one octet CAtypes. To carry extensions in XML,
we'd define an element that can carry unknown CAtypes. <ext:EXT
CAtype="192">Value</ext:EXT> as suggested in -local-civic would be
a representative implementation of this option.
Removing the DHCP extension point was actually something suggested in a
previous version of -local-civic. That got some fairly strong
objections, but it should be tabled again. In this option extensions
are natively defined in XML and we define a way to convey an XML-based
extension in DHCP. The two new CAtypes in -local-civic are
representative implementations of this option.
Thus we have the solution matrix:
Extend DHCP?
| Yes | No
------+-----------------+-----------------
Extend Yes | -local-civic-03 | -local-civic-02
XML? No | *C | *D
*C is what (I think) Brian is advocating (Brian: correct me if I am
wrong, I've heard you support this).
I don't think that anyone is advocating *D, though it's effectively
where we are at the moment.
Keith is partly right about a do-over always being a final failsafe
option: we do always have the option of a complete do-over. However,
the main problem will just carry over into the new format if we don't
resolve it. A do-over is just a decision we might make in the course of
implementing one of these four options.
We should resolve this issue before we get into discussions on
registration policies and so forth. Those discussions are wasteful as
long as we each have different fundamental solutions in mind. I hope
that we can agree that each of these works with wild west, fcfs, expert
review or standards action with similar efficacy, though different
levels of accessibility and interoperability.
--Martin
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
