I suspect nearly all LoST implementations are wrong.
I believe, as a practical matter, that a LoST server can't be upgraded to validate a new element without an actual implementation change. If you accepted a new namespace, you have new code. You can ignore it ("not checked"), but you can't validate it.
A LoST client can shovel any form of PIDF into a LoST query and report results. Nothing we're doing here would really affect the LoST client itself, but see below.
So the issue is how to extend LoST in a backwards compatible way which would allow us to use the extCAtype and it's local variation.
I note the following: no matter how you look at it you can't extend validation of LoST to cover anything that could occur more than once. The limit on validation is a QName, and that is a simple element name and prefix. That is a very serious limitation. No CAtype that had a parameter and could appear more than once is allowed. This is a limit I noted in 4119 carried over to 5139: the CAtype list is a sequence, and James would have that be inviolate, never able to be changed.
If we take it as an unbreakable rule that the namespace in RFC5222 is inviolate, and we can't replace it with a new one, we would have to create some extension namespace add some additional validation response. Any change like this to LoST has the same problem.
It is untenable, in my opinion, to force us to stay inside this box. This is the basic dilemma that started this discussion. If you consider whatever you want (5139 or 5222) to be the last word, and you assume it can never be changed, only new namespaces can be added, you really get into a very small box. We aren't that good at predicting the future. That is why the current practice is to reissue the schema.
It gets worse.
Suppose we used the existing extensionPoint in the validation response. We could add extValid, extInvalid, extUnchecked to locationValidation. Except we can't. Since we can't issue a new Relax NG schema that replaces the existing one, we can't actually use the extensionPoint, because that would actually add some new element to a defined name in an existing namespace. All the extensionPoints in the schema are useless.
What to do?
Reissue the schemas. Just like the XML directorate advises. They have been through this.
Brian
On Oct 27, 2010, at 11:26 AM, Richard L. Barnes wrote:
> I had a more thorough look at the LoST spec last night, and I think I might understand the confusion. (Summary: The examples are wrong.) I've written a summary below in three acts, plus conclusion. Let me know whether you think this makes sense.
> --Richard
>
>
> I. Mechanism recap
>
> We've been discussing two mechanisms for extending the civic address specification without breaking backward compatibility. In either case, the assumption is that there is a desire to extend the set of "types" allowed in a civic address. Elements with these extended types will still logically have a single value associated with them; complex types are not allowed (except maybe using attributes). Either case can be constrained with IANA registration requirements (either on type tokens or (namespace,token) pairs). The question is then purely one of syntax:
>
> A. Attribute-based extension
> <ext:caElement type="ex1">value1</ext:caElement>
> <ext:caElement type="ex2">value2</ext:caElement>
> <ext:caElement type="ex3">value3</ext:caElement>
>
> B. Namespace-based extension
> <extA:ex1>value1</extA:ex1>
> <extA:ex2>value2</extA:ex2>
> <extB:ex3>value3</extB:ex3>
>
>
> II. LoST Recap
>
> The complexity here is all in terms of LoST location validation. For the purposes of using the 'civic' profile, neither mechanism requires a change to LoST, since the LoST civic profile uses the RFC 5139 schema, which allows for arbitrary extension elements at the end of an address.
>
> Recall that LoST validation works in the following way. The client sets a flag requesting validation, and the server returns a <locationValidation> element indicating which elements of the address are <valid>, <invalid>, or <unchecked>. The question for extension elements is how a LoST server refers to them in these validation elements.
>
> RFC 5222 specifies the <valid>, <invalid>, or <unchecked> elements as lists of "qualified names". Recall that in XML, a qualified name is the combination of a namespace prefix and a local name. This means that the location validation examples in RFC 5222 are incorrect. Instead of this...
>
> <locationValidation>
> <valid>country A1 A3 A6</valid>
> <invalid>PC</invalid>
> <unchecked>HNO</unchecked>
> </locationValidation>
>
> ... the correct version using qualified names would be this:
>
> <locationValidation
> xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
> <valid>ca:country ca:A1 ca:A3 ca:A6</valid>
> <invalid>ca:PC</invalid>
> <unchecked>ca:HNO</unchecked>
> </locationValidation>
>
> So LoST is built to refer to XML elements by their full names, with namespace plus local name.
>
>
> III. LoST deals better with namespace-based extension
>
> The upshot of the above observation about LoST is that LoST can deal with namespace-based extensions to civic addresses with no modification at all. If the civic address in the RFC 5222 example were extended with the following values...
>
> <extA:ex1>value1</extA:ex1>
> <extA:ex2>value2</extA:ex2>
> <extB:ex3>value3</extB:ex3>
>
> ... then the server could indicate validation outcomes with the following response:
>
> <locationValidation
> xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
> xmlns:extA="urn:external:nonexistent-A"
> xmlns:extB="urn:external:nonexistent-B">
> <valid>ca:country ca:A1 ca:A3 ca:A6 extA:ex1</valid>
> <invalid>ca:PC extA:ex2</invalid>
> <unchecked>ca:HNO extB:ex3</unchecked>
> </locationValidation>
>
> With attribute-based extension and the current LoST syntax, the LoST server would only be able to point to the general extension element, not to specific types of extension elements. So LoST would need to be modified to have a mechanism to point to address elements based on attributes instead of qualified names.
>
>
> CONCLUSION: Attribute-based extension and namespace-based extension present the same properties in terms of
> -- their ability to represent address information, and-- the IETF's ability to manage extension via IANA registration
> Attribute-based extension requires modification to the LoST address validation function, however, while namespace-based extension does not.
>
>
>
>
>
>
>
> On Oct 27, 2010, at 10:56 AM, Brian Rosen wrote:
>
>> I'm a bit lost here (no pun), but ISTM, if we used your draft, then you could code a new CAtype with the X and Y codes, and then validation wouldn't work.
>>
>> If we extend LoST so that it would look at priv:caElement names in some reasonable manner, then an unupgraded LoST server would return "not checked", and an upgraded one would return the right thing.
>>
>> Could we concentrate on consensus please, instead of doom and gloom? We do seem to be making progress.
>>
>> Brian
>>
>> On Oct 26, 2010, at 8:50 PM, Winterbottom, James wrote:
>>
>>> Changing the protocols and namespaces of well defined things is a deal breaker for me at this point, and it is a deal breaker for many vendors and standards bodies that have already implemented or profiled against existing specifications.
>>>
>>> It is an industry requirement at this point that the changes don't impact these. You might not like the mechanism in local-civic but it address what the industry requires and still allows the extensions necessary.
>>>
>>> Cheers
>>> James
>>>
>>>
>>>> -----Original Message-----
>>>> From: Brian Rosen [mailto:br@brianrosen.net]
>>>> Sent: Wednesday, 27 October 2010 11:45 AM
>>>> To: Winterbottom, James
>>>> Cc: Richard L. Barnes; geopriv@ietf.org; Thomson, Martin
>>>> Subject: Re: [Geopriv] draft-ietf-geopriv-prefix-00 & draft-winterbottom-
>>>> geopriv-local-civic
>>>>
>>>> I understand this, but I'd rather fix it then use the mechanisms you
>>>> invented. I think the FCFS registry is a good idea.
>>>>
>>>> It's not a deal breaker to me, but we're early enough that I think it's
>>>> worth doing it cleanly.
>>>>
>>>> Brian
>>>>
>>>> On Oct 26, 2010, at 6:49 PM, Winterbottom, James wrote:
>>>>
>>>>> Perhaps I should have clarified, the problem is caused with LoST
>>>> validation.
>>>>> LoST validation elements are returned as qualified names,
>>>> namespace+element or if you have a namespace+prefix defined in the same
>>>> scope then prefix+element. When you introduce a common element name, with
>>>> a "type" to distinguish between the actual elements as 2a is doing, there
>>>> is no way to communicate to the thing requesting validation what actually
>>>> validated and what didn't.
>>>>>
>>>>> This problem doesn't exist with 2b.
>>>>> The appendix in the local-civic draft hacks its way around this problem
>>>> because the CATypeExt namespace is known, I don't think that this hack
>>>> works well/at-all for an arbitrary namespace.
>>>>>
>>>>> Cheers
>>>>> James
>>>>>
>>>>>
>>>>> James Winterbottom
>>>>> Global Product Manager
>>>>> Andrew GeoLENs
>>>>> IP Location Product Portfolio
>>>>> Email: james.winterbottom@andrew.com
>>>>> Phone: +61-2-42-212938
>>>>> Mobile: +61-447-773-560
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Richard L. Barnes [mailto:rbarnes@bbn.com]
>>>>>> Sent: Wednesday, 27 October 2010 9:44 AM
>>>>>> To: Winterbottom, James
>>>>>> Cc: Brian Rosen; geopriv@ietf.org; Thomson, Martin
>>>>>> Subject: Re: [Geopriv] draft-ietf-geopriv-prefix-00 & draft-
>>>> winterbottom-
>>>>>> geopriv-local-civic
>>>>>>
>>>>>> How does 2.a. cause a problem with LoST? Or, is it that 2.a. causes a
>>>>>> problem with LoST while 2.b. doesn't? The only difference is the
>>>>>> number of extension namespaces/schemas.
>>>>>>
>>>>>> --Richard
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Oct 26, 2010, at 6:24 PM, Winterbottom, James wrote:
>>>>>>
>>>>>>> I am not really in favour of type 2a. My rationale being that I
>>>>>>> think that this doesn't fit well with how one would validate it in
>>>>>>> something like LoST in a consistent way. The proposal in the
>>>>>>> appendix of the local-civic draft is a hack, but it works because
>>>>>>> the namespace is known, and so this is blended into the element
>>>>>>> name. 2b works fine, because elements in LoST validation are qnames
>>>>>>> and so are qualified by the namespace or prefix.
>>>>>>>
>>>>>>> Anything you want to do with 2a can be done with 2b, and 2b plays
>>>>>>> nicely with other things.
>>>>>>>
>>>>>>> I think that for 2a to be a serious contender as an option there
>>>>>>> needs to be a strong case made for it and there needs to be a
>>>>>>> consistent way to over come the LoST interaction problem I described.
>>>>>>>
>>>>>>> Cheers
>>>>>>> James
>>>>>>>
>>>>>>>
>>>>>>> James Winterbottom
>>>>>>> Global Product Manager
>>>>>>> Andrew GeoLENs
>>>>>>> IP Location Product Portfolio
>>>>>>> Email: james.winterbottom@andrew.com
>>>>>>> Phone: +61-2-42-212938
>>>>>>> Mobile: +61-447-773-560
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Richard L. Barnes [mailto:rbarnes@bbn.com]
>>>>>>>> Sent: Wednesday, 27 October 2010 9:11 AM
>>>>>>>> To: Brian Rosen
>>>>>>>> Cc: Winterbottom, James; geopriv@ietf.org; Thomson, Martin
>>>>>>>> Subject: Re: [Geopriv] draft-ietf-geopriv-prefix-00 & draft-
>>>>>>>> winterbottom-
>>>>>>>> geopriv-local-civic
>>>>>>>>
>>>>>>>> Ok, good, hope we're converging here. To tighten up the proposal a
>>>>>>>> little:
>>>>>>>>
>>>>>>>> 1. An "official extension" namespace with a single element
>>>>>>>> <ext:caElement type="thing">fnord</ext:caElement>
>>>>>>>> Values for the 'type' attribute MUST be registered in the standard
>>>>>>>> IANA registry. DHCP serialization via standard RFC 4776 use of
>>>>>>>> CAtype
>>>>>>>> numbers.
>>>>>>>>
>>>>>>>> 2.a. A "private extension" namespace with a single element
>>>>>>>> <priv:caElement type="other-thing">fnord</priv:caElement>
>>>>>>>> (This could actually be done in the same namespace as the "official"
>>>>>>>> one). Values for the 'type' attribute SHOULD be registered in a new
>>>>>>>> FCFS registry and MUST NOT be in the "official CAType" registry.
>>>>>>>> DHCP serialization via a new civic address element
>>>>>>>> +-------------+----------+--------+---------+
>>>>>>>> | CAType=PRIV | CALength | CAName | CAValue |
>>>>>>>> +-------------+----------+--------+---------+
>>>>>>>>
>>>>>>>> 2.b. A template for private extensions recommending that they have
>>>>>>>> the
>>>>>>>> same "list of elements" structure
>>>>>>>> <priv:XYZ>fnord</priv:XYZ>
>>>>>>>> (Type values == element names are unconstrained.) DHCP serialization
>>>>>>>> via a new civic address element
>>>>>>>> +-------------+----------+-------------+--------+---------+
>>>>>>>> | CAType=PRIV | CALength | CANamespace | CAName | CAValue |
>>>>>>>> +-------------+----------+-------------+--------+---------+
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Oct 26, 2010, at 5:55 PM, Brian Rosen wrote:
>>>>>>>>
>>>>>>>>> Agree on both points
>>>>>>>>>
>>>>>>>>> We could do something gross like have a FCFS registry for local
>>>>>>>>> CAtypes whose only purpose really is to allow extCAtype to be used
>>>>>>>>> in DHCP and other similar mechanisms, but I think a private
>>>>>>>>> namespace is a cleaner approach.
>>>>>>>>>
>>>>>>>>> Brian
>>>>>>>>> On Oct 26, 2010, at 5:36 PM, Richard L. Barnes wrote:
>>>>>>>>>
>>>>>>>>>> Another wrinkle, just to make sure there's common understanding:
>>>>>>>>>> This approach does *not* prevent people from adding "private"
>>>>>>>>>> extension elements from other namespaces. It just provides a more
>>>>>>>>>> extensible way forward for "official" CAtypes.
>>>>>>>>>>
>>>>>>>>>> It also kind of disclaims any responsibility for what the private
>>>>>>>>>> extensions should look like. I think it might be nice to at least
>>>>>>>>>> make some recommendations about that, e.g., suggesting a CAtype-
>>>>>>>>>> like type/value list or saying something about DHCP serialization.
>>>>>>>>>> (Note, though, that this path kind of leads back toward the -local-
>>>>>>>>>> civic DHCP concepts.)
>>>>>>>>>>
>>>>>>>>>> --Richard
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Oct 26, 2010, at 4:23 PM, Brian Rosen wrote:
>>>>>>>>>>
>>>>>>>>>>> The better part of valor would be to say that we define extCAtype
>>>>>>>>>>> in a new namespace and preserve backwards compatibility.
>>>>>>>>>>>
>>>>>>>>>>> I actually think there are so few deployments that we could redo
>>>>>>>>>>> the schema with a new namespace, which would make it much cleaner
>>>>>>>>>>> for the 99.9999% of implementations that come after the handful
>>>>>>>>>>> that are around now. You are forcing two namespaces where one
>>>>>>>>>>> will do for a very small deployment upgrade.
>>>>>>>>>>>
>>>>>>>>>>> But I'll go with WG consensus on that. The important parts to me
>>>>>>>>>>> are:
>>>>>>>>>>> a) Controlled expansion of the CAtypes registry
>>>>>>>>>>> b) Common use CAtypes are always named, defined, and used
>>>>>>>>>>> consistently
>>>>>>>>>>> c) Limited (1 or 2) namespaces for any global address, with
>>>>>>>>>>> possible per country tweaks as in 5774
>>>>>>>>>>> d) Only one way to encode an extension (from here on in) CAtype,
>>>>>>>>>>> not 3.
>>>>>>>>>>>
>>>>>>>>>>> If I might add a bit of a wrinkle:
>>>>>>>>>>> I'd like to add two generic parameters to extCAtype, so that a new
>>>>>>>>>>> CAtype could be defined that used them.
>>>>>>>>>>> One example of that would be the INT (which had parameters), but
>>>>>>>>>>> there are others.
>>>>>>>>>>>
>>>>>>>>>>> Brian
>>>>>>>>>>>
>>>>>>>>>>> On Oct 26, 2010, at 3:40 PM, Richard L. Barnes wrote:
>>>>>>>>>>>
>>>>>>>>>>>> The appropriate question would seem to be in what namespace this
>>>>>>>>>>>> <extCAtype> element lives. If it's in a new namespace, then
>>>>>>>>>>>> there's no break in backward compatibility. Also, there would be
>>>>>>>>>>>> no need to change LoST, since the LoST civic profile is defined
>>>>>>>>>>>> by reference to RFC 5139, which accommodates additional
>>>>>>>>>>>> namespaces.
>>>>>>>>>>>>
>>>>>>>>>>>> --Richard
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Oct 26, 2010, at 10:46 AM, Brian Rosen wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> If you would please concentrate on what I proposed, we could
>>>>>>>>>>>>> perhaps make some more rapid progress.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I proposed having ONE new element = extensionCAtype, which very
>>>>>>>>>>>>> similar to one part of your proposal.
>>>>>>>>>>>>> <extCAtype "CAname="STP">Avenue</extCAtype>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Endpoints have one (or maybe two) namespaces. We don't have to
>>>>>>>>>>>>> mint new ones for any new extensions.
>>>>>>>>>>>>>
>>>>>>>>>>>>> LoST does need to change, once, but not again, although it's
>>>>>>>>>>>>> backwards compatible with the current extension point. The only
>>>>>>>>>>>>> reason it needs to change is that there are parameters to
>>>>>>>>>>>>> extCAtype. I think your proposal has the same issue.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Endpoints support ONE (or maybe 2) schema(s). If they don't
>>>>>>>>>>>>> understand any given CAtype, they can pass it, or ignore it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> There is ONE way to express any new CA, extCAtype.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Brian
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Oct 25, 2010, at 10:29 PM, Winterbottom, James wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I am sorry, but I don't see any rational argument for not
>>>>>>>>>>>>>> including just the new elements into a new namespace beyond "oh
>>>>>>>>>>>>>> I don't want to have multiple namespace declarations".
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Brian, the impacts we are talking about if we continue with
>>>>>>>>>>>>>> your approach are:
>>>>>>>>>>>>>> 1)No end-point can be sure what namespace received CATypes
>>>>>>>>>>>>>> should be put in to ensure they are understood.
>>>>>>>>>>>>>> 2) LoST will need to change to support another Civic profile
>>>>>>>>>>>>>> 3) All end-points will now need to support multiple civic
>>>>>>>>>>>>>> schemas since they cannot be sure which one they will be given
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And these just what I can think of without spending any time on
>>>>>>>>>>>>>> the problem, yet all this work will need to be done because
>>>>>>>>>>>>>> somebody doesn't want to see extra namespace declarations. I am
>>>>>>>>>>>>>> sorry but I don't think that this is reasonable, and it leaves
>>>>>>>>>>>>>> problems that I don't believe can be solved, without
>>>>>>>>>>>>>> significant work by vendors.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Cheers
>>>>>>>>>>>>>> James
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> James Winterbottom
>>>>>>>>>>>>>> Global Product Manager
>>>>>>>>>>>>>> Andrew GeoLENs
>>>>>>>>>>>>>> IP Location Product Portfolio
>>>>>>>>>>>>>> Email: james.winterbottom@andrew.com
>>>>>>>>>>>>>> Phone: +61-2-42-212938
>>>>>>>>>>>>>> Mobile: +61-447-773-560
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>> From: geopriv-bounces@ietf.org [mailto:geopriv-
>>>>>>>>>>>>>>> bounces@ietf.org] On Behalf
>>>>>>>>>>>>>>> Of Brian Rosen
>>>>>>>>>>>>>>> Sent: Tuesday, 26 October 2010 11:04 AM
>>>>>>>>>>>>>>> To: Thomson, Martin
>>>>>>>>>>>>>>> Cc: geopriv@ietf.org
>>>>>>>>>>>>>>> Subject: Re: [Geopriv] draft-ietf-geopriv-prefix-00 & draft-
>>>>>>>>>>>>>>> winterbottom-
>>>>>>>>>>>>>>> geopriv-local-civic
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> While I am happy to hear that deployments of 5139 exist, we
>>>>>>>>>>>>>>> live in a
>>>>>>>>>>>>>>> world were it's upgrade or die.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Nevertheless, as I said, I would like a better way.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I agree that people will extend. I am not advocating
>>>>>>>>>>>>>>> eliminating the
>>>>>>>>>>>>>>> possibility of a "private" namespace. However, I believe it
>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>> appropriate that IETF control "official" extensions that have
>>>>>>>>>>>>>>> broad
>>>>>>>>>>>>>>> applicability. Prefix is one such extension. "relative-
>>>>>>>>>>>>>>> location" is
>>>>>>>>>>>>>>> another. Adding new "official" CAtypes should be possible,
>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>> appropriate review.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I understand that to correctly parse an address into fields,
>>>>>>>>>>>>>>> or to render
>>>>>>>>>>>>>>> fields into human readable text, requires a per-country
>>>>>>>>>>>>>>> document, which
>>>>>>>>>>>>>>> means per-country code. It's unavoidable. However, we saw
>>>>>>>>>>>>>>> value in
>>>>>>>>>>>>>>> creating a list of common elements that many countries used in
>>>>>>>>>>>>>>> their
>>>>>>>>>>>>>>> addresses. I believe that remains a value, and it would be
>>>>>>>>>>>>>>> most
>>>>>>>>>>>>>>> unfortunate to have "Street Prefix" in one and
>>>>>>>>>>>>>>> "ThoroughfareType-Pre" in
>>>>>>>>>>>>>>> another that was exactly the same thing, used the same way as
>>>>>>>>>>>>>>> "STS" but
>>>>>>>>>>>>>>> before the street name. That is the value in having a formal
>>>>>>>>>>>>>>> extension
>>>>>>>>>>>>>>> path for CAtypes.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If we agree on that, then we need a way to create the XML. I
>>>>>>>>>>>>>>> really
>>>>>>>>>>>>>>> dislike 3 ways to do the same thing. Having a generic
>>>>>>>>>>>>>>> extension gives us
>>>>>>>>>>>>>>> one way to have an extended CAtype, rather than 3. It avoids
>>>>>>>>>>>>>>> adding a
>>>>>>>>>>>>>>> slew of namespaces. It continues the use of the CAtype
>>>>>>>>>>>>>>> registry, with its
>>>>>>>>>>>>>>> current policy for adding CAtypes. Given the example in 5774,
>>>>>>>>>>>>>>> that's
>>>>>>>>>>>>>>> really all we need.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Private extensions can use their own namespace, as they can
>>>>>>>>>>>>>>> now.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Brian
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Oct 25, 2010, at 7:10 PM, Thomson, Martin wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi Brian,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I agree with Hannes. Backwards compatibility is more
>>>>>>>>>>>>>>>> important than you
>>>>>>>>>>>>>>> seem to think.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 2010-10-26 at 01:46:17, Brian Rosen wrote:
>>>>>>>>>>>>>>>>> Is there really a good reason why 5139 can create a new
>>>>>>>>>>>>>>>>> namespace that
>>>>>>>>>>>>>>>>> effectively obsoletes the one in 4119, but -prefix cannot?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yes, there are two very good reasons.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Use: Actual use of 4119 was rare to non-existent. 5139 is in
>>>>>>>>>>>>>>>> use.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Language: There was no allowance for language tags in 4119 -
>>>>>>>>>>>>>>>> something
>>>>>>>>>>>>>>> that I'm sure you'll agree is handy. Adding language tags in
>>>>>>>>>>>>>>> any other
>>>>>>>>>>>>>>> way would have been extremely difficult.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It has always been possible to add a namespace and add
>>>>>>>>>>>>>>>>> elements to a
>>>>>>>>>>>>>>>>> PIDF. The obvious problem is that anyone could declare
>>>>>>>>>>>>>>>>> such a
>>>>>>>>>>>>>>>>> namespace, and then expect the rest of the world to generate
>>>>>>>>>>>>>>>>> PIDFs with
>>>>>>>>>>>>>>>>> their namespace. This leads to non-interoperability, a
>>>>>>>>>>>>>>>>> point made in
>>>>>>>>>>>>>>>>> the comments on earlier versions of -local-civic.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> There's a definite parallel on the apps-discuss list
>>>>>>>>>>>>>>>> regarding
>>>>>>>>>>>>>>> extensions in the discussions on X-. The basic rule is that
>>>>>>>>>>>>>>> people will
>>>>>>>>>>>>>>> extend. When they do so, they don't necessarily seek
>>>>>>>>>>>>>>> interoperability.
>>>>>>>>>>>>>>> That comes later as the extension is seen to be useful.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> We need to provide a path toward interoperability. -local-
>>>>>>>>>>>>>>>> civic
>>>>>>>>>>>>>>> describes how that works. "Interoperability or bust" is not a
>>>>>>>>>>>>>>> sentiment
>>>>>>>>>>>>>>> that I would like to have conveyed.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The current accepted IETF practice in this kind of
>>>>>>>>>>>>>>>>> situation is to in fact issue a new namespace, which we all
>>>>>>>>>>>>>>>>> agree is
>>>>>>>>>>>>>>>>> not very good.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> [citation required]
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Extensions go in new namespaces: yes. Extensions replace the
>>>>>>>>>>>>>>>> original
>>>>>>>>>>>>>>> namespace: not from what I've seen.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'm not sure if I think this is very good or not. It's just
>>>>>>>>>>>>>>>> how things
>>>>>>>>>>>>>>> are: a trade-off between competing considerations.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I think we will discover, from time to time, that new
>>>>>>>>>>>>>>>>> CAtypes, which
>>>>>>>>>>>>>>>>> have relatively broad applicability, are needed. What we're
>>>>>>>>>>>>>>>>> searching
>>>>>>>>>>>>>>>>> for is a way to add them without breaking backwards
>>>>>>>>>>>>>>>>> compatibility.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Precisely. This is why my mind boggles when you recommend
>>>>>>>>>>>>>>>> that we break
>>>>>>>>>>>>>>> backward compatibility.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --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
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>
>>
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
