errata logo graphic

Found 4 records.

Status: Reported (3)

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

Source of RFC: ecrit (rai)

Errata ID: 4174

Status: Reported
Type: Technical

Reported By: Dan Banks
Date Reported: 2014-11-12

Section 15 & Apdx A says:

In section 15, the Exception pattern says (in part):
  locationProfileUnrecognized =
    element locationProfileUnrecognized {
      attribute unsupportedProfiles { xsd:NMTOKENS },
      basicException
    }

The corresponding section in Appendix A says:
       <define name="locationProfileUnrecognized">
         <element name="locationProfileUnrecognized">
           <attribute name="unsupportedProfiles">
             <data type="NMTOKENS"/>
           </attribute>
           <ref name="basicException"/>
         </element>
       </define>

It should say:

Section 15 should say:
  locationProfileUnrecognized =
    element locationProfileUnrecognized {
      basicException
    }

Appendix A should say:
       <define name="locationProfileUnrecognized">
         <element name="locationProfileUnrecognized">
           <ref name="basicException"/>
         </element>
       </define>

Notes:

The ‘unsupportedProfiles’ attribute is not referenced anywhere else in the text of the document; no instruction is given describing the use of this attribute. This, by itself, is problematic. However, based on the type, it seems reasonable that the intent may have been to list the location profiles which the server is unable to understand.

Consider the condition under which the ‘locationProfileUnrecognized’ error is returned (section 12.1):
8. If a server receives a request that only contains location
information using profiles it does not understand, the server
responds with a <locationProfileError>

If none of the locations include the optional ‘profile’ attribute, the server may not be able to identify any of the profiles and therefore would be incapable of returning a list of profile names. This is especially problematic considering that the ‘unsupportedProfiles’ attribute is required by the schema.

Even in cases where one or more locations include the profile attribute, the client already knows what profiles were used in the request, so returning a list of these profiles does not provide new information to the client.

At best, use of the ‘unsupportedProfiles’ attribute appears to be redundant; at worst, it is impossible. Therefore, the suggested course of action is to remove the attribute from the schema.


Errata ID: 4176

Status: Reported
Type: Technical

Reported By: Dan Banks
Date Reported: 2014-11-13

Section 15 & Apdx A says:

Section 15:  

exceptionContainer =
    (badRequest?
     & internalError?
     & serviceSubstitution?
     & defaultMappingReturned?
     & forbidden?
     & notFound?
     & loop?
     & serviceNotImplemented?
     & serverTimeout?
     & serverError?
     & locationInvalid?
     & locationProfileUnrecognized?),
    extensionPoint,
    source

And:

  serverError = element serverError { basicException }
  locationInvalid = element locationInvalid { basicException }

Appendix A:

           <optional>
             <ref name="serverError"/>
           </optional>
           <optional>
             <ref name="locationInvalid"/>
           </optional>

And:

       <define name="serverError">
         <element name="serverError">
           <ref name="basicException"/>
         </element>
       </define>

       <define name="locationInvalid">
         <element name="locationInvalid">
           <ref name="basicException"/>
         </element>
       </define>

It should say:

Section 15:  

exceptionContainer =
    (badRequest?
     & internalError?
     & serviceSubstitution?
     & defaultMappingReturned?
     & forbidden?
     & notFound?
     & loop?
     & serviceNotImplemented?
     & serverTimeout?
     & serverError?
     & SRSInvalid?
     & locationInvalid?
     & locationProfileUnrecognized?),
    extensionPoint,
    source

And:

  serverError = element serverError { basicException }
  SRSInvalid = element SRSInvalid { basicException }
  locationInvalid = element locationInvalid { basicException }

Appendix A:

           <optional>
             <ref name="serverError"/>
           </optional>
           <optional>
             <ref name="SRSInvalid"/>
           </optional>
           <optional>
             <ref name="locationInvalid"/>
           </optional>

And:

       <define name="serverError">
         <element name="serverError">
           <ref name="basicException"/>
         </element>
       </define>

       <define name="SRSInvalid">
         <element name="SRSInvalid">
           <ref name="basicException"/>
         </element>
       </define>

       <define name="locationInvalid">
         <element name="locationInvalid">
           <ref name="basicException"/>
         </element>
       </define>

Notes:

The SRSInvalid error is defined in section 13.1, but was omitted from the schemas.


Errata ID: 4175

Status: Reported
Type: Editorial

Reported By: Dan Banks
Date Reported: 2014-11-12

Section 12.1 Fig 15 says:

     <location id="DEF 345" profile="geodetic-2d">
       <gml:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
         <gml:pos>42.656844 -73.348157</gml:pos>
       </gml:Point>
     </location>

It should say:

     <location id="DEF 345" profile="geodetic-2d">
       <gml:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">
         <gml:pos>42.656844 -73.348157</gml:pos>
       </gml:Point>
     </location>

Notes:

The 'srsName' in the location provided as part of example in Figure 15 is missing a required ':' between 'EPSG' and '4326'.


Status: Held for Document Update (1)

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

Source of RFC: ecrit (rai)

Errata ID: 2511

Status: Held for Document Update
Type: Technical

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