If you didn't read the email, "tl;dr" is an acceptable response, I wont be offended.
On 2010-12-02 at 00:07:49, Brian Rosen wrote:
> My notion is that you have two registries, the existing one, and one
> that only attempts to avoid duplication. With registries come two
> things: a label and a number.
>
> The label is what you use with LoST. The number is what you use with
> DHCP. If you are worried about running out of DHCP number space,
> create one new number that has the label as it's first parameter.
>
> For the new namespace, LoST works already. Create one new DHCP option
> with the namespace as the first parameter and the label (tag) as the
> second.
>
> Brian
>
> On Nov 30, 2010, at 8:01 PM, Thomson, Martin wrote:
>
> > Robert asked a question about how the various extension scheme affect
> > 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
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
