Friday, August 5, 2011

Re: [Ecrit] [Geopriv] Verifying errata 2511

Also, there are implementations that do it the way the text currently illustrates, and it works, so this would require them to change, for little gain.

While I would have preferred that we handled this better in 5222, I'm with Ted here.

Brian

On Aug 5, 2011, at 5:56 PM, Ted Hardie wrote:

> 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