Re: [Geopriv] AD Review: draft-ietf-geopriv-held-identity-extensions-04

On 2010-09-29 at 04:26:30, Robert Sparks wrote:
> Summary: This draft is ready for IETF LC - I'll be requesting that LC
> shortly.
>
> Please consider the following as early LC comments:
>
> The last sentence of (1.1 Applications) is a bare assertion.
> Can you add text or point to more discussion?

Good point. Would this help?

Section 1.1 (last paragraph), ADD:
For instance, a policy rules document could be used to express the agreed policy. Formal policy documents, such as [RFC4745], can be applied in an automated fashion by a LIS.

> The first sentence of the third paragraph of section 2.1
> (Starting "The identifiers described") is very hard to parse.
> Could it be simplified to "The identifiers described in this
> document MUST only be used as inputs for location determination."?
> Can you call out some example applications where it is not ok
> to use these identifiers (helping to motivate the MUST).

That text sounds OK. Actually, since this is just a (poor) paraphrase of RFC 5687, maybe we could instead lift that text:

The LIS MUST be able to use the identifier [...] for location determination.

Would this plagiarism work for you?

> In section 3.5's discussion about ensuring a URI refers to a single
> device, please consider pointing to GRUU.

It was always the intent to use GRUU :)

Section 3.5, OLD:
... For example, a SIP address of record URI can
correspond to a service subscription rather than a single Device.
NEW:
... For example, a SIP address of record URI can
correspond to a service subscription rather than a single Device;
a Globally Routable User Agent URI (GRUU) [RFC5627] might be more
appropriate.

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

Re: [Geopriv] Fwd: I-D Action:draft-ietf-geopriv-deref-protocol-01.txt

On 2010-09-29 at 14:42:13, Richard L. Barnes wrote:
> Supporting GET is a good idea. It makes the simple case simpler.

Very simple :)

> One minor comment: Given that one reason for supporting GET is
> generic, non-HELD/PIDF-aware clients, doesn't it seem a little odd
> that the GET example includes:
> Accept: application/pidf+xml,application/held+xml;q=0.5
>
> It might be a little more realistic to use something like a typical
> XHR Accept line:
> Accept: application/xml,text/xml;q=0.5,*;q=0.1
>

I do take the comment for the first example GET request - that's definitely worth updating to include a typical Accept header.

But not the second one. If you want this sort of behaviour, you have to know what you are getting. That means that this isn't a HELD- and PIDF-aware client.

The typical Accept here isn't much use in selecting one document type over another. Both fall types under '*;q=0.1'. The typical request doesn't express a useful preference.

The other thing to consider here is how this unaware client might become aware. They do this by triggering a useful default response. If that isn't a location response, they never get the opportunity to learn that HELD works here.

--Martin

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

Re: [Geopriv] Fwd: I-D Action:draft-ietf-geopriv-deref-protocol-01.txt

Supporting GET is a good idea. It makes the simple case simpler.

One minor comment: Given that one reason for supporting GET is
generic, non-HELD/PIDF-aware clients, doesn't it seem a little odd
that the GET example includes:
Accept: application/pidf+xml,application/held+xml;q=0.5

It might be a little more realistic to use something like a typical
XHR Accept line:
Accept: application/xml,text/xml;q=0.5,*;q=0.1

On Sep 29, 2010, at 12:28 AM, Thomson, Martin wrote:

> I've made this update to include the changes discussed at IETF-78.
>
> The document now describes what an HTTP GET request means.
>
> Diff here:
> <http://tools.ietf.org/rfcdiff?url2=draft-ietf-geopriv-deref-protocol-01.txt
> >
>
> On 2010-09-29 at 12:15:01, Internet-Drafts@ietf.org wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Geographic Location/Privacy Working
>> Group of the IETF.
>>
>>
>> Title : A Location Dereferencing Protocol Using HELD
>> Author(s) : J. Winterbottom, et al.
>> Filename : draft-ietf-geopriv-deref-protocol-01.txt
>> Pages : 23
>> Date : 2010-09-28
>>
>> This document describes how to use the Hypertext Transfer Protocol
>> (HTTP) over Transport Layer Security (TLS) as a dereferencing
>> protocol to resolve a reference to a Presence Information Data Format
>> Location Object (PIDF-LO). The document assumes that a Location
>> Recipient possesses a secure HELD URI that can be used in conjunction
>> with the HELD protocol to request the location of the Target.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-deref-
>> protocol-
>> 01.txt
> _______________________________________________
> 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] Fwd: I-D Action:draft-ietf-geopriv-deref-protocol-01.txt

I've made this update to include the changes discussed at IETF-78.

The document now describes what an HTTP GET request means.

Diff here:
<http://tools.ietf.org/rfcdiff?url2=draft-ietf-geopriv-deref-protocol-01.txt>

On 2010-09-29 at 12:15:01, Internet-Drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Geographic Location/Privacy Working
> Group of the IETF.
>
>
> Title : A Location Dereferencing Protocol Using HELD
> Author(s) : J. Winterbottom, et al.
> Filename : draft-ietf-geopriv-deref-protocol-01.txt
> Pages : 23
> Date : 2010-09-28
>
> This document describes how to use the Hypertext Transfer Protocol
> (HTTP) over Transport Layer Security (TLS) as a dereferencing
> protocol to resolve a reference to a Presence Information Data Format
> Location Object (PIDF-LO). The document assumes that a Location
> Recipient possesses a secure HELD URI that can be used in conjunction
> with the HELD protocol to request the location of the Target.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-deref-protocol-
> 01.txt
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] I-D Action:draft-ietf-geopriv-deref-protocol-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Geographic Location/Privacy Working Group of the IETF.

Title : A Location Dereferencing Protocol Using HELD
Author(s) : J. Winterbottom, et al.
Filename : draft-ietf-geopriv-deref-protocol-01.txt
Pages : 23
Date : 2010-09-28

This document describes how to use the Hypertext Transfer Protocol
(HTTP) over Transport Layer Security (TLS) as a dereferencing
protocol to resolve a reference to a Presence Information Data Format
Location Object (PIDF-LO). The document assumes that a Location
Recipient possesses a secure HELD URI that can be used in conjunction
with the HELD protocol to request the location of the Target.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-deref-protocol-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Re: [Geopriv] [geopriv] #39: AD review

Maybe this could help:

This document describes conversions for 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. However, it is not possible to translate an arbitrary PIDF-LO to version 0 with a bounded increase in uncertainty, thus the conversion to version 0 is not specified.

Alissa picked up the last nit a while back - but it must have been missed :)

--Martin

-----Original Message-----
From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of geopriv issue tracker
Sent: Wednesday, 29 September 2010 10:55 AM
To: bernard_aboba@hotmail.com
Cc: geopriv@ietf.org
Subject: [Geopriv] [geopriv] #39: AD review

#39: AD review
---------------------------------------+------------------------------------
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:
---------------------------------------+------------------------------------
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)

--
Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/39>
geopriv <http://tools.ietf.org/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] [geopriv] #39: AD review

#39: AD review
---------------------------------------+------------------------------------
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:
---------------------------------------+------------------------------------
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)

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

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

[Geopriv] Last Call: (Use of Device Identity in HTTP-Enabled Location Delivery (HELD)) to Proposed Standard

The IESG has received a request from the Geographic Location/Privacy WG
(geopriv) to consider the following document:
- 'Use of Device Identity in HTTP-Enabled Location Delivery (HELD)'
<draft-ietf-geopriv-held-identity-extensions-04.txt> as a Proposed
Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2010-10-12. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-geopriv-held-identity-extensions/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-geopriv-held-identity-extensions/

No IPR declarations were found that appear related to this I-D.
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] AD Review: draft-ietf-geopriv-held-identity-extensions-04

Summary: This draft is ready for IETF LC - I'll be requesting that LC shortly.

Please consider the following as early LC comments:

The last sentence of (1.1 Applications) is a bare assertion.
Can you add text or point to more discussion?

The first sentence of the third paragraph of section 2.1
(Starting "The identifiers described") is very hard to parse.
Could it be simplified to "The identifiers described in this
document MUST only be used as inputs for location determination."?
Can you call out some example applications where it is not ok
to use these identifiers (helping to motivate the MUST).

In section 3.5's discussion about ensuring a URI refers to a single
device, please consider pointing to GRUU.

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

Re: [Ecrit] [Geopriv] FCC NoI regarding IP 9-1-1

Richard,
do you know if there's an updated URL at the FCC, as this
link is no longer valid.

Kind regards

Stephen

On 27 September 2010 17:30, Richard L. Barnes <rbarnes@bbn.com> wrote:
> Not directly GEOPRIV-related, but probably of interest to some:
>
> FCC released a Notice of Inquiry last week seeking comment on emergency
> services for IP-enabled providers, including some questions about how
> location information should work in these cases.  Comment period is 30 days.
>
> <http://www.fcc.gov/Daily_Releases/Daily_Business/2010/db0924/FCC-10-177A1.pdf>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
>
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

[Geopriv] FCC NoI regarding IP 9-1-1

Not directly GEOPRIV-related, but probably of interest to some:

FCC released a Notice of Inquiry last week seeking comment on
emergency services for IP-enabled providers, including some questions
about how location information should work in these cases. Comment
period is 30 days.

<http://www.fcc.gov/Daily_Releases/Daily_Business/2010/db0924/FCC-10-177A1.pdf
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] Fwd: Internet Privacy Workshop: 8 and 9 December 2010

Hi all,

I am sure that folks on this list have an opinion about privacy. Please consider participating.

Ciao
Hannes

Begin forwarded message:

> From: IETF Secretariat <ietf-secretariat@ietf.org>
> Date: September 21, 2010 12:00:02 AM GMT+03:00
> To: ietf-announce@ietf.org
> Subject: Internet Privacy Workshop: 8 and 9 December 2010
>
> The Internet Architecture Board (IAB), World Wide Web Consortium (W3C),
> Internet Society (ISOC) and Massachusetts Institute of Technology (MIT)
> will hold a joint Internet privacy workshop on 8 and 9 December 2010 at
> MIT, Cambridge, Massachusetts on the question:
>
> "How Can Technology Help to Improve Privacy on the Internet?"
>
> Information about who we are, what we own, what we have experienced, how
> we behave, where we are located, and how we can be reached are among the
> most personal pieces of information about us. This information is
> increasingly being made more easily available electronically via the
> Internet, often without the consent of the subject.
>
> The question for the workshop therefore is: How can we ensure that
> architectures and technologies for the Internet, including the World
> Wide Web, are developed in ways that respects users‚ intentions about
> their privacy?
>
> This workshop aims to explore the experience and approaches taken by
> developers of Internet including Web technology, when designing privacy
> into these protocols and architectures. Engineers know that many design
> considerations need to be taken into account when developing solutions.
> Balancing between the conflicting goals of openness, privacy, economics,
> and security is often difficult, as illustrated by Clark, et al. in
> "Tussle in Cyberspace: Defining Tomorrow's Internet", see
> http://groups.csail.mit.edu/ana/Publications/PubPDFs/Tussle2002.pdf
>
> As a member of the technical community, we invite you to share your
> experiences by participating in this important workshop. Workshop
> participants will focus on the core privacy challenges, the approaches
> taken to deal with them, and the status of the work in the field. The
> objective is to draw a relationship with other application areas and
> other privacy work in an effort to discuss how specific approaches can
> be generalized.
>
> Interested parties must submit a brief contribution describing their
> work or approach as it relates to the workshop theme. We welcome
> visionary ideas for how to tackle Internet privacy problems, as well as
> write-ups of existing concepts, deployed technologies, and
> lessons-learned from successful or failed attempts at deploying privacy
> technologies. Contributions are not required to be original in content.
>
> Submitters of accepted position papers will be invited to the workshop.
> The workshop will be structured as a series of working sessions,
> punctuated by invited speakers, who will present relevant background
> information or controversial ideas that will motivate participants to
> reach a deeper understanding of the subject. The organizing committee
> may ask submitters of particularly topical papers to present their ideas
> and experiences to the workshop.
>
> We will publish submitted position papers and slides together with a
> summary report of the workshop.
>
> There are no plans for any remote participation in this workshop.
>
> To be invited to the workshop, please submit position papers to
> privacy@iab.org by November, 5th 2010.
>
> More detailed information about the workshop, including further details
> about the position paper requirements, is available at:
> http://www.iab.org/about/workshops/privacy/
>
> We look forward to your input,
> Bernard Aboba (IAB), Trent Adams (ISOC), Daniel Appelquist (W3C), Karen
> O'Donoghue (ISOC), Jon Peterson (IAB), Thomas Roessler (W3C), Karen
> Sollins (MIT), Hannes Tschofenig (IAB)
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce

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

[Geopriv] NomCom 2010-2011: Call for More Nominations

FYI. Please consider submitting nominations for the open slots in the
IAB, IESG, and IAOC.

Begin forwarded message:

> From: NomCom Chair <nomcom-chair@ietf.org>
> Date: September 17, 2010 12:26:02 AM BST
> To: IETF Announcement list <ietf-announce@ietf.org>
> Subject: NomCom 2010-2011: Call for More Nominations
>
>
>
> Hi Folks,
>
> Nominations have slowed down dramatically, so this update is to enlist
> the community in an effort to pick up the pace.
>
> We are very far behind in nominations for all the open positions but
> in
> particular we need nominations for the IESG and IAOC open positions.
> There have been no nominations received (other than for the
> incumbents)
> in INT, RAI, and RTG, and only 1 for OPS. Likewise, in IAOC there
> have
> been no nominations submitted other than the incumbent.
>
> The acceptance rates of those nominated has also been very slow. In
> order to initiate the open list of willing nominees we are in need
> of a
> reasonable number of acceptances, and due to the low number of
> nominees
> and acceptances have delayed the start date for publishing the first
> open list to September 20. So if you have been nominated and are
> willing to serve, but have not yet confirmed this by email back to the
> NomCom, please do so as soon as possible.
>
> We need Community input and participation! We cannot properly execute
> the task of selecting the best candidates for these positions with so
> few nominations and acceptances. So, please consider making
> nominations for the open positions, in particular those for which we
> have so few nominations – it takes just a few minutes of your time.
> Right now, we just need the names/email addresses.
>
> Why do we need more nominations? Well, even if you think a willing
> incumbent is doing a very good job and should be returned, his or her
> ability to serve again might be impacted by unforeseen circumstances
> between now and March. NomCom needs to consider multiple nominees to
> be
> prepared in the event one or more candidates is unable to serve come
> next
> March and to ensure we have chosen the best candidate.
>
> There are several ways you can help the IETF Nominating Committee.
>
> - You may nominate yourself.
> - You can nominate someone you know whom you think would do a good
> job.
>
> Do not worry about whether they might already be nominated. We would
> much prefer to receive the same nomination several times rather than
> miss a good person we should consider.
>
> How to submit Nominations:
> --------------------------
> The list of positions we need to fill, and the provided Job
> Descriptions, and forms for nominations, can be found in the call for
> nominations at: https://datatracker.ietf.org/ann/nomcom/2468/
>
> You may enter a nomination by going to the following URL
> https://wiki.tools.ietf.org/group/nomcom/10/nominate
>
> You may also nominate someone by sending an email to nomcom10@ietf.org
> and giving us their name, email address and the open position you are
> nominating them for. We will take care of the rest.
>
> If you are asked for a user name and password, use an existing ietf
> login
> and password. If you need a login and password, request one from the
> tools
> page at the following URL http://trac.tools.ietf.org/newlogin
>
>
> Open List:
> ----------
> As you already know, NomCom 2010-2011 will follow the policy for "Open
> Disclosure of Willing Nominees" described in RFC 5680.
>
> Feedback Collection:
> --------------------
> Once the open list is available, the entire community will be invited
> to provide feedback. I will send a further announcement requesting
> feedback on the nominees, describing how to submit feedback, and how
> to
> view the open list of nominees.
>
> Thank you,
>
> Thomas Walsh
> Chair, NomCom 2010-2011
> nomcom-chair@ietf.org
> twalsh@juniper.net
>
>
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce

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

Re: [Geopriv] Format of SSID in held-measurements-01.txt

Martin,

On Sep 15, 2010, at 9:28 PM, Thomson, Martin wrote:
> The joy of writing a specification is that you don't have to specify what algorithm is used. Either algorithm would only be an example - you can use the more conservative algorithm, I can choose to provide a more complicated algorithm :)
>
> Taking "Wêïrd\5cNàmé" you get [0x57, 0xC3, 0xAA, 0xC3, 0xAF, 0x72, 0x64, 0x4E, 0xC3, 0xA0, 0x6D, 0xC3, 0xA9]. You could just as easily go with "W\c3\aa\c3\afrd\5cN\c3\a0m\c3\a9"; or even "\57\c3\aa\c3\af\72\64\4e\c3\a0\6d\c3\a9". They all end up producing the same value. Certainly, the latter two choices are easier to write code for.
>
> This is what I intend to add:
>
> An SSID is a sequence of up to 32 octets. SSIDs are typically presented as strings, which are converted to an octet sequence using either ASCII or UTF-8 encoding. The "ssid" element is provided as a string that is converted to octets by UTF-8 encoding the string. Octet values can be expressed directly using a backslash ('\') followed by two hexadecimal digits.
>
> The value of an SSID is the sequence of octets that
> is produced from the concatenation of UTF-8 encoded sequences of
> unescaped characters and octets derived from escaped components.

I think there might be a problem in the revised definition. What if you have 32 ê values, which you encoded with the two octets \c3\aa? Per your pattern, that is legal but it's 64 octets. Perhaps we can get out of it with a statement in the text rather than trying to fix the pattern to be exact (a solution I don't prefer but it's manageable)?

Also I'd note in the text that 0 byte characters are legal in a SSID.

>
> The XML will change to have a constraint:
>
> <xs:pattern value="([^\\]|\\[\da-fA-F]{2}){1,32}"/>

The SSID can be zero bytes, so the pattern (before fixing the above problem) would be:
<xs:pattern value="([^\\]|\\[\da-fA-F]{2}){0,32}"/>

--
David Waitzman
BBN Technologies
djw@bbn.com 410-290-6160

Re: [Geopriv] Format of SSID in held-measurements-01.txt

> > <ssid>Wêird\5cNàmé</ssid>
>
> But there's a need to be defensive about illegal UTF-8 sequences,
> including 0 byte values.
> See rfc3629.txt section 6 and also
> http://etutorials.org/Programming/secure+programming/Chapter+3.+Input+V
> alidation/3.12+Detecting+Illegal+UTF-8+Characters/
>
> I suggest a more defensive algorithm: anything not printable ASCII gets
> hex encoded. That won't handle Wêird\5cNàmé but it will handle
> ManufacturerName and \20\00\ff\fbUgly\00\00\00.

The joy of writing a specification is that you don't have to specify what algorithm is used. Either algorithm would only be an example - you can use the more conservative algorithm, I can choose to provide a more complicated algorithm :)

Taking "Wêïrd\5cNàmé" you get [0x57, 0xC3, 0xAA, 0xC3, 0xAF, 0x72, 0x64, 0x4E, 0xC3, 0xA0, 0x6D, 0xC3, 0xA9]. You could just as easily go with "W\c3\aa\c3\afrd\5cN\c3\a0m\c3\a9"; or even "\57\c3\aa\c3\af\72\64\4e\c3\a0\6d\c3\a9". They all end up producing the same value. Certainly, the latter two choices are easier to write code for.

This is what I intend to add:

An SSID is a sequence of up to 32 octets. SSIDs are typically presented as strings, which are converted to an octet sequence using either ASCII or UTF-8 encoding. The "ssid" element is provided as a string that is converted to octets by UTF-8 encoding the string. Octet values can be expressed directly using a backslash ('\') followed by two hexadecimal digits.

The value of an SSID is the sequence of octets that
is produced from the concatenation of UTF-8 encoded sequences of
unescaped characters and octets derived from escaped components.

The XML will change to have a constraint:

<xs:pattern value="([^\\]|\\[\da-fA-F]{2}){1,32}"/>

--Martin

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

Re: [Geopriv] Format of SSID in held-measurements-01.txt

Martin,

On Sep 15, 2010, at 12:52 AM, Thomson, Martin wrote:
> David Waitzman writes:
>> As I expressed in my first message, users don't normally look at raw
>> XML contents:
>
> This is an interesting argument, and one that I've seen used quite frequently (I've used it myself on occasion).
>
> When applied to the general question of text-vs-binary protocols, the answer tends to be entirely subjective. Taken to its extreme, you end up with ASN.1+PER or similar solutions.
>
> I favour the protocol being usable in the default case. Even if that sort of usage seems unlikely, it's been hugely beneficial in debugging thus far.

I appreciate your argument: I used to be able to read parts of hex dumps of ASN.1 BER-encoded data from SNMP. I cede the point that having human readability can help.

>> Your suggestion in msg08717.html of: [...]
>>>>> octetsAsString = *(vcharx / escaped)
>>>>> vcharx = %x21-5b / %x5d-7e ; VCHAR minus backslash
>>>>> escaped = %x5c 2HEXDIG
>>
>> doesn't handle the UTF-8 encoding cases well.
>
> LDAP solves this by adding UTFMB, a pattern that allows for multi-byte UTF-8 sequences:
> octetsAsString = *(vcharx / escapted / UTFMB)
>
> In XML, the easiest solution is slightly different, and even quite simple:
> ([^\\]|\\[0-9a-fA-F]{2})*
>
> That is, everything other than backslash, or backslash plus two hex characters. To convert from a raw token value to a sequence of octets, UTF-8 encode all characters except backslash, then replace all backslash-escaped sequences with a single octet. In reverse, decode UTF-8 and backslash-escape anything that doesn't decode, plus backslash.
>
> The benefits are clear enough:
>
> <ssid>ManufacturerName</ssid>
>
> ...as opposed to:
>
> <ssid>4d616e7566616374757265724e616d65</ssid>
>
> ...with the occasional:
>
> <ssid>Wêird\5cNàmé</ssid>

But there's a need to be defensive about illegal UTF-8 sequences, including 0 byte values.
See rfc3629.txt section 6 and also http://etutorials.org/Programming/secure+programming/Chapter+3.+Input+Validation/3.12+Detecting+Illegal+UTF-8+Characters/

I suggest a more defensive algorithm: anything not printable ASCII gets hex encoded. That won't handle Wêird\5cNàmé but it will handle ManufacturerName and \20\00\ff\fbUgly\00\00\00.

--
David Waitzman
BBN Technologies
djw@bbn.com 410-290-6160

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

[Geopriv] [Editorial Errata Reported] RFC5986 (2522)

The following errata report has been submitted for RFC5986,
"Discovering the Local Location Information Server (LIS)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5986&eid=2522

--------------------------------------
Type: Editorial
Reported by: Alfred Hoenes <ah@TR-Sys.de>

Section: 5, pg.12

Original Text
-------------
| The domain name that used to authenticate the LIS is the domain name
input to the U-NAPTR process, not the output of that process
[RFC3958], [RFC4848]. As a result, the results of DNS queries do not
need integrity protection.

Corrected Text
--------------
| The domain name that is used to authenticate the LIS is the domain
name input to the U-NAPTR process, not the output of that process
[RFC3958], [RFC4848]. As a result, the results of DNS queries do not
need integrity protection.

Notes
-----
Rationale: missing verb: "is"

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC5986 (draft-ietf-geopriv-lis-discovery-15)
--------------------------------------
Title : Discovering the Local Location Information Server (LIS)
Publication Date : September 2010
Author(s) : M. Thomson, J. Winterbottom
Category : PROPOSED STANDARD
Source : Geographic Location/Privacy
Area : Real-time Applications and Infrastructure
Stream : IETF
Verifying Party : IESG
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] [Editorial Errata Reported] RFC5986 (2521)

The following errata report has been submitted for RFC5986,
"Discovering the Local Location Information Server (LIS)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5986&eid=2521

--------------------------------------
Type: Editorial
Reported by: Alfred Hoenes <ah@TR-Sys.de>

Section: 3.4,3rd para

Original Text
-------------
DHCPv4 option 15 [RFC2132] provides an indication of the domain name
| that a host uses when resolving hostnames in DNS. This option is
used when the DHCPv4 access domain name is not available.

Corrected Text
--------------
DHCPv4 option 15 [RFC2132] provides an indication of the domain name
| that a host uses when resolving hostnames in the DNS. This option is
used when the DHCPv4 access domain name is not available.

Notes
-----
Rationale: missing article

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC5986 (draft-ietf-geopriv-lis-discovery-15)
--------------------------------------
Title : Discovering the Local Location Information Server (LIS)
Publication Date : September 2010
Author(s) : M. Thomson, J. Winterbottom
Category : PROPOSED STANDARD
Source : Geographic Location/Privacy
Area : Real-time Applications and Infrastructure
Stream : IETF
Verifying Party : IESG
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Format of SSID in held-measurements-01.txt

David,

David Waitzman writes:
> As I expressed in my first message, users don't normally look at raw
> XML contents:

This is an interesting argument, and one that I've seen used quite frequently (I've used it myself on occasion).

When applied to the general question of text-vs-binary protocols, the answer tends to be entirely subjective. Taken to its extreme, you end up with ASN.1+PER or similar solutions.

I favour the protocol being usable in the default case. Even if that sort of usage seems unlikely, it's been hugely beneficial in debugging thus far.

> Your suggestion in msg08717.html of: [...]
> >>> octetsAsString = *(vcharx / escaped)
> >>> vcharx = %x21-5b / %x5d-7e ; VCHAR minus backslash
> >>> escaped = %x5c 2HEXDIG
>
> doesn't handle the UTF-8 encoding cases well.

LDAP solves this by adding UTFMB, a pattern that allows for multi-byte UTF-8 sequences:
octetsAsString = *(vcharx / escapted / UTFMB)

In XML, the easiest solution is slightly different, and even quite simple:
([^\\]|\\[0-9a-fA-F]{2})*

That is, everything other than backslash, or backslash plus two hex characters. To convert from a raw token value to a sequence of octets, UTF-8 encode all characters except backslash, then replace all backslash-escaped sequences with a single octet. In reverse, decode UTF-8 and backslash-escape anything that doesn't decode, plus backslash.

The benefits are clear enough:

