Subject: [Ecrit] [Technical Errata Reported] RFC5222 (2511)

From: RFC Errata System <[email-masked]>
Date: Tue, 7 Sep 2010 22:24:40 -0700 (PDT)

The following errata report has been submitted for RFC5222,
"LoST: A Location-to-Service Translation Protocol".

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

--------------------------------------
Type: Technical
Reported by: Martin Thomson <[email-masked]>

Section: 8.3.5, 8.4.2

Original Text
-------------
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.  ...

Corrected Text
--------------
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 example 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.

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.

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. 

--------------------------------------
RFC5222 (draft-ietf-ecrit-lost-10)
--------------------------------------
Title               : LoST: A Location-to-Service Translation Protocol
Publication Date    : August 2008
Author(s)           : T. Hardie, A. Newton, H. Schulzrinne, H. Tschofenig
Category            : PROPOSED STANDARD
Source              : Emergency Context Resolution with Internet Technologies
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG