RFC 5222, "LoST: A Location-to-Service Translation Protocol", August 2008

Note: This RFC has been updated by RFC 6848, RFC 8917, RFC 9036

Errata ID: 2511
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Martin Thomson
Date Reported: 2010-09-07
Held for Document Update by: Robert Sparks
Date Held: 2011-09-14

Section 8.3.5, 8.4.2 says:

In 8.3.5:
     <locationValidation>
       <valid>country A1 A3 A6</valid>
       <invalid>PC</invalid>
       <unchecked>HNO</unchecked>
     </locationValidation>

In 8.4.2:
   ... Each element contains a list of tokens separated by
   whitespace, enumerating the civic location labels used in child
   elements of the <civicAddress> element.  ...
and:
   The example shown in Figure 5 and in Figure 6 indicates that the
   tokens 'country', 'A1', 'A3', and 'A6' have been validated by the
   LoST server.  ...

It should say:

In 8.3.5:
     <locationValidation
        xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
       <valid>ca:country ca:A1 ca:A3 ca:A6</valid>
       <invalid>ca:PC</invalid>
       <unchecked>ca:HNO</unchecked>
     </locationValidation>

In 8.4.2:
   ... Each element contains a list of qualified element names separated by
   whitespace, enumerating child elements of the <civicAddress> element.  ...
and:
   The examples shown in Figure 5 and in Figure 6 indicates that the
   tokens 'country', 'A1', 'A3', and 'A6' from [RFC5139] have been validated
   by the LoST server.  ...

Notes:

It's not clear from the description how the location validation response elements are to be interpreted. The example seems to indicate that the local name (only) for the civic address elements is used. On the other hand, the schema seems to imply that, because this is a list of xs:QName, a qualified name is used for each. The text itself is ambiguous.

----
This errata is being held for document update. The essence of its issue is being addressed in draft-ietf-geopriv-local-civic. There are two related threads in the ecrit archive. One beginning at
http://www.ietf.org/mail-archive/web/ecrit/current/msg07380.html
and one ending at
http://www.ietf.org/mail-archive/web/ecrit/current/msg07750.html


Using the local name only could result in errors - it would be possible (albeit inadvisable) to extend RFC 5139 with an element that had the same local name as an existing element or an element in another extension. As long as the namespace is distinct, this is perfectly legal, but it could lead to a naming conflict here.

With this interpretation, the elements in the example in 8.3.5 indicate elements from the LoST namespace (urn:ietf:params:xml:ns:lost1), rather than the civic address namespace (urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr).

Updating the description in 8.4.2 and the example in 8.3.5 would ensure that this doesn't result in interoperability problems.

Report New Errata