<ssid>ManufacturerName</ssid>

...as opposed to:

<ssid>4d616e7566616374757265724e616d65</ssid>

...with the occasional:

<ssid>Wêird\5cNàmé</ssid>

> > p.s. It's not immediately clear, but a token can include any string
> content: <http://www.w3.org/TR/xml/#AVNormalize>. The text you cite is
> misleading.
>
> I looked that up and don't get your point. In <xs:element name="ssid"
> type="wifi:ssidBaseType" minOccurs="0"/> we not dealing with an
> Attribute's value.

You have to follow the thread of definitions: token is defined to have whiteSpace set to "collapse". This definition references whiteSpace, which references the attribute value normalization section of the XML specification.

You can check this behaviour with a conformant processor. Try decoding:

<foo xsi:type="xs:token"> &#x20;
&#x20; </foo>

You should get three spaces.

> One additional question for you: what's the difference between "name"
> and "ssid" in wifiType?

Good question. I honestly can't remember now, and I can't find a good reason for the "name" field. A "name" doesn't feature prominently in 802.11-2007, so it must be from somewhere else. I'll ask around and try to find out for you, but I suspect that it's redundant and safe to remove.

--Martin


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

[Geopriv] FYI: RFC 5962 publication

Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO) has been published as a proposed standard:

<http://tools.ietf.org/html/rfc5962>

Abstract

The Geopriv Location Object introduced by the Presence Information
Data Format - Location Object (PIDF-LO), RFC 4119, defines a basic
XML format for carrying geographical information of a presentity.
This document defines PIDF-LO extensions to convey information about
moving objects. Elements are defined that enable expression of
spatial orientation, speed, and heading of the presentity.

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

Re: [Geopriv] Format of SSID in held-measurements-01.txt

Martin,

On Sep 13, 2010, at 8:19 PM, Thomson, Martin wrote:
> The SSID as string is an error.
>
> It would be relatively easy to change the base type used here to xs:hexBinary.

Using xs:hexBinary is also a good choice; I was trying to mirror how macAddressType are encoded.

> The only concern is that, in most cases, an SSID is a string. Users set and view SSIDs as strings.
>
> LDAP has a similar problem with its attributes and they solved it [RFC4514] differently. And I proposed that we do the same in response to John Bressler:
>
> <http://www.ietf.org/mail-archive/web/geopriv/current/msg08717.html>

I get geopriv as a digest, for now, so it's too easy to loose track of valuable individual emails like John's and your response to him.

> That solution recognizes the virtues of a text-based protocol and attempts to retain those virtues at a small cost in complexity.

As I expressed in my first message, users don't normally look at raw XML contents:
>> This way the *protocol* can express all legal underlying values and
>> *implementations* can choose to pretty-print the SSID values if they
>> wish.
>>
>> A drawback to my suggestion is that the raw XML contents will no longer
>> display human readable SSID values. But I don't feel that the IETF
>> mandates humans being able to easily read raw packet dumps.

Your suggestion in msg08717.html of:
>>> LDAP uses a simple scheme where a backslash followed by two hex characters is converted into an octet with that value:
>>>
>>> octetsAsString = *(vcharx / escaped)
>>> vcharx = %x21-5b / %x5d-7e ; VCHAR minus backslash
>>> escaped = %x5c 2HEXDIG

doesn't handle the UTF-8 encoding cases well. It would escape all non-ASCII values in an UTF-8 string, so for practical real-world cases, would use escaping. We did tests here with non-ASCII UTF-8 contents in real wireless devices and some were fine with them, like Apple Airports.

Therefore, I still prefer my proposal or your hexBinary proposal. At least the LDAP scheme is not lossy as compared to the current HELD-measurements draft.

> p.s. It's not immediately clear, but a token can include any string content: <http://www.w3.org/TR/xml/#AVNormalize>. The text you cite is misleading.

I looked that up and don't get your point. In <xs:element name="ssid" type="wifi:ssidBaseType" minOccurs="0"/> we not dealing with an Attribute's value.

---

One additional question for you: what's the difference between "name" and "ssid" in wifiType?

name: The broadcast name for the access point.
ssid: The service set identifier for the wireless network served by
the access point.

<xs:element name="name" type="wifi:ssidBaseType" minOccurs="0"/>

The one example of a wifiType has these values with different capitalization:
<name>Example</name>
<ssid>example</ssid>

As far as I can understand, name should be identical to ssid. Perhaps there was supposed to be some distinction with regards to "hidden" SSIDs?

--
David Waitzman
BBN Technologies
djw@bbn.com 410-290-6160

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

Re: [Geopriv] Format of SSID in held-measurements-01.txt

The SSID as string is an error.

It would be relatively easy to change the base type used here to xs:hexBinary.

The only concern is that, in most cases, an SSID is a string. Users set and view SSIDs as strings.

LDAP has a similar problem with its attributes and they solved it [RFC4514] differently. And I proposed that we do the same in response to John Bressler:

<http://www.ietf.org/mail-archive/web/geopriv/current/msg08717.html>

That solution recognizes the virtues of a text-based protocol and attempts to retain those virtues at a small cost in complexity.

--Martin

p.s. It's not immediately clear, but a token can include any string content: <http://www.w3.org/TR/xml/#AVNormalize>. The text you cite is misleading.

> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of David Waitzman
> Sent: Tuesday, 14 September 2010 5:49 AM
> To: geopriv@ietf.org
> Subject: [Geopriv] Format of SSID in held-measurements-01.txt
>
> I have a comment about the choice of data representation of SSID along
> with a suggested change.
>
> The held-measurements draft makes a common assumption that the SSID
> (not the BSSID) is a printable character string. This is expressed in
> the XML on page 52:
> <xs:simpleType name="ssidBaseType">
> <xs:restriction base="xs:token">
> <xs:maxLength value="32"/>
> </xs:restriction>
> </xs:simpleType>
>
> Actually, xs:token has some important restrictions on its contents.
> http://www.w3.org/TR/xmlschema-2/#token says:
> "The ·value space· of token is the set of strings that do not contain
> the carriage return (#xD), line feed (#xA) nor tab (#x9) characters,
> that have no leading or trailing spaces (#x20) and that have no
> internal sequences of two or more spaces."
>
> The IEEE 802.11 standards simply state a SSID is "0 to 32 octets".
> Nothing about ASCII or UTF-8. I think it is just a convenience hack
> that many 802.11 devices show them as if they are ASCII and some in
> UTF-8.
>
> Therefore, the held-measurements draft can not represent all valid SSID
> values nor even all common ones (such as with leading/trailing/multiple
> spaces or a tab).
>
> Additionally, non-printable SSIDs have been used in the past to defeat
> wardriving tools, by having contents that the tools would crash upon
> decoding. If we make a clear comment in the draft to *not* assume
> ASCII or legal UTF-8 values, we can encourage more robust
> implementations.
>
> I suggest changing ssidBaseType to be something that can hold any octet
> value, like:
> <xs:simpleType name="ssidBaseType">
> <xs:restriction base="xs:string">
> <xs:pattern value="(([0-9A-Fa-f]{2})(-[0-9A-Fa-f]{2}){0,31})?"/>
> </xs:restriction>
> </xs:simpleType>
>
> Example: 45-40-01-00-fe
>
> This pattern is similar to what's used for macAddressType.
>
> This way the *protocol* can express all legal underlying values and
> *implementations* can choose to pretty-print the SSID values if they
> wish.
>
> A drawback to my suggestion is that the raw XML contents will no longer
> display human readable SSID values. But I don't feel that the IETF
> mandates humans being able to easily read raw packet dumps.
>
> --
> David Waitzman
> BBN Technologies
> djw@bbn.com 410-290-6160

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

Re: [Geopriv] New Version Notification for draft-winterbottom-geopriv-local-civic-00

On Mon, Sep 13, 2010 at 12:18 PM, Winterbottom, James
<James.Winterbottom@andrew.com> wrote:
> I would not support your approach Ted as I think it becomes horribly convoluted  very quickly.

Why? Because of the multiple namespaces needed to parse the XML?

It's an interoperability trade-off. If anyone can mint a namespace
and elements within it with no
registration (pace review for a minute), then you'll very quickly get
fragmentation in the extensions.
For extensions which are highly likely to overlap, that fragmentation
isn't needed, is bad for the
end-user, and could be avoided. For those that don't, the key
questions are whether the barrier to
creating a registered extension is so high that it's a problem and
whether the number of interesting,
useful extensions coming from multiple namespaces gets out of hand.

For the second one, I would suggest that if this is likely to be a
problem, then the fragmentation
issue is equally serious. Your mileage may vary.

regards,

Ted
> I also don't think that we can limit the registry to one per country, this extension scheme is not proposed just for jurisdictional extensions, it is proposed for all extensions, including enterprise application extensions. So any assertion as to only a few number of namespaces is well grounded unless we are also saying that people don't have to register them. If we say the latter then we shouldn't expect anyone to register them.
>
> Cheers
> James
>
>
>
> ________________________________________
> From: Brian Rosen [br@brianrosen.net]
> Sent: Monday, September 13, 2010 12:39 PM
> To: Ted Hardie
> Cc: Winterbottom, James; Thomson, Martin; geopriv@ietf.org; James M. Polk
> Subject: Re: [Geopriv] New Version Notification for draft-winterbottom-geopriv-local-civic-00
>
> I suppose it depends on how fragmented you want these things to be.
>
> I was thinking that we would try to keep the number of namespaces down to (about) one per country.
>
> If the U.S., say, was first to define "milepost", but the UK used milepost, would you want the UK to import the US namespace just to get the milepost definition?  It would clearly work, but I was thinking that the element registry didn't have the namespace, but that we encouraged reuse of the same entry in the registry for the same thing.
>
> I'm okay either way.
>
> Brian
>
>
>
> On Sep 13, 2010, at 12:51 PM, Ted Hardie wrote:
>
>> On Fri, Sep 10, 2010 at 5:54 PM, Winterbottom, James
>> <James.Winterbottom@andrew.com> wrote:
>>> What you have said is clear, and I do understand it.
>>> My concern is that this falsely lulls a node receiving an element named fred in one namesapce into believing that it is interchangeable  with fred in another namespace, and I think that this is a very dangerous precedent to set. If this is not the precedent that is trying to be set then I think that the second registry is redundant.
>>>
>>> Cheers
>>> James
>>
>> I think the second registry actually shows tuples of (namespace,
>> element) so that someone considering
>> naming something ("newnamespace", "matched name") can consider whether
>> they 1) need to create
>> that element at all (instead re-using the existing one) or 2) whether
>> disambiguation might be useful
>> (e.g. using "track mile marker" instead of "milepost" for train track
>> mile markers, when "milepost" has
>> already been used to mean road mile markers).
>>
>> regards,
>>
>> Ted
>>
>>
>>
>>
>>> ________________________________________
>>> From: Brian Rosen [br@brianrosen.net]
>>> Sent: Friday, September 10, 2010 5:35 PM
>>> To: Winterbottom, James
>>> Cc: Ted Hardie; Thomson, Martin; geopriv@ietf.org; James M. Polk
>>> Subject: Re: [Geopriv] New Version Notification for draft-winterbottom-geopriv-local-civic-00
>>>
>>> I proposed two registries:
>>>
>>> One registered namespaces with (approximately) one per country.
>>>
>>> One registered element tags with expert review to avoid duplication and consistent naming that can be as big as it needs to be.
>>>
>>> I believe we all understand that an element in one namespace is distinct from an element in another in a syntactic/XML sense.  However, it is very useful to avoid mile-post vs milepost even if the XML tools are clear that they are not the "same" thing.  The point we are making is that they ARE the same thing and we should call them, and use them, the same way in any namespace that needs that kind of element.  XML is actually getting in the way here, but no one is proposing to actually do anything other than have some expert look at a new element name to see if it is already in the registry and the same element name can be re-used to avoid complexity and confusion.
>>>
>>> Brian
>>>
>>> On Sep 10, 2010, at 6:12 PM, Winterbottom, James wrote:
>>>
>>>> Hi Ted,
>>>>
>>>> [AJW] I want to make really sure that I understand what you are saying here.
>>>> Are you suggesting that different jurisdictions are defining different CATypes, e.g. Jurisdiction A defines CAType[100]=lamp-post and jurisdiction B defines CAType[101]=lamppost?
>>>> This is the only kind of real overlap that I can see, and the draft indicates why continuing to extend CATypes has significant ramifications and should not be done.
>>>> This really only leaves the option of adding new elements into a new XML namespace.
>>>> Can we agree on this to start with?
>>>> Otherwise we are not starting from the same premise.
>>>>
>>>> Other comments inline...
>>>>
>>>>
>>>>
>>>> For what it is worth, that's not something I see in the discussion to
>>>> date at all.  The interoperability you achieve
>>>> with the xml namespace-based proposal without a registry is whatever
>>>> was initially standardized.  Each subsequent
>>>> jurisdiction that wants to add functionality does so independently.
>>>>
>>>> [AJW] Do you agree that it does it within the jurisdiction though, and that the jurisdiction likely has the ability to require conformance?
>>>>
>>>> I agree with Brian that this is likely to mean that
>>>> un-reviewed later additions will overlap (but likely not perfectly).
>>>> Since the sender doesn't know what the
>>>> receiver supports, the sender can't fix it by mapping to namespaces
>>>> that the receiver *does* understand.  That means
>>>> the end device that doesn't understand "mile-post" but would have
>>>> understood "milepost" can send it along,
>>>> but can't actually use the data.
>>>>
>>>> [AJW] Okay, I see what you are saying, but I think that there are a couple of over simplifications in your example.
>>>> The first is that if I have two namespaces urn:orga:civicextension and urn:orgb:civicextension, and both define milepost,
>>>> <milepost xlmns:urn:orga:civicextension/> is not the same as <milepost xlmns:urn:orgb:civicextension/>, one cane define it as an integer, the other a complex element, and someone else a token. This is a very local thing and it should be.
>>>> So what I am trying to say is that the base-part, that everyone needs to understand, is defined in the 5139 schema. Extensions are local, and that not everything will understand them, but they must not discard them. This will ensure that the information is used by things that can use it, even if intermediaries can't. This will mean that local applications will work, but that a foreign application may not get everything it wants. Emergency services as per ECRIT will work fine using the above method. Personally I think this is okay.
>>>>
>>>> I think having a registry here helps by identifying what has already
>>>> been covered and fosters interoperability.
>>>> Having a reviewer helps further, but making a first-come first-served
>>>> registry to help folks identify what
>>>> has already been done.  I really don't seen how that level of support
>>>> from the IETF could be considered
>>>> control.
>>>> [AJW] Because registry that Brian was proposing was a namespace registry, I didn't see a suggestion of also requiring them to register their schema extensions with the IETF. Even if they did, if the first come one had defined a lampost as a token within their namespace, and a second organization wanted to define a lamp-post as a token, for the second organization to pickup the first lamppost into their schema would result in a lot of unnecessary inclusions.
>>>>
>>>> So this leads back to my initial question of whether people understand the concern raise din the document about the continuing addition of more and more CATypes, and how this impacts things already specified and implemented.
>>>>
>>>> Cheers
>>>> James
>>>
>>>
>
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] New Version Notification for draft-winterbottom-geopriv-local-civic-00

If any enterprise can add anything it wants to a PIDF, then we have no interoperability unless all the apps knew about all of the enterprises. This is impossible.

We can't stop any enterprise from doing this of course, and I don't want to. However, I want to be able to write apps that can parse addresses all over the world. With a finite number of namespaces listed in a registry, I have a reasonable chance to do that.

Brian

On Sep 13, 2010, at 3:18 PM, Winterbottom, James wrote:

> I would not support your approach Ted as I think it becomes horribly convoluted very quickly.
> I also don't think that we can limit the registry to one per country, this extension scheme is not proposed just for jurisdictional extensions, it is proposed for all extensions, including enterprise application extensions. So any assertion as to only a few number of namespaces is well grounded unless we are also saying that people don't have to register them. If we say the latter then we shouldn't expect anyone to register them.
>
> Cheers
> James
>
>
>
> ________________________________________
> From: Brian Rosen [br@brianrosen.net]
> Sent: Monday, September 13, 2010 12:39 PM
> To: Ted Hardie
> Cc: Winterbottom, James; Thomson, Martin; geopriv@ietf.org; James M. Polk
> Subject: Re: [Geopriv] New Version Notification for draft-winterbottom-geopriv-local-civic-00
>
> I suppose it depends on how fragmented you want these things to be.
>
> I was thinking that we would try to keep the number of namespaces down to (about) one per country.
>
> If the U.S., say, was first to define "milepost", but the UK used milepost, would you want the UK to import the US namespace just to get the milepost definition? It would clearly work, but I was thinking that the element registry didn't have the namespace, but that we encouraged reuse of the same entry in the registry for the same thing.
>
> I'm okay either way.
>
> Brian
>
>
>
> On Sep 13, 2010, at 12:51 PM, Ted Hardie wrote:
>
>> On Fri, Sep 10, 2010 at 5:54 PM, Winterbottom, James
>> <James.Winterbottom@andrew.com> wrote:
>>> What you have said is clear, and I do understand it.
>>> My concern is that this falsely lulls a node receiving an element named fred in one namesapce into believing that it is interchangeable with fred in another namespace, and I think that this is a very dangerous precedent to set. If this is not the precedent that is trying to be set then I think that the second registry is redundant.
>>>
>>> Cheers
>>> James
>>
>> I think the second registry actually shows tuples of (namespace,
>> element) so that someone considering
>> naming something ("newnamespace", "matched name") can consider whether
>> they 1) need to create
>> that element at all (instead re-using the existing one) or 2) whether
>> disambiguation might be useful
>> (e.g. using "track mile marker" instead of "milepost" for train track
>> mile markers, when "milepost" has
>> already been used to mean road mile markers).
>>
>> regards,
>>
>> Ted
>>
>>
>>
>>
>>> ________________________________________
>>> From: Brian Rosen [br@brianrosen.net]
>>> Sent: Friday, September 10, 2010 5:35 PM
>>> To: Winterbottom, James
>>> Cc: Ted Hardie; Thomson, Martin; geopriv@ietf.org; James M. Polk
>>> Subject: Re: [Geopriv] New Version Notification for draft-winterbottom-geopriv-local-civic-00
>>>
>>> I proposed two registries:
>>>
>>> One registered namespaces with (approximately) one per country.
>>>
>>> One registered element tags with expert review to avoid duplication and consistent naming that can be as big as it needs to be.
>>>
>>> I believe we all understand that an element in one namespace is distinct from an element in another in a syntactic/XML sense. However, it is very useful to avoid mile-post vs milepost even if the XML tools are clear that they are not the "same" thing. The point we are making is that they ARE the same thing and we should call them, and use them, the same way in any namespace that needs that kind of element. XML is actually getting in the way here, but no one is proposing to actually do anything other than have some expert look at a new element name to see if it is already in the registry and the same element name can be re-used to avoid complexity and confusion.
>>>
>>> Brian
>>>
>>> On Sep 10, 2010, at 6:12 PM, Winterbottom, James wrote:
>>>
>>>> Hi Ted,
>>>>
>>>> [AJW] I want to make really sure that I understand what you are saying here.
>>>> Are you suggesting that different jurisdictions are defining different CATypes, e.g. Jurisdiction A defines CAType[100]=lamp-post and jurisdiction B defines CAType[101]=lamppost?
>>>> This is the only kind of real overlap that I can see, and the draft indicates why continuing to extend CATypes has significant ramifications and should not be done.
>>>> This really only leaves the option of adding new elements into a new XML namespace.
>>>> Can we agree on this to start with?
>>>> Otherwise we are not starting from the same premise.
>>>>
>>>> Other comments inline...
>>>>
>>>>
>>>>
>>>> For what it is worth, that's not something I see in the discussion to
>>>> date at all. The interoperability you achieve
>>>> with the xml namespace-based proposal without a registry is whatever
>>>> was initially standardized. Each subsequent
>>>> jurisdiction that wants to add functionality does so independently.
>>>>
>>>> [AJW] Do you agree that it does it within the jurisdiction though, and that the jurisdiction likely has the ability to require conformance?
>>>>
>>>> I agree with Brian that this is likely to mean that
>>>> un-reviewed later additions will overlap (but likely not perfectly).
>>>> Since the sender doesn't know what the
>>>> receiver supports, the sender can't fix it by mapping to namespaces
>>>> that the receiver *does* understand. That means
>>>> the end device that doesn't understand "mile-post" but would have
>>>> understood "milepost" can send it along,
>>>> but can't actually use the data.
>>>>
>>>> [AJW] Okay, I see what you are saying, but I think that there are a couple of over simplifications in your example.
>>>> The first is that if I have two namespaces urn:orga:civicextension and urn:orgb:civicextension, and both define milepost,
>>>> <milepost xlmns:urn:orga:civicextension/> is not the same as <milepost xlmns:urn:orgb:civicextension/>, one cane define it as an integer, the other a complex element, and someone else a token. This is a very local thing and it should be.
>>>> So what I am trying to say is that the base-part, that everyone needs to understand, is defined in the 5139 schema. Extensions are local, and that not everything will understand them, but they must not discard them. This will ensure that the information is used by things that can use it, even if intermediaries can't. This will mean that local applications will work, but that a foreign application may not get everything it wants. Emergency services as per ECRIT will work fine using the above method. Personally I think this is okay.
>>>>
>>>> I think having a registry here helps by identifying what has already
>>>> been covered and fosters interoperability.
>>>> Having a reviewer helps further, but making a first-come first-served
>>>> registry to help folks identify what
>>>> has already been done. I really don't seen how that level of support
>>>> from the IETF could be considered
>>>> control.
>>>> [AJW] Because registry that Brian was proposing was a namespace registry, I didn't see a suggestion of also requiring them to register their schema extensions with the IETF. Even if they did, if the first come one had defined a lampost as a token within their namespace, and a second organization wanted to define a lamp-post as a token, for the second organization to pickup the first lamppost into their schema would result in a lot of unnecessary inclusions.
>>>>
>>>> So this leads back to my initial question of whether people understand the concern raise din the document about the continuing addition of more and more CATypes, and how this impacts things already specified and implemented.
>>>>
>>>> Cheers
>>>> James
>>>
>>>
>

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

Re: [Geopriv] Format of SSID in held-measurements-01.txt

Thanks for the pickup and suggestion David.

Cheers
James

________________________________________
From: geopriv-bounces@ietf.org [geopriv-bounces@ietf.org] On Behalf Of David Waitzman [djw@bbn.com]
Sent: Monday, September 13, 2010 2:49 PM
To: geopriv@ietf.org
Subject: [Geopriv] Format of SSID in held-measurements-01.txt

I have a comment about the choice of data representation of SSID along with a suggested change.

The held-measurements draft makes a common assumption that the SSID (not the BSSID) is a printable character string. This is expressed in the XML on page 52:
<xs:simpleType name="ssidBaseType">
<xs:restriction base="xs:token">
<xs:maxLength value="32"/>
</xs:restriction>
</xs:simpleType>

Actually, xs:token has some important restrictions on its contents. http://www.w3.org/TR/xmlschema-2/#token says:
"The ·value space· of token is the set of strings that do not contain the carriage return (#xD), line feed (#xA) nor tab (#x9) characters, that have no leading or trailing spaces (#x20) and that have no internal sequences of two or more spaces."

The IEEE 802.11 standards simply state a SSID is "0 to 32 octets". Nothing about ASCII or UTF-8. I think it is just a convenience hack that many 802.11 devices show them as if they are ASCII and some in UTF-8.

Therefore, the held-measurements draft can not represent all valid SSID values nor even all common ones (such as with leading/trailing/multiple spaces or a tab).

Additionally, non-printable SSIDs have been used in the past to defeat wardriving tools, by having contents that the tools would crash upon decoding. If we make a clear comment in the draft to *not* assume ASCII or legal UTF-8 values, we can encourage more robust implementations.

I suggest changing ssidBaseType to be something that can hold any octet value, like:
<xs:simpleType name="ssidBaseType">
<xs:restriction base="xs:string">
<xs:pattern value="(([0-9A-Fa-f]{2})(-[0-9A-Fa-f]{2}){0,31})?"/>
</xs:restriction>
</xs:simpleType>

Example: 45-40-01-00-fe

This pattern is similar to what's used for macAddressType.

This way the *protocol* can express all legal underlying values and *implementations* can choose to pretty-print the SSID values if they wish.

A drawback to my suggestion is that the raw XML contents will no longer display human readable SSID values. But I don't feel that the IETF mandates humans being able to easily read raw packet dumps.

--
David Waitzman
BBN Technologies
djw@bbn.com 410-290-6160

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

[Geopriv] Format of SSID in held-measurements-01.txt

I have a comment about the choice of data representation of SSID along with a suggested change.

The held-measurements draft makes a common assumption that the SSID (not the BSSID) is a printable character string. This is expressed in the XML on page 52:
<xs:simpleType name="ssidBaseType">
<xs:restriction base="xs:token">
<xs:maxLength value="32"/>
</xs:restriction>
</xs:simpleType>

Actually, xs:token has some important restrictions on its contents. http://www.w3.org/TR/xmlschema-2/#token says:
"The ·value space· of token is the set of strings that do not contain the carriage return (#xD), line feed (#xA) nor tab (#x9) characters, that have no leading or trailing spaces (#x20) and that have no internal sequences of two or more spaces."

The IEEE 802.11 standards simply state a SSID is "0 to 32 octets". Nothing about ASCII or UTF-8. I think it is just a convenience hack that many 802.11 devices show them as if they are ASCII and some in UTF-8.

Therefore, the held-measurements draft can not represent all valid SSID values nor even all common ones (such as with leading/trailing/multiple spaces or a tab).

Additionally, non-printable SSIDs have been used in the past to defeat wardriving tools, by having contents that the tools would crash upon decoding. If we make a clear comment in the draft to *not* assume ASCII or legal UTF-8 values, we can encourage more robust implementations.

I suggest changing ssidBaseType to be something that can hold any octet value, like:
<xs:simpleType name="ssidBaseType">
<xs:restriction base="xs:string">
<xs:pattern value="(([0-9A-Fa-f]{2})(-[0-9A-Fa-f]{2}){0,31})?"/>
</xs:restriction>
</xs:simpleType>

