Re: [Geopriv] [geopriv] rfc3825bis #39 (new): AD review

On 2010-10-31 at 08:35:57, geopriv issue tracker wrote:
> Conversion to PIDF-LO does not increase uncertainty; conversion
> from
> PIDF-LO to version 1 increases uncertainty by less than a factor of
> 2
> in each dimension. Since it is not possible to translate an
> arbitrary PIDF-LO to version 0 with a bounded increase in
> uncertainty, the conversion to version 0 is not specified. Note
> also
> that in the conversion of version 0 to PIDF-LO it may not always be
> possible to produce a PIDF-LO that captures both the location as
> well
> as the uncertainty region surrounding it.

WFM. In retrospect, the last sentence doesn't make a lot of sense. It could be safely removed.

--Martin

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] [geopriv] rfc3825bis #39 (new): AD review

#39: AD review

Changes (by bernard_aboba@…):

* owner: bernard_aboba@… => martin.thomson@…

Comment:

Here is the complete proposed text for Section 1.2, incorporating Martin's
suggested text as well:

1.2. Resolution and Uncertainty

The DHCP options defined in this document include fields quantifying
the resolution or uncertainty associated with a target location. No
inferences relating to privacy policies can be drawn from either
uncertainty or resolution values.

As utilized in this document, resolution refers to the accuracy of a
reported location, as expressed by the number of valid bits in each
of the Latitude, Longitude and Altitude fields.

In the context of location technology, uncertainty is a
quantification of errors. Any method for determining location is
subject to some sources of error; uncertainty describes the amount of
error that is present. Uncertainty might be the coverage area of a
wireless transmitter, the extent of a building or a single room.

Uncertainty is usually represented as an area within which the target
is located. In this document, each of the three axes can be assigned
an uncertainty value. In effect, this describes a rectangular prism,
which may be used as a coarse representation of a more complex shape
that fits within it. See Section 2.3.2 for more detail on the
correspondence between shapes and uncertainty.

When representing locations from sources that can quantify
uncertainty, the goal is to find the smallest possible rectangular
prism that this format can describe. This is achieved by taking the
minimum and maximum values on each axis and ensuring that the final
encoding covers these points. This increases the region of
uncertainty, but ensures that the region that is described
encompasses the target location.

The DHCPv4 option format defined in this document supports both
resolution and uncertainty parameters. Version 0 of the DHCPv4
option format includes a resolution parameter for each of the
dimensions of location. Since this resolution parameter need not
apply to all dimensions equally, a resolution value is included for
each of the three location elements. Since version 0 of the DHCPv6
option format is not defined, the DHCPv6 option does not support a
resolution parameter. Version 1 of the DHCPv4 and DHCPv6 option
format utilizes an uncertainty parameter. Appendix A describes the
mapping of DHCP option values to GML. Appendix B of this document
provides examples showing the calculation of resolution values.
Appendix C provides an example demonstrating calculation of
uncertainty values.

Since the PIDF-LO format [RFC4119][RFC5491] is used to conveying
location and the associated uncertainty within an emergency call
[Convey], a mechanism is needed to convert the information contained
with the DHCPv4 and DHCPv6 options to PIDF-LO. This document
describes the following conversions:

version 0 to PIDF-LO
version 1 to PIDF-LO
PIDF-LO to version 1

Conversion to PIDF-LO does not increase uncertainty; conversion from
PIDF-LO to version 1 increases uncertainty by less than a factor of 2
in each dimension. Since it is not possible to translate an
arbitrary PIDF-LO to version 0 with a bounded increase in
uncertainty, the conversion to version 0 is not specified. Note also
that in the conversion of version 0 to PIDF-LO it may not always be
possible to produce a PIDF-LO that captures both the location as well
as the uncertainty region surrounding it.

--
---------------------------------------+------------------------------------
Reporter: bernard_aboba@… | Owner: martin.thomson@…
Type: defect | Status: new
Priority: major | Milestone: draft-ietf-geopriv-3825bis
Component: rfc3825bis | Version: 1.0
Severity: Submitted WG Document | Keywords:
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/39#comment:2>
geopriv <http://tools.ietf.org/geopriv/>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] draft-ietf-geopriv-prefix-00 & draft-winterbottom-geopriv-local-civic

Yes, I saw that hack. It's not bad (although including ext:EXT is really ugly), and it would work.

What it doesn't do that I want to get done is changing SEQUENCE, but really I'm trying to point out that trying to keep the original schema inviolate constrains us way too much - we don't know enough about what we are doing to get it right the first time, and limiting us only to things you can do with extension namespaces is not feasible. Never being able to use the defined extensionPoints for example. If we can't use the extensionPoints, why are they there?

I don't want us to make promises we can't keep, and I want to fix things that are broken as early as possible, even if some early implementations have to be modified.

Brian

On Oct 28, 2010, at 5:49 PM, Thomson, Martin wrote:

> On 2010-10-28 at 05:32:29, Brian Rosen wrote:
> [Lots of stuff]
>> Reissue the schemas.
>
> Because a disproportionate response to a small problem is always the best way forward.
>
> Seriously, things just aren't that broken. A little hack and we're home. Read the appendix of the local-civic draft and you'll see that the LoST problem isn't intractable.
>
> --Martin

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] [geopriv] rfc3825bis #39 (new): AD review

#39: AD review

Comment(by bernard_aboba@…):

Hey Bernard,

Don't think this ever got a follow-up. Do you recall the discussion that
Robert is talking about here? It goes back to some intensive discussion
(around the Philadelphia IETF, IIRC) about how the resolution
representation is unsuitable for privacy in part because it represents
some regions so poorly, e.g., those near the equator.

Would you mind drafting some text, or at least proposing some
clarifications to Section 1.2? These don't necessarily need to go into a
new rev right now, since the change is pretty minor, but if you could at
least send out an acknowledgement, that would be helpful.

Thanks,
--Richard

[BA] The NITs have been fixed in my private -13 copy which I'll submit
once the window opens again during IETF week.

I went back to the archives of IETF 71, and reviewed the presentation.

Here is a potential revision to Section 1.2 to address the comments:

1.2. Resolution and Uncertainty

The DHCP options defined in this document include fields quantifying
the resolution or uncertainty associated with a target location. No
inferences relating to privacy policies can be drawn from either
uncertainty or resolution values.

As utilized in this document, resolution refers to the accuracy of a
reported location, as expressed by the number of valid bits in each
of the Latitude, Longitude and Altitude fields.

In the context of location technology, uncertainty is a
quantification of errors. Any method for determining location is
subject to some sources of error; uncertainty describes the amount of
error that is present. Uncertainty might be the coverage area of a
wireless transmitter, the extent of a building or a single room.

Uncertainty is usually represented as an area within which the target
is located. In this document, each of the three axes can be assigned
an uncertainty value. In effect, this describes a rectangular prism,
which may be used as a coarse representation of a more complex shape
that fits within it. See Section 2.3.2 for more detail on the
correspondence between shapes and uncertainty.

When representing locations from sources that can quantify
uncertainty, the goal is to find the smallest possible rectangular
prism that this format can describe. This is achieved by taking the
minimum and maximum values on each axis and ensuring that the final
encoding covers these points. This increases the region of
uncertainty, but ensures that the region that is described
encompasses the target location.

The DHCPv4 option format defined in this document supports both
resolution and uncertainty parameters. Version 0 of the DHCPv4
option format includes a resolution parameter for each of the
dimensions of location. Since this resolution parameter need not
apply to all dimensions equally, a resolution value is included for
each of the three location elements. However, due to the definition
of resolution, using version 0 of the DHCP option format, it may
not be possible to define a PIDF-LO that captures both the
location as well as the uncertainty region surrounding it.

Since version 0 of the DHCPv6 option format is not defined, the
DHCPv6 option does not support a resolution parameter. Version 1
of the DHCPv4 and DHCPv6 option format utilizes an uncertainty
parameter. Using version 1 of the DHCP option format, it is
typically possible to define a PIDF-LO that encloses
the location as well as the uncertainty region surrounding it.

Appendix A describes the mapping of DHCP option values
to GML. Appendix B of this document provides examples showing
the calculation of resolution values. Appendix C provides an
example demonstrating calculation of uncertainty values.

--
---------------------------------------+------------------------------------
Reporter: bernard_aboba@… | Owner: bernard_aboba@…
Type: defect | Status: new
Priority: major | Milestone: draft-ietf-geopriv-3825bis
Component: rfc3825bis | Version: 1.0
Severity: Submitted WG Document | Keywords:
---------------------------------------+------------------------------------

Ticket URL: <https://wiki.tools.ietf.org/wg/geopriv/trac/ticket/39#comment:1>
geopriv <http://tools.ietf.org/geopriv/>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] the Geolocation Policy draft: draft-ietf-geopriv-policy-22.txt

Hi Jorge,

I think that this proposal falls short of what we need. I have one major concern, plus a few relatively minor issues.

Major issues

I see no mention of how to address continuous movement in this algorithm. It would appear that continuous movement could reveal the location of the target with an extremely high degree of accuracy - the same problem that we have had with all previous algorithms. This just has the added virtue of being more complicated (though--to its credit--not significantly).

Minor issues

In general, the algorithm is given with too little explanation about what its goals are and how it seeks to achieve those goals. More specifically:

Grid selection is left to the example, which is not appropriate. Obviously, it doesn't matter as long as an implementation uses the same method each time, but you could say that.

The method used in the example for selecting a grid doesn't offer any guidance on when to switch grids, except to say that it shouldn't be done often. That implies to me that there is a need for hysteresis in the algorithm, which is not ideal.

How does one choose for the 'or' in C2, C4, C5 and C7? I consider this to be almost as important as above. [Please, if we go with this, include a picture of C1-C8. It helps greatly to be able to map this out.]

More explanation on why sqrt(3)/6 [or 1/(2*sqrt(3))] is selected would be nice. On first analysis, 1/2*sqrt(2) [1/sqrt(8)] seems a better fit, since this gives equal areas within the cell. If I consider that the corner regions are joined in groups of four and the "OR" regions are joined in groups of two. 'p' and 'q' were selected so that C2, C4, C5 and C7 have double the area given to the corner regions. That seems logical, but I really don't know what that really buys me other than an elegant tessellation pattern [1]. Nor should I have had to work so hard to reach that conclusion.

This last is a minor fault that I forgot about in my own proposal: Any grid origin is likely at zero longitude. The point that is 180 degrees east or west of that is going to be special. A naïve implementation will reveal - by discontinuity - when someone is crossing the 180th meridian. The problem is not that the algorithm fails to produce a result, it's that the result is bad. This is relatively easy to fix, but it does need an explicit mention so that it doesn't get forgotten.

--Martin

[1] Would a tiler have to use different numbers to ensure that they have enough space for grouting? I think it likely...

On 2010-10-28 at 06:48:03, Jorge Cuellar wrote:
> Hi all,
>
> last week Hannes and I met in Munich to discuss the Geolocation
> Policy draft. We decided to write a text to address the raised
> concerns regarding the location obfuscation algorithm. The
> problem is both when movement occurs and an update of the
> obscured location is necessary, and also when repeatedly the
> same location is visited and different obscured locations are
> provided.
>
> The new draft is:
>
> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-22.txt
>
> The idea of the proposed algorithm is that only a fixed set
> of "cells" are used and the points in those cells are
> indistinguishable. Only one variant of a general type of
> algorithms is presented here, The details of the construction of
> the grids and the calculations are spelled out for the so called
> Mercator "secant projection",
> (http://en.wikipedia.org/wiki/Scale_%28map%29#Secant.2C_or_modified.2C_
> projections).
>
> You might also find the following slide sets interesting:
>
> http://www.tschofenig.priv.at/svn/draft-ietf-geopriv-
> policy/Literature/Privacy%20of%20Location%20Information.ppt
>
> http://www.tschofenig.priv.at/svn/draft-ietf-geopriv-
> policy/Literature/Algo%20for%20Location%20Information-Choices.ppt
>
> Ciao,
> Jorge
> _______________________________________________
> 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

Re: [Geopriv] AD review: draft-ietf-geopriv-rfc3825bis-12

The NITs have been fixed in my private -13 copy which I'll submit once the window opens again during IETF week.

I went back to the archives of IETF 71, and reviewed the presentation. 

Here is a potential revision to Section 1.2 to address the comments:

1.2. Resolution and Uncertainty

   The DHCP options defined in this document include fields quantifying
   the resolution or uncertainty associated with a target location.  No
   inferences relating to privacy policies can be drawn from either
   uncertainty or resolution values.

   As utilized in this document, resolution refers to the accuracy of a
   reported location, as expressed by the number of valid bits in each
   of the Latitude, Longitude and Altitude fields. 

   In the context of location technology, uncertainty is a
   quantification of errors.  Any method for determining location is
   subject to some sources of error; uncertainty describes the amount of
   error that is present.  Uncertainty might be the coverage area of a
   wireless transmitter, the extent of a building or a single room.

   Uncertainty is usually represented as an area within which the target
   is located.  In this document, each of the three axes can be assigned
   an uncertainty value.  In effect, this describes a rectangular prism,
   which may be used as a coarse representation of a more complex shape
   that fits within it.  See Section 2.3.2 for more detail on the
   correspondence between shapes and uncertainty.

   When representing locations from sources that can quantify
   uncertainty, the goal is to find the smallest possible rectangular
   prism that this format can describe.  This is achieved by taking the
   minimum and maximum values on each axis and ensuring that the final
   encoding covers these points.  This increases the region of
   uncertainty, but ensures that the region that is described
   encompasses the target location.

   The DHCPv4 option format defined in this document supports both
   resolution and uncertainty parameters.  Version 0 of the DHCPv4
   option format includes a resolution parameter for each of the
   dimensions of location.  Since this resolution parameter need not
   apply to all dimensions equally, a resolution value is included for
   each of the three location elements. However, due to the definition
   of resolution, using version 0 of the DHCP option format, it may
   not be possible to define a PIDF-LO that captures both the
   location as well as the uncertainty region surrounding it.


   Since version 0 of the DHCPv6 option format is not defined, the
   DHCPv6 option does not support a resolution parameter.  Version 1
   of the DHCPv4 and DHCPv6 option format utilizes an uncertainty
   parameter.  Using version 1 of the DHCP option format, it is
   typically possible to define a PIDF-LO that encloses
   the location as well as the uncertainty region surrounding it.

   Appendix A describes the mapping of DHCP option values
   to GML.  Appendix B of this document provides examples showing
   the calculation of resolution values. Appendix C provides an
   example demonstrating calculation of uncertainty values.

---

From: rbarnes@bbn.com
To: bernard_aboba@hotmail.com
Subject: Fwd: [Geopriv] AD review: draft-ietf-geopriv-rfc3825bis-12
Date: Thu, 28 Oct 2010 18:37:52 -0400

Hey Bernard,

Don't think this ever got a follow-up.  Do you recall the discussion that Robert is talking about here? It goes back to some intensive discussion (around the Philadelphia IETF, IIRC) about how the resolution representation is unsuitable for privacy in part because it represents some regions so poorly, e.g., those near the equator.

Would you mind drafting some text, or at least proposing some clarifications to Section 1.2?  These don't necessarily need to go into a new rev right now, since the change is pretty minor, but if you could at least send out an acknowledgement, that would be helpful.

Thanks,

--Richard

Begin forwarded message:

From: Robert Sparks <rjsparks@nostrum.com>

Date: October 11, 2010 5:16:27 PM EDT

To: GEOPRIV <geopriv@ietf.org>

Cc: draft-ietf-geopriv-rfc3825bis@tools.ietf.org

Subject: [Geopriv] AD review: draft-ietf-geopriv-rfc3825bis-12

Bernard and the chairs tell me that this is ready to go again - I've requested IETF Last Call.

Please consider the following early IETF LC comments:

Comment:

This document doesn't capture the issues with the version 0 DHCPv4 
option that we discussed in Philadelphia.
(See <http://www.ietf.org/proceedings/71/slides/geopriv-2/geopriv-2.htm>). 
It may not need to, since it is not trying to specify using the version 0 
DHCPv4 option to return an area covering another area. However, given the
amount of conversation that went into understanding the limitation, some 
text explaining it seems warranted. It would also help motivate _why_ there
is now a version 1. (That said, there is text in section 1.2 that could
be read to say a version 0 response could cover an arbitrary region to
a desired level of precision - that text should be adjusted to make it
clear that's not what's being claimed).

Nits:

Section 2.4 should call out that it is defining AType values.
In this section (and elsewhere in the document), the older "AT" 
tag in the prose should be changed to use the "AType" tag in the 
new format layout. 

The last equation in section 2.4.5 has x on both sides. I suspect
log2(x) should have been log2(Uncertainty)

Please double-check the XML templates - there are a few spurious semicolons.

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Draft IETF 79 Agenda

On 2010-10-28 at 03:56:28, Alissa Cooper wrote:
> 15m location obfuscation and draft-ietf-geopriv-policy (H. Tschofenig)

This is an important topic for the group.

I know this is a full session, but I would like the opportunity to present the alternative that I have developed. I'll follow-up with a separate analysis of the algorithm described by Hannes and Jorge in the draft.

We should continue the discussion on-list too, 15 minutes wont solve this problem.

--Martin

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] draft-ietf-geopriv-prefix-00 & draft-winterbottom-geopriv-local-civic

On 2010-10-28 at 05:32:29, Brian Rosen wrote:
[Lots of stuff]
> Reissue the schemas.

Because a disproportionate response to a small problem is always the best way forward.

Seriously, things just aren't that broken. A little hack and we're home. Read the appendix of the local-civic draft and you'll see that the LoST problem isn't intractable.

--Martin
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Draft IETF 79 Agenda

I also understand that there is a mailing list that can be used for
these kind of discussions :)

On Oct 28, 2010, at 8:01 AM, Winterbottom, James wrote:

> I think 15 mins is enough to introduce the problem and how this
> draft addresses it. We have virtual interim happen soon after to
> discuss the pros and cons of this solution versus others.
>
> Cheers
> James
>
> ----- Original Message -----
> From: geopriv-bounces@ietf.org <geopriv-bounces@ietf.org>
> To: Alissa Cooper <acooper@cdt.org>; geopriv@ietf.org <geopriv@ietf.org
> >
> Sent: Thu Oct 28 18:48:34 2010
> Subject: Re: [Geopriv] Draft IETF 79 Agenda
>
> I wonder whether 15mins will be enough to discuss the topic. We had
> a punch
> of mails on the subject recently.
>
>
> On 10/27/10 7:56 PM, "Alissa Cooper" <acooper@cdt.org> wrote:
>
>> 15m civic addressing extensions, draft-winterbottom-geopriv-local-
>> civic, draft-ietf-geopriv-prefix, etc. (R. Barnes)
>
> _______________________________________________
> 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

Re: [Geopriv] Draft IETF 79 Agenda

I think 15 mins is enough to introduce the problem and how this draft addresses it. We have virtual interim happen soon after to discuss the pros and cons of this solution versus others.

Cheers
James

----- Original Message -----
From: geopriv-bounces@ietf.org <geopriv-bounces@ietf.org>
To: Alissa Cooper <acooper@cdt.org>; geopriv@ietf.org <geopriv@ietf.org>
Sent: Thu Oct 28 18:48:34 2010
Subject: Re: [Geopriv] Draft IETF 79 Agenda

I wonder whether 15mins will be enough to discuss the topic. We had a punch
of mails on the subject recently.

On 10/27/10 7:56 PM, "Alissa Cooper" <acooper@cdt.org> wrote:

> 15m civic addressing extensions, draft-winterbottom-geopriv-local-
> civic, draft-ietf-geopriv-prefix, etc. (R. Barnes)

_______________________________________________
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

Re: [Geopriv] Draft IETF 79 Agenda

I wonder whether 15mins will be enough to discuss the topic. We had a punch
of mails on the subject recently.

On 10/27/10 7:56 PM, "Alissa Cooper" <acooper@cdt.org> wrote:

> 15m civic addressing extensions, draft-winterbottom-geopriv-local-
> civic, draft-ietf-geopriv-prefix, etc. (R. Barnes)

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] the Geolocation Policy draft: draft-ietf-geopriv-policy-22.txt

Hi all,

last week Hannes and I met in Munich to discuss the Geolocation
Policy draft. We decided to write a text to address the raised
concerns regarding the location obfuscation algorithm. The
problem is both when movement occurs and an update of the
obscured location is necessary, and also when repeatedly the
same location is visited and different obscured locations are
provided.

The new draft is:

http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-22.txt

The idea of the proposed algorithm is that only a fixed set
of "cells" are used and the points in those cells are
indistinguishable. Only one variant of a general type of
algorithms is presented here, The details of the construction of
the grids and the calculations are spelled out for the so called
Mercator "secant projection",
(http://en.wikipedia.org/wiki/Scale_%28map%29#Secant.2C_or_modified.2C_projections).

You might also find the following slide sets interesting:

http://www.tschofenig.priv.at/svn/draft-ietf-geopriv-policy/Literature/Privacy%20of%20Location%20Information.ppt

http://www.tschofenig.priv.at/svn/draft-ietf-geopriv-policy/Literature/Algo%20for%20Location%20Information-Choices.ppt

Ciao,
Jorge
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] draft-ietf-geopriv-prefix-00 & draft-winterbottom-geopriv-local-civic

I think you are correct.

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

[Geopriv] Draft IETF 79 Agenda

A draft agenda for the WG meeting is below. Please send suggested
changes by this Friday, October 29.

Since several WG members will not be present in Beijing, we are hoping
to schedule a virtual interim meeting within two weeks after IETF 79
to discuss civic address extensions. The slot on the agenda below
should serve to tee up that discussion. I will send around a doodle
poll shortly for virtual interim scheduling.

Cheers,
Alissa

INTRO:
5m Chairs intro & administrivia

LIGHTNING TALKS:
5m draft-ietf-sipcore-location-conveyance (J. Polk)
5m draft-ietf-geopriv-relative-location (M. Thomson)

WG DRAFT UPDATES:
15m location obfuscation and draft-ietf-geopriv-policy (H. Tschofenig)
15m draft-ietf-geopriv-deref-protocol (M. Thomson)
15m draft-ietf-geopriv-held-measurements (M. Thomson)

NON-WG DRAFT PRESENTATIONS AND DISCUSSION:
15m civic addressing extensions, draft-winterbottom-geopriv-local-
civic, draft-ietf-geopriv-prefix, etc. (R. Barnes)
15m draft-barnes-geopriv-policy-uri (R. Barnes) -- expect to call for
WG adoption
15m draft-thomson-geopriv-res-gw-lis-discovery (R. Bellis) -- expect
to call for WG adoption
15m draft-hoene-geopriv-bli (C. Hoene)
15m draft-brim-mobility-and-privacy (S. Brim)

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] draft-ietf-geopriv-prefix-00 & draft-winterbottom-geopriv-local-civic

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