Found 1 record.
Errata ID: 2511
Status: Held for Document Update
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. ...
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
and one ending at
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