I don't think that it hurts to have an annex in local-civic that shows what a LoST query and validation response might look like, I would like to hear if anybody else is okay with approach before we update local-civic though since we have agreement to call a WGLC once the document is updated with the registry consensus.
Cheers
James
________________________________________
From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of Ted Hardie [ted.ietf@gmail.com]
Sent: Friday, August 05, 2011 4:56 PM
To: Richard L. Barnes
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] [Geopriv] Verifying errata 2511
Howdy Richard,
Your example is definitely better than the text in the erratum, but I
still don't think this is an erratum for RFC 5222.
RFC 5222 says:
The <valid> element enumerates those civic address elements that have
been recognized as valid by the LoST server and that have been used to
determine the mapping. The <unchecked> elements enumerates the civic
address elements that the server did not check and that were not used
in determining the response. The <invalid> element enumerate civic
address elements that the server attempted to check, but that did not
match the other civic address elements found in the <valid> list.
Civic location tokens that are not listed in either the <valid>
<invalid>, or <unchecked> element belong to the class of unchecked
tokens.
In the examples used in RFC 5222, there was only one namespace, so
there was no need for a disambiguation prefix for the elements. Even
in your example, the disambiguation occurs with a prefix only on one
of the two namespaces; the erratum appears to suggest it is required
even when there is a single namespace. I don't think it is.
A better approach here, at least in my opinion, would be to add a
locationValidation example to draft-ietf-geopriv-local-civic, to show
how it works when there are multiple namespaces. I don't think that
would require the draft to update RFC 5222--it's just an example, not
a substantive change (again, just my opinion). It's also far more
likely to be seen there than in an erraturm.
Ted
On Thu, Aug 4, 2011 at 5:15 PM, Richard L. Barnes <rbarnes@bbn.com> wrote:
> The confusion arises when you have civic address elements that originate from multiple namespaces, as in draft-ietf-geopriv-local-civic:
>
> <civicAddress xml:lang="en-GB"
> xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
> xmlns:cdc="http://devon.canals.org.uk/civic">
> <country>UK</country>
> <A1>Devon</A1>
> <A3>Monkokehampton</A3>
> <RD>Deckport</RD>
> <STS>Cross</STS>
>
> <cdc:bridge>21451338</cdc:bridge>
>
> </civicAddress>
>
>
> On Aug 4, 2011, at 6:28 PM, Ted Hardie wrote:
>
>> I don't think this is needed. If you look at the full response,
>> you'll see that this namespace is declared in reference to the
>> civicAddress in both the query and response:
>>
>> <civicAddress
>> xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
>> <country>DE</country>
>> <A1>Bavaria</A1>
>> <A3>Munich</A3>
>> <PC>81675</PC>
>> </civicAddress>
>>
>> The location ID is present in both as well, so I don't think there
>> should be much confusion about how the location validation response
>> elements are to be interepreted. They are specific to a location,
>> which already has a namespace attached.
>>
>> It may be that further text is required to make that even more clear,
>> but I don't think adding a namespace within the locationValidation
>> response itself is needed.
>>
>> regards,
>>
>> Ted
>>
>>
>>
>> On Thu, Aug 4, 2011 at 12:12 PM, Robert Sparks <rjsparks@nostrum.com> wrote:
>>> (note the crosspost - please reply only to ecrit@ietf.org)
>>> Please see <http://www.rfc-editor.org/errata_search.php?eid=2511>
>>> and thread on the Ecrit list titled
>>>
>>> Erratum report on erratum 2511 to RFC 5222 (LoST: A Location-to-Service
>>> Translation Protocol)
>>>
>>> which started Nov 23, 2010.
>>> Given the subsequent discussion of draft-ietf-geopriv-local-civic, I plan to
>>> mark this errata as
>>> Verified. If you don't think this is the correct thing to do, please let me
>>> know ASAP. If there are no
>>> replies, I will verify that errata next Thursday (11Aug)
>>> _______________________________________________
>>> 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
>
>
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
