Subject: [Ecrit] Verifying errata 2511

From: Robert Sparks <[email-masked]>
Date: Thu, 4 Aug 2011 14:12:19 -0500

(note the crosspost - please reply only to [email-masked])

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)

---

From: Ted Hardie <[email-masked]>
Date: Thu, 4 Aug 2011 15:28:51 -0700

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 <[email-masked]> wrote:
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv
>
>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 4 Aug 2011 20:15:29 -0400

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:

> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: Ted Hardie <[email-masked]>
Date: Fri, 5 Aug 2011 14:56:26 -0700

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

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 5 Aug 2011 18:05:51 -0400

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

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 6 Aug 2011 06:18:50 +0800

I don't think that local-civic needs to update RFC5222, but I don't think that the examples in RFC5222 are correct either when it comes to the token shown in the validation examples. The schema clearly calls for a qualified name list, and the tokens in the examples are not suitably qualified. 

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: [email-masked] [[email-masked]] On Behalf Of Ted Hardie [[email-masked]]
Sent: Friday, August 05, 2011 4:56 PM
To: Richard L. Barnes
Cc: [email-masked]
Subject: Re: [Ecrit] [Geopriv] Verifying errata 2511

Howdy Richard,

RFC 5222 says:

Ted

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 6 Aug 2011 06:21:09 +0800

This just highlights the fact that we need to errata the examples because people are implementing from non-normative examples rather than from normative schema. 
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Rosen, Brian [[email-masked]]
Sent: Friday, August 05, 2011 5:05 PM
To: Ted Hardie
Cc: [email-masked]
Subject: Re: [Ecrit] [Geopriv] Verifying errata 2511

Brian

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 8 Aug 2011 08:22:24 +0800

> even when there is a single namespace.  I don't think it is.

The problem isn't that the example is ambiguous to you or I.  Machine interpretation of these elements is unable to make the sorts of inferences you are describing.

The type of each of these elements is clear:
  qnameList = list { xsd:QName* }

Say that I implement this in Java with JAXB.  The type of each of these elements (based on the schema) is java.util.List<javax.xml.namespace.QName>.  When I go looking to see if the "A3" element is valid, I would use something like:

   List<QName> valid = locationValidation.getValid();
   for (QName n : valid) {
      if (n.getNamespaceURI().equals("urn:...:civicAddr")
          && n.getLocalPart().equals("A3")) {
         return true;
      }
   }
   return false;

That wouldn't work with the example as it stands, because the value that my parser reads is {urn:ietf:params:xml:ns:lost1}:A3.

Another secondary benefit of the schema being as it is: noise is flagged as being in error.  The following would be picked up in parsing and validation unless the "foo" prefix was bound:

  <valid>foo:bar</valid>

--Martin

---

From: Robert Sparks <[email-masked]>
Date: Thu, 18 Aug 2011 16:48:25 -0500

Ted - with this argument, do you still think the errata is inappropriate?

Your suggestion for an example in local-civic is something we could do anyhow - does anybody think that would be a bad idea?

RjS