RFC Errata


Errata Search
 
Source of RFC  
Summary Table Full Records

Found 2 records.

Status: Verified (1)

RFC 4745, "Common Policy: A Document Format for Expressing Privacy Preferences", February 2007

Source of RFC: geopriv (rai)

Errata ID: 1455
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Chris Newman
Date Reported: 2008-06-16
Verifier Name: Cullen Jennings
Date Verified: 2009-01-08

Section 7.4 says: 

   pair.  Times are expressed in XML dateTime format.

It should say:

   pair.  Times are expressed in XML dateTime [W3C-Schema] format with a
   mandatory timezone.

Notes:

The reference to W3C Schema is normative. The timezone needs to be mandatory
in order to ensure interoperability. An alternative would be to reference
RFC 3339 normatively.

Status: Reported (1)

RFC 4745, "Common Policy: A Document Format for Expressing Privacy Preferences", February 2007

Source of RFC: geopriv (rai)

Errata ID: 5208
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Randall Gellens
Date Reported: 2017-12-14

Section 7 says: 

   The access to data items needs to be matched with the rule set stored
   at the PS.  Each instance of a request has different attributes
   (e.g., the identity of the requestor) that are used for
   authorization.  A rule in a rule set might have a number of
   conditions that need to be met before executing the remaining parts
   of a rule (i.e., actions and transformations).  Details about rule
   matching are described in Section 10.  This document specifies only a
   few conditions (i.e., identity, sphere, and validity).  Further
   condition elements can be added via extensions to this document.  If
   a child element of the <conditions> element is in a namespace that is
   not known or not supported, then this child element evaluates to
   FALSE.

It should say:

   The access to data items needs to be matched with the rule set stored
   at the PS.  Each instance of a request has different attributes
   (e.g., the identity of the requestor) that are used for
   authorization.  A rule in a rule set might have a number of
   conditions that need to be met before executing the remaining parts
   of a rule (i.e., actions and transformations).  Details about rule
   matching are described in Section 10.  This document specifies only a
   few conditions (i.e., identity, sphere, and validity).  Further
   condition elements can be added via extensions to this document.  If
   a child element of the <conditions> element is in a namespace that is
   not known or not supported, then this child element evaluates to
   FALSE.  A rule without a <conditions> element evaluates to TRUE.
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

(Only change is new sentence at end.)

Notes:

The schema in RFC 4745 (Common Policy: A Document Format for Expressing Privacy Preferences) allows the <conditions> element to be omitted. The RFC should say that omitted <conditions> evaluates to TRUE, as the alternative (omitted <conditions> evaluating to FALSE) makes no sense. Omitted <conditions> as TRUE allows for a rule that is always executed, while evaluating as FALSE would create a rule that is never executed, a meaningless thing.

Report New Errata



Advanced Search