| Yes | No
------+-----------------+-----------------
Extend Yes | -local-civic-03 | -local-civic-02
XML? No | *C | *D
Is this a variation on -local-civic-03 we're discussing?
On 2010-12-02 at 10:19:38, Brian Rosen wrote:
> While I consider it part of my life's mission to always do what you
> expect me to do, I don't expect to be recognized for doing it.
>
> I did read the email, and didn't see where "tl;dr" was mentioned,
> whatever "tl" and "dr" mean.
>
> I think we're very close to agreement. We have an open issue on how to
> represent the namespace in DHCP for a local extension, and we have two
> proposals: two DHCP options or one.
>
> If you are okay with the second registry, with it's accompanying CAtype
> and DHCP option, then we should be able to close the one or two DHCP
> options issues with a couple of other people expressing their opinions;
> I certainly don't feel very strongly about that, since the result is
> the same: any local extension can be passed through DHCP.
>
> Since we have mechanisms to pass two new CAtypes with the associated
> registries through DHCP, there is no problem there, and I think we have
> no disagreement (save the one or two registry issue).
>
> LoST validation is also not in play - we understand how to do that with
> any of the proposals on the table.
>
> I had the suggestion to have two generic parameters in the one or two
> CAtypes. You could weigh in on that.
>
> I'm pretty lost, no pun intended, on why the service boundary is any
> issue at all. There are 3 entities, and some can either pass data
> without understanding it, or drop it. If the LoST server gets some LI
> it doesn't understand, it ignores it, which means it doesn't appear in
> a service boundary. If the LoST client got LI elements it didn't
> understand, and passes them through to LoST, it may get that element
> back in the service boundary if the LoST server does understand the
> extension. If the server sends something back, it would have to be the
> value it got sent in. Take bridge: if getting off the bridge is out of
> the service area, then bridge id is part of the service boundary -- the
> client can compare the bridge id it gets from a location update even if
> it doesn't know anything about bridge and requery LoST if it changed.
> If bridge ID is not part of the service boundary, it's not in the
> return and the LoST client won't miss it. I am missing the problem.
> It appears to me to work, and not be dependent on representation.
>
> Brian
>
> On Dec 1, 2010, at 4:52 PM, Thomson, Martin wrote:
>
> > Thank you Brian for doing exactly what I predicted and de-railing the
> conversation onto registries again.
> >
> > 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
