OASIS eXtensible Access Control Markup Language (XACML) TC

New Issue: Hierarchical Profile rfc 2396 is obsolete and shouldbe updated to rfc 3986 instead

  • 1.  New Issue: Hierarchical Profile rfc 2396 is obsolete and shouldbe updated to rfc 3986 instead

    Posted 10-14-2009 15:15
    
    
    
    
    According to the IETF stds directory rfc2396 has been obsoleted by
    RFC3986:
    http://www.ietf.org/download/rfc-index.txt
    2396 Uniform Resource Identifiers (URI): Generic Syntax. T.
         Berners-Lee, R. Fielding, L. Masinter. August 1998. (Format:
         TXT=83639 bytes) (Obsoleted by RFC3986) (Updates RFC1808, RFC1738)
         (Updated by RFC2732) (Status: DRAFT STANDARD)
      
    Suggest we update the Hierarchical Profile 3.0 with RFC3986 in refs section and a number of places in the doc that refs it. The entry for rfc 3986 in above directory says:
    3986 Uniform Resource Identifier (URI): Generic Syntax. T.
         Berners-Lee, R. Fielding, L. Masinter. January 2005. (Format:
         TXT=141811 bytes) (Obsoletes RFC2732, RFC2396, RFC1808) (Updates
         RFC1738) (Also STD0066) (Status: STANDARD)
      
    I don't believe there are any changes in 3986 that impact the current spec.

    However, there are a few minor spelling corrections (multiple instances of missing 2nd 'r' in 'hierarchical') in section 2.2.

    Also, I recommend changing lines 208-210 (actually only change is on 210), which currently say:
    Hierarchical URIs with slashes are of the following form.
    <scheme> “://” <authority> “/” <pathname>
    To:
    Hierarchical URIs with slashes are of the following form.
    <scheme> “://” [<authority>] “/” [<pathname>]
    where the brackets around authority and pathname more accurately reflect the fact that these variables may be empty. This also utilizes the syntax usage that is specified in the Terminology section lines 158-160 and is consistent with the usage of brackets on line 216, which would mean that if a pathname is present it must include a non-empty rootname.

    (However, I suppose one could argue that a variable that can be empty is not the same as one that is optional, but I think that would be more likely to be confusing than saying a variable that can be empty is effectively optional.)

        Thanks,
        Rich