errata logo graphic

Found 3 records.

Status: Verified (2)

RFC4119, "A Presence-based GEOPRIV Location Object Format", December 2005

Source of RFC: geopriv (rai)

Errata ID: 1535

Status: Verified
Type: Technical

Reported By: Eduardo Cardona
Date Reported: 2008-10-03
Verifier Name: Robert Sparks
Date Verified: 2010-05-23

Section 2.2.2 says:

2.2.2.  'usage-rules' Element
   'retransmission-allowed': When the value of this element is 'no', the
      Recipient of this Location Object is not permitted to share the
      enclosed Location Information, or the object as a whole, with
      other parties.  When the value of this element is 'yes',


 snip.. 

 'retention-expires': This field specifies an absolute date at which
      time the Recipient is no longer permitted to possess the location

snip..
 'ruleset-reference': This field contains a URI that indicates where a
      fuller ruleset of policies, related to this object, can be found.

Notes:

Definitions do not match with the XML schema :

* boolean according to XML Schema Part 2: Datatypes Second Edition is either 'true', 'false', '0', or '1'

<xs:element name="retransmission-allowed" type="xs:boolean"
minOccurs="0" maxOccurs="1"/>

* Element names do not match

<xs:element name="retention-expiry" type="xs:dateTime"
minOccurs="0" maxOccurs="1"/>

<xs:element name="external-ruleset" type="xs:anyURI"
minOccurs="0" maxOccurs="1"/>


Errata ID: 1771

Status: Verified
Type: Editorial

Reported By: Martin Thomson
Date Reported: 2009-05-03
Verifier Name: Robert Sparks
Date Verified: 2010-05-23

Section 2.3 says:

 <presence xmlns="urn:ietf:params:xml:ns:pidf"
    xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
    xmlns:cl=" urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc"
    entity="pres:geotarget@example.com">
...
      <gp:usage-rules>
        <gp:retransmission-allowed>no</gp:retransmission-allowed>
        <gp:retention-expiry>2003-06-23T04:57:29Z</gp:retention-expiry>
      </gp:usage-rules>

It should say:

 <presence xmlns="urn:ietf:params:xml:ns:pidf"
    xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
    xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
    xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc"
    entity="pres:geotarget@example.com">
...
      <gp:usage-rules>
        <gbp:retransmission-allowed>no</gbp:retransmission-allowed>
        <gbp:retention-expiry>2003-06-23T04:57:29Z</gbp:retention-expiry>
      </gp:usage-rules>

Notes:

This applies to both examples in Section 2.3. The use of the "urn:ietf:params:xml:ns:pidf:geopriv10" namespace for the retransmission-allowed and retention-expiry elements is incorrect. These elements are defined in the "urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy" namespace.

This does not manifest in an error in parsers due to the allowance for extensions. The XML schema <any> rule with processContents="lax" permits unknown elements, as these are. A schema-aware processor would not reliably detect these elements, potentially leading to them being ignored.

To reveal this problem, validate these examples against a schema with processContents="strict" on all <any> elements.


Status: Rejected (1)

RFC4119, "A Presence-based GEOPRIV Location Object Format", December 2005

Source of RFC: geopriv (rai)

Errata ID: 827

Status: Rejected
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2005-12-21
Rejected by: Robert Sparks
Date Rejected: 2010-05-23

 

On mid-page 8, RFC 4119 specifies:
                                                     [...]  If the
    value in the 'retention-expires' element has already passed when
    the Location Recipient receives the Location Object, the Recipient
    MUST discard the Location Object immediately.

Now, RFC 4119 contains examples of Location Objects. Thus, the reader
of RFC 4119 (or his workstation) becomes a Location Recipient.
But those examples of Location Objects contained in RFC 4119 specify
a 'retention-expires' date that has passed *long before* the
publication of RFC 4119.
Therefore, every reader of RFC 4119, and every system receiving a
copy of RFC 4119, MUST immediately discard the RFC; moreover,
even the RFC editor SHOULD NOT ever have processed the draft!

But in this case, the above rule would not have become effective,
making these actions, creation and reading of the RFC, legitimate
again ...

It should say:

[see above]

Notes:

from pending

From the RAI reviewer: Strictly speaking, only the Location Objects contained in the RFC4119 MUST be discarded. Since this would only remove the examples from the RFC and not the specifiction, the RFC would remain effective, if somewhat less convenient to use.
--VERIFIER NOTES--


Report New Errata