Example: 45-40-01-00-fe

This pattern is similar to what's used for macAddressType.

This way the *protocol* can express all legal underlying values and *implementations* can choose to pretty-print the SSID values if they wish.

A drawback to my suggestion is that the raw XML contents will no longer display human readable SSID values. But I don't feel that the IETF mandates humans being able to easily read raw packet dumps.

--
David Waitzman
BBN Technologies
djw@bbn.com 410-290-6160

Re: [Geopriv] New Version Notification for draft-winterbottom-geopriv-local-civic-00

I would not support your approach Ted as I think it becomes horribly convoluted very quickly.
I also don't think that we can limit the registry to one per country, this extension scheme is not proposed just for jurisdictional extensions, it is proposed for all extensions, including enterprise application extensions. So any assertion as to only a few number of namespaces is well grounded unless we are also saying that people don't have to register them. If we say the latter then we shouldn't expect anyone to register them.

Cheers
James

________________________________________
From: Brian Rosen [br@brianrosen.net]
Sent: Monday, September 13, 2010 12:39 PM
To: Ted Hardie
Cc: Winterbottom, James; Thomson, Martin; geopriv@ietf.org; James M. Polk
Subject: Re: [Geopriv] New Version Notification for draft-winterbottom-geopriv-local-civic-00

I suppose it depends on how fragmented you want these things to be.

I was thinking that we would try to keep the number of namespaces down to (about) one per country.

If the U.S., say, was first to define "milepost", but the UK used milepost, would you want the UK to import the US namespace just to get the milepost definition? It would clearly work, but I was thinking that the element registry didn't have the namespace, but that we encouraged reuse of the same entry in the registry for the same thing.

I'm okay either way.

Brian

On Sep 13, 2010, at 12:51 PM, Ted Hardie wrote:

> On Fri, Sep 10, 2010 at 5:54 PM, Winterbottom, James
> <James.Winterbottom@andrew.com> wrote:
>> What you have said is clear, and I do understand it.
>> My concern is that this falsely lulls a node receiving an element named fred in one namesapce into believing that it is interchangeable with fred in another namespace, and I think that this is a very dangerous precedent to set. If this is not the precedent that is trying to be set then I think that the second registry is redundant.
>>
>> Cheers
>> James
>
> I think the second registry actually shows tuples of (namespace,
> element) so that someone considering
> naming something ("newnamespace", "matched name") can consider whether
> they 1) need to create
> that element at all (instead re-using the existing one) or 2) whether
> disambiguation might be useful
> (e.g. using "track mile marker" instead of "milepost" for train track
> mile markers, when "milepost" has
> already been used to mean road mile markers).
>
> regards,
>
> Ted
>
>
>
>
>> ________________________________________
>> From: Brian Rosen [br@brianrosen.net]
>> Sent: Friday, September 10, 2010 5:35 PM
>> To: Winterbottom, James
>> Cc: Ted Hardie; Thomson, Martin; geopriv@ietf.org; James M. Polk
>> Subject: Re: [Geopriv] New Version Notification for draft-winterbottom-geopriv-local-civic-00
>>
>> I proposed two registries:
>>
>> One registered namespaces with (approximately) one per country.
>>
>> One registered element tags with expert review to avoid duplication and consistent naming that can be as big as it needs to be.
>>
>> I believe we all understand that an element in one namespace is distinct from an element in another in a syntactic/XML sense. However, it is very useful to avoid mile-post vs milepost even if the XML tools are clear that they are not the "same" thing. The point we are making is that they ARE the same thing and we should call them, and use them, the same way in any namespace that needs that kind of element. XML is actually getting in the way here, but no one is proposing to actually do anything other than have some expert look at a new element name to see if it is already in the registry and the same element name can be re-used to avoid complexity and confusion.
>>
>> Brian
>>
>> On Sep 10, 2010, at 6:12 PM, Winterbottom, James wrote:
>>
>>> Hi Ted,
>>>
>>> [AJW] I want to make really sure that I understand what you are saying here.
>>> Are you suggesting that different jurisdictions are defining different CATypes, e.g. Jurisdiction A defines CAType[100]=lamp-post and jurisdiction B defines CAType[101]=lamppost?
>>> This is the only kind of real overlap that I can see, and the draft indicates why continuing to extend CATypes has significant ramifications and should not be done.
>>> This really only leaves the option of adding new elements into a new XML namespace.
>>> Can we agree on this to start with?
>>> Otherwise we are not starting from the same premise.
>>>
>>> Other comments inline...
>>>
>>>
>>>
>>> For what it is worth, that's not something I see in the discussion to
>>> date at all. The interoperability you achieve
>>> with the xml namespace-based proposal without a registry is whatever
>>> was initially standardized. Each subsequent
>>> jurisdiction that wants to add functionality does so independently.
>>>
>>> [AJW] Do you agree that it does it within the jurisdiction though, and that the jurisdiction likely has the ability to require conformance?
>>>
>>> I agree with Brian that this is likely to mean that
>>> un-reviewed later additions will overlap (but likely not perfectly).
>>> Since the sender doesn't know what the
>>> receiver supports, the sender can't fix it by mapping to namespaces
>>> that the receiver *does* understand. That means
>>> the end device that doesn't understand "mile-post" but would have
>>> understood "milepost" can send it along,
>>> but can't actually use the data.
>>>
>>> [AJW] Okay, I see what you are saying, but I think that there are a couple of over simplifications in your example.
>>> The first is that if I have two namespaces urn:orga:civicextension and urn:orgb:civicextension, and both define milepost,
>>> <milepost xlmns:urn:orga:civicextension/> is not the same as <milepost xlmns:urn:orgb:civicextension/>, one cane define it as an integer, the other a complex element, and someone else a token. This is a very local thing and it should be.
>>> So what I am trying to say is that the base-part, that everyone needs to understand, is defined in the 5139 schema. Extensions are local, and that not everything will understand them, but they must not discard them. This will ensure that the information is used by things that can use it, even if intermediaries can't. This will mean that local applications will work, but that a foreign application may not get everything it wants. Emergency services as per ECRIT will work fine using the above method. Personally I think this is okay.
>>>
>>> I think having a registry here helps by identifying what has already
>>> been covered and fosters interoperability.
>>> Having a reviewer helps further, but making a first-come first-served
>>> registry to help folks identify what
>>> has already been done. I really don't seen how that level of support
>>> from the IETF could be considered
>>> control.
>>> [AJW] Because registry that Brian was proposing was a namespace registry, I didn't see a suggestion of also requiring them to register their schema extensions with the IETF. Even if they did, if the first come one had defined a lampost as a token within their namespace, and a second organization wanted to define a lamp-post as a token, for the second organization to pickup the first lamppost into their schema would result in a lot of unnecessary inclusions.
>>>
>>> So this leads back to my initial question of whether people understand the concern raise din the document about the continuing addition of more and more CATypes, and how this impacts things already specified and implemented.
>>>
>>> Cheers
>>> James
>>
>>

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

Re: [Geopriv] New Version Notification for draft-winterbottom-geopriv-local-civic-00

I suppose it depends on how fragmented you want these things to be.

I was thinking that we would try to keep the number of namespaces down to (about) one per country.

If the U.S., say, was first to define "milepost", but the UK used milepost, would you want the UK to import the US namespace just to get the milepost definition? It would clearly work, but I was thinking that the element registry didn't have the namespace, but that we encouraged reuse of the same entry in the registry for the same thing.

I'm okay either way.

Brian

On Sep 13, 2010, at 12:51 PM, Ted Hardie wrote:

> On Fri, Sep 10, 2010 at 5:54 PM, Winterbottom, James
> <James.Winterbottom@andrew.com> wrote:
>> What you have said is clear, and I do understand it.
>> My concern is that this falsely lulls a node receiving an element named fred in one namesapce into believing that it is interchangeable with fred in another namespace, and I think that this is a very dangerous precedent to set. If this is not the precedent that is trying to be set then I think that the second registry is redundant.
>>
>> Cheers
>> James
>
> I think the second registry actually shows tuples of (namespace,
> element) so that someone considering
> naming something ("newnamespace", "matched name") can consider whether
> they 1) need to create
> that element at all (instead re-using the existing one) or 2) whether
> disambiguation might be useful
> (e.g. using "track mile marker" instead of "milepost" for train track
> mile markers, when "milepost" has
> already been used to mean road mile markers).
>
> regards,
>
> Ted
>
>
>
>
>> ________________________________________
>> From: Brian Rosen [br@brianrosen.net]
>> Sent: Friday, September 10, 2010 5:35 PM
>> To: Winterbottom, James
>> Cc: Ted Hardie; Thomson, Martin; geopriv@ietf.org; James M. Polk
>> Subject: Re: [Geopriv] New Version Notification for draft-winterbottom-geopriv-local-civic-00
>>
>> I proposed two registries:
>>
>> One registered namespaces with (approximately) one per country.
>>
>> One registered element tags with expert review to avoid duplication and consistent naming that can be as big as it needs to be.
>>
>> I believe we all understand that an element in one namespace is distinct from an element in another in a syntactic/XML sense. However, it is very useful to avoid mile-post vs milepost even if the XML tools are clear that they are not the "same" thing. The point we are making is that they ARE the same thing and we should call them, and use them, the same way in any namespace that needs that kind of element. XML is actually getting in the way here, but no one is proposing to actually do anything other than have some expert look at a new element name to see if it is already in the registry and the same element name can be re-used to avoid complexity and confusion.
>>
>> Brian
>>
>> On Sep 10, 2010, at 6:12 PM, Winterbottom, James wrote:
>>
>>> Hi Ted,
>>>
>>> [AJW] I want to make really sure that I understand what you are saying here.
>>> Are you suggesting that different jurisdictions are defining different CATypes, e.g. Jurisdiction A defines CAType[100]=lamp-post and jurisdiction B defines CAType[101]=lamppost?
>>> This is the only kind of real overlap that I can see, and the draft indicates why continuing to extend CATypes has significant ramifications and should not be done.
>>> This really only leaves the option of adding new elements into a new XML namespace.
>>> Can we agree on this to start with?
>>> Otherwise we are not starting from the same premise.
>>>
>>> Other comments inline...
>>>
>>>
>>>
>>> For what it is worth, that's not something I see in the discussion to
>>> date at all. The interoperability you achieve
>>> with the xml namespace-based proposal without a registry is whatever
>>> was initially standardized. Each subsequent
>>> jurisdiction that wants to add functionality does so independently.
>>>
>>> [AJW] Do you agree that it does it within the jurisdiction though, and that the jurisdiction likely has the ability to require conformance?
>>>
>>> I agree with Brian that this is likely to mean that
>>> un-reviewed later additions will overlap (but likely not perfectly).
>>> Since the sender doesn't know what the
>>> receiver supports, the sender can't fix it by mapping to namespaces
>>> that the receiver *does* understand. That means
>>> the end device that doesn't understand "mile-post" but would have
>>> understood "milepost" can send it along,
>>> but can't actually use the data.
>>>
>>> [AJW] Okay, I see what you are saying, but I think that there are a couple of over simplifications in your example.
>>> The first is that if I have two namespaces urn:orga:civicextension and urn:orgb:civicextension, and both define milepost,
>>> <milepost xlmns:urn:orga:civicextension/> is not the same as <milepost xlmns:urn:orgb:civicextension/>, one cane define it as an integer, the other a complex element, and someone else a token. This is a very local thing and it should be.
>>> So what I am trying to say is that the base-part, that everyone needs to understand, is defined in the 5139 schema. Extensions are local, and that not everything will understand them, but they must not discard them. This will ensure that the information is used by things that can use it, even if intermediaries can't. This will mean that local applications will work, but that a foreign application may not get everything it wants. Emergency services as per ECRIT will work fine using the above method. Personally I think this is okay.
>>>
>>> I think having a registry here helps by identifying what has already
>>> been covered and fosters interoperability.
>>> Having a reviewer helps further, but making a first-come first-served
>>> registry to help folks identify what
>>> has already been done. I really don't seen how that level of support
>>> from the IETF could be considered
>>> control.
>>> [AJW] Because registry that Brian was proposing was a namespace registry, I didn't see a suggestion of also requiring them to register their schema extensions with the IETF. Even if they did, if the first come one had defined a lampost as a token within their namespace, and a second organization wanted to define a lamp-post as a token, for the second organization to pickup the first lamppost into their schema would result in a lot of unnecessary inclusions.
>>>
>>> So this leads back to my initial question of whether people understand the concern raise din the document about the continuing addition of more and more CATypes, and how this impacts things already specified and implemented.
>>>
>>> Cheers
>>> James
>>
>>

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

Re: [Geopriv] New Version Notification for draft-winterbottom-geopriv-local-civic-00

On Fri, Sep 10, 2010 at 5:54 PM, Winterbottom, James
<James.Winterbottom@andrew.com> wrote:
> What you have said is clear, and I do understand it.
> My concern is that this falsely lulls a node receiving an element named fred in one namesapce into believing that it is interchangeable  with fred in another namespace, and I think that this is a very dangerous precedent to set. If this is not the precedent that is trying to be set then I think that the second registry is redundant.
>
> Cheers
> James

I think the second registry actually shows tuples of (namespace,
element) so that someone considering
naming something ("newnamespace", "matched name") can consider whether
they 1) need to create
that element at all (instead re-using the existing one) or 2) whether
disambiguation might be useful
(e.g. using "track mile marker" instead of "milepost" for train track
mile markers, when "milepost" has
already been used to mean road mile markers).

regards,

Ted

> ________________________________________
> From: Brian Rosen [br@brianrosen.net]
> Sent: Friday, September 10, 2010 5:35 PM
> To: Winterbottom, James
> Cc: Ted Hardie; Thomson, Martin; geopriv@ietf.org; James M. Polk
> Subject: Re: [Geopriv] New Version Notification for draft-winterbottom-geopriv-local-civic-00
>
> I proposed two registries:
>
> One registered namespaces with (approximately) one per country.
>
> One registered element tags with expert review to avoid duplication and consistent naming that can be as big as it needs to be.
>
> I believe we all understand that an element in one namespace is distinct from an element in another in a syntactic/XML sense.  However, it is very useful to avoid mile-post vs milepost even if the XML tools are clear that they are not the "same" thing.  The point we are making is that they ARE the same thing and we should call them, and use them, the same way in any namespace that needs that kind of element.  XML is actually getting in the way here, but no one is proposing to actually do anything other than have some expert look at a new element name to see if it is already in the registry and the same element name can be re-used to avoid complexity and confusion.
>
> Brian
>
> On Sep 10, 2010, at 6:12 PM, Winterbottom, James wrote:
>
>> Hi Ted,
>>
>> [AJW] I want to make really sure that I understand what you are saying here.
>> Are you suggesting that different jurisdictions are defining different CATypes, e.g. Jurisdiction A defines CAType[100]=lamp-post and jurisdiction B defines CAType[101]=lamppost?
>> This is the only kind of real overlap that I can see, and the draft indicates why continuing to extend CATypes has significant ramifications and should not be done.
>> This really only leaves the option of adding new elements into a new XML namespace.
>> Can we agree on this to start with?
>> Otherwise we are not starting from the same premise.
>>
>> Other comments inline...
>>
>>
>>
>> For what it is worth, that's not something I see in the discussion to
>> date at all.  The interoperability you achieve
>> with the xml namespace-based proposal without a registry is whatever
>> was initially standardized.  Each subsequent
>> jurisdiction that wants to add functionality does so independently.
>>
>> [AJW] Do you agree that it does it within the jurisdiction though, and that the jurisdiction likely has the ability to require conformance?
>>
>> I agree with Brian that this is likely to mean that
>> un-reviewed later additions will overlap (but likely not perfectly).
>> Since the sender doesn't know what the
>> receiver supports, the sender can't fix it by mapping to namespaces
>> that the receiver *does* understand.  That means
>> the end device that doesn't understand "mile-post" but would have
>> understood "milepost" can send it along,
>> but can't actually use the data.
>>
>> [AJW] Okay, I see what you are saying, but I think that there are a couple of over simplifications in your example.
>> The first is that if I have two namespaces urn:orga:civicextension and urn:orgb:civicextension, and both define milepost,
>> <milepost xlmns:urn:orga:civicextension/> is not the same as <milepost xlmns:urn:orgb:civicextension/>, one cane define it as an integer, the other a complex element, and someone else a token. This is a very local thing and it should be.
>> So what I am trying to say is that the base-part, that everyone needs to understand, is defined in the 5139 schema. Extensions are local, and that not everything will understand them, but they must not discard them. This will ensure that the information is used by things that can use it, even if intermediaries can't. This will mean that local applications will work, but that a foreign application may not get everything it wants. Emergency services as per ECRIT will work fine using the above method. Personally I think this is okay.
>>
>> I think having a registry here helps by identifying what has already
>> been covered and fosters interoperability.
>> Having a reviewer helps further, but making a first-come first-served
>> registry to help folks identify what
>> has already been done.  I really don't seen how that level of support
>> from the IETF could be considered
>> control.
>> [AJW] Because registry that Brian was proposing was a namespace registry, I didn't see a suggestion of also requiring them to register their schema extensions with the IETF. Even if they did, if the first come one had defined a lampost as a token within their namespace, and a second organization wanted to define a lamp-post as a token, for the second organization to pickup the first lamppost into their schema would result in a lot of unnecessary inclusions.
>>
>> So this leads back to my initial question of whether people understand the concern raise din the document about the continuing addition of more and more CATypes, and how this impacts things already specified and implemented.
>>
>> Cheers
>> James
>
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv