RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 4 records.

Status: Verified (2)

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

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

Source of RFC: ecrit (rai)

Errata ID: 4174
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Dan Banks
Date Reported: 2014-11-12
Verifier Name: Alissa Cooper
Date Verified: 2016-04-03

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: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Dan Banks
Date Reported: 2014-11-13
Verifier Name: Alissa Cooper
Date Verified: 2016-04-03

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.

Status: Held for Document Update (2)

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

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

Source of RFC: ecrit (rai)

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.

Errata ID: 4175
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Dan Banks
Date Reported: 2014-11-12
Held for Document Update by: Alissa Cooper
Date Held: 2015-11-01

Section 12.1 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'.

Report New Errata



Advanced Search