Subject: [Ecrit] Erratum report on erratum 2511 to RFC 5222 (LoST: A Location-to-Service Translation Protocol)

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 23 Nov 2010 13:39:42 -0500

======================================================================
RFC5222, "LoST: A Location-to-Service Translation Protocol"
Source of RFC: ecrit (rai)

Errata ID: 2511

Status: Reported
Type: Technical

Reported By: Martin Thomson
Date Reported: 2010-09-07

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 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.
----------------------------------------------------------------------
Recommended status:  I think the erratum is incorrect, but the matter
needs serious consideration in the WG.

As the erratum notes say, it's not clear from the RFC text how the
<valid>, etc., elements are to be interpreted.  The examples, what
seems natural to me, and how I expect people to implement, suggest
that the element content is a whitespace-separated list of the
"LocalParts" of the child elements of <locationValidation> -- that is,
<valid> would contain "A1" even if <valid> had an explicit namespace
qualifier.  But the schema in the RFC explicitly says that the elements
are QNames.  Now that latter may be an error (and the schema is
labeled non-normative), and also all LocalParts are QNames.  But the
implication of the fact that QNames are allowed is that the values in
<valid> are to be interpreted as namespace-qualified.

However, if the values in <valid> are namespace-qualified, the example
of Figure 6 becomes invalid, as the A1, etc., elements are in
namespace "urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" whereas
the default namespace at the point of <valid> is
"urn:ietf:params:xml:ns:lost1".  Fixing that requires the changes
listed in the erratum.  I suspect these changes would propagate into
almost all existing implementations.

But if we interpret the values as not namespace-qualified, that places
certain limitations on future extensibility, as extension elements of
<civicAddress> would have to have distinct LocalParts even if they
were in different namespaces.

This ambiguity needs to be clarified in one way or another, as it
affects interoperability.

There appears to have been some discussion of this problem in the
Geopriv working group.
======================================================================

Dale

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 24 Nov 2010 11:27:19 +0800

This is a sound analysis, with one small, but significant exception:

The analysis relies on the premise that the schema is non-normative:

> ... Now that latter may be an error (and the schema is
> labeled non-normative), ...

This is only true of the schema in the appendices.  I assume that the RelaxNG schema in Section 15 is normative in the absence of statements to the contrary.

Regardless, achieving interoperability in the presence of extensions to the civic address format based solely on the RFC text is difficult - hence the technical erratum.

--Martin

On 2010-11-24 at 05:39:42, Worley, Dale R (Dale) wrote:
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 24 Nov 2010 09:35:58 -0500

________________________________________
From: Thomson, Martin [[email-masked]]

Ugh, that is an error on my part.  Yes, clearly the schema in section 15 is normative.

Unfortunately, I think this problem is beyond "errata" but rather is an inconsistency in the design, and there is no clearly correct resolution.  Hence my desire to return it to the WG.

Dale

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 25 Nov 2010 05:49:38 +0800

On 2010-11-25 at 01:35:58, Worley, Dale R (Dale) wrote:
> Unfortunately, I think this problem is beyond "errata" but rather is an
> inconsistency in the design, and there is no clearly correct
> resolution.  Hence my desire to return it to the WG.

I can't argue with that.  We definitely need to discuss this further.  Probably discuss along with the resolution to the GEOPRIV question.

--Martin