Subject: Re: [AAA-WG]: Re: [issue] Bring back UTF8 datatype.

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 5 Jun 2001 17:12:14 +0200

Mark> Juergen,
Mark> 
Mark> Is the following acceptable.
Mark> 
Mark>  1. I renamed "AVP Data Formats" to "AVP Base Data Formats".

OK

Mark>  2. I created a new section, "AVP Derived Data Formats".

OK

Mark>  3. I stated that an AVP Derived Data Format MUST only be
Mark>     defined in one RFC.

I guess you mean "AVP Base Data Formats" here. With that assumption, OK.

Mark>  4. I stated that a new AVP Derived Data Format MUST be
Mark>     registered with IANA.  (This may be a little extreme.)

This at least ensures that you get unique names.

Mark>  5. I moved Address to the AVP Derived Data Formats.

OK

Mark>  6. I added a time format to the AVP Derived Data Formats.

OK

Mark>  7. I added UTF8String and used most of the explanation from
Mark>     your example to describe it.

OK

Mark>  8. Additionally, I specified that UTF8String MUST not contain
Mark>     an octet with a value of zero.

Note sure this is necessary - but see below.

Mark>  9. I added a DiameterIdentity format (formerly FQDN) to the AVP
Mark>     Derived Data Formats.

OK

Mark> 10. I added an Enumerated format to the AVP Derived Data
Mark>     Formats.

OK.

Mark> Below is the new text.  Is the basic idea getting closer to
Mark> respectable?  If so, any comments on the details?

Looks good. Below are some more detailed comments.

Mark>  OctetString
Mark>     The data contains arbitrary data of variable length. Unless
Mark>     otherwise noted, the AVP Length field MUST be set to at least 9
Mark>     (13 if the 'V' bit is enabled).  AVP Values of this type that
Mark>     do not align on a 32-bit boundary MUST have the necessary
Mark>     padding.

Note that the length should be 8 or 12 to allow for zero-length
strings (as noted already somewhere else).

Mark>  Unsigned32
Mark>     32 bit unsigned value, in network byte order. The AVP Length
Mark>     field MUST be set to 12 (16 if the 'V' bit is enabled).
Mark>     Unsigned32 values used to transmit time data contains the four
Mark>     most significant octets returned from NTP [18], in network byte
Mark>     order.

I suggest to remove the last sentence as it is irrelevant for
understanding what an Unsigned32 value looks like.

Mark>  Address
Mark>  	  The Address format is derived from the OctetString AVP Base 
Mark>     Format. It represents 32 bit (IPv4) [17] or 128 bit (IPv6)
Mark>     [16] address, most significant octet first. The format of the
Mark>     address (IPv4 or IPv6) is determined by the length. If the
Mark>     attribute value is an IPv4 address, the AVP Length field MUST
Mark>     be 12 (16 if 'V' bit is enabled), otherwise the AVP Length
Mark>     field MUST be set to 24 (28 if the 'V' bit is enabled) for
Mark>     IPv6 addresses.

Perhaps this should be called IpAddress to make it clearer that it is
restricted to IP addresses. Another question is whether Diameter will
ever have to deal with scoped IPv6 addresses which require another 4
bytes to make them unique in a given domain (scope identifier). RFC
2851 has take the approach to allow 16 or 20 bytes for an IPv6
address.

Mark>  UTF8String
[...]

Mark> 	  The UTF8String MUST not contain any octets with a value of 
Mark>     zero.

I am not sure this is needed since you already have this:

Mark>     Since additional code points are added by amendments to the
Mark>     10646 standard from time to time, implementations MUST be
Mark>     prepared to encounter any code point from 0x00000001 to
Mark>     0x7fffffff.  Byte sequences that do not correspond to the
Mark>     valid UTF-8 encoding of a code point or are outside this
Mark>     range are prohibited.

I am not a UTF-8 expert but it appears to me (from reading RFC 2279)
that the UTF-8 encoding can only contain a 0x00 byte if the code point
is actually 0x00000000. But I might be wrong on this.

Mark>  Enumerated
Mark>     Enumerated is Derived from the Unsigned32 AVP Base Format.
Mark>     This contains a list of valid values and their interpretation 
Mark>     and is described in the Diameter application introducing the AVP.

I personally would allow negative enumerated values (which is
consistent with the SMIv2/SMIng and XDR) and thus I would use
Integer32 as the AVP base format here. There remaining range of
positive numbers should still be large enough to hold real-world
enumerated values.

---

From: Mark Eklund <[email-masked]>
Date: Tue, 5 Jun 2001 11:53:40 -0400 (EDT)

Juergen,

> I guess you mean "AVP Base Data Formats" here. With that assumption, OK.

Correct

> strings (as noted already somewhere else).

Agreed.

> understanding what an Unsigned32 value looks like.

Agreed.

> 2851 has take the approach to allow 16 or 20 bytes for an IPv6

Good point.  I'll leave the above as is for now, but create a
new issue concerning the above.

> is actually 0x00000000. But I might be wrong on this.

I'm no expert either.  I'd like to explicitely state that no
octet may contain a 0x00 byte.  I agree the statement is
redundant.  How about I change and move the statement to be the
last sentence in the below paragraph.

    Since additional code points are added by amendments to the
    10646 standard from time to time, implementations MUST be
    prepared to encounter any code point from 0x00000001 to
    0x7fffffff.  Byte sequences that do not correspond to the
    valid UTF-8 encoding of a code point or are outside this
    range are prohibited.  Note that since a code point of
    0x00000000 is prohibited, no octet will contain a value of
    0x00.

> positive numbers should still be large enough to hold real-world

Good point.  Making it an Integer32 is fine by me.

-mark

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 5 Jun 2001 17:57:40 +0200

>>>>> Mark Eklund writes:

Mark> I'm no expert either.  I'd like to explicitely state that no
Mark> octet may contain a 0x00 byte.  I agree the statement is
Mark> redundant.  How about I change and move the statement to be the
Mark> last sentence in the below paragraph.

Mark>     Since additional code points are added by amendments to the
Mark> 10646 standard from time to time, implementations MUST be
Mark> prepared to encounter any code point from 0x00000001 to
Mark> 0x7fffffff.  Byte sequences that do not correspond to the valid
Mark> UTF-8 encoding of a code point or are outside this range are
Mark> prohibited.  Note that since a code point of 0x00000000 is
Mark> prohibited, no octet will contain a value of 0x00.

Looks good to me.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

---

From: Patrice Calhoun <[email-masked]>
Date: Tue, 5 Jun 2001 09:10:44 -0700 (PDT)

Mark,

Could you please update the text to include Juergen's comments and resend to
the list? I would then include the text into the base protocol spec.

PatC

---

From: Mark Eklund <[email-masked]>
Date: Tue, 5 Jun 2001 17:46:49 -0400 (EDT)

Pat, 
Below are the changes with Juergen's suggestions.
-mark

4.3  AVP Base Data Format

   The Data field is zero or more octets and contains information
   specific to the Attribute. The format and length of the Data field is
   determined by the AVP Code and AVP Length fields. The format of the
   Data field MUST be one of the following base data types or a data
   type derived from the base data types.  In the event that a new
   AVP Base Data Format is needed, a new version of this RFC must be
   created.

      OctetString
         The data contains arbitrary data of variable length. Unless
         otherwise noted, the AVP Length field MUST be set to at least 8
         (12 if the 'V' bit is enabled).  AVP Values of this type that
         do not align on a 32-bit boundary MUST have the necessary padding.

      Integer32
         32 bit signed value, in network byte order. The AVP Length
         field MUST be set to 12 (16 if the 'V' bit is enabled).

      Integer64
         64 bit signed value, in network byte order. The AVP Length
         field MUST be set to 16 (20 if the 'V' bit is enabled).

      Unsigned32
         32 bit unsigned value, in network byte order. The AVP Length
         field MUST be set to 12 (16 if the 'V' bit is enabled).

      Unsigned64
         64 bit unsigned value, in network byte order. The AVP Length
         field MUST be set to 16 (20 if the 'V' bit is enabled).

      Float32
         This represents floating point values of single precision as
         described by [30].  The 32 bit value is transmitted in network
         byte order. The AVP Length field MUST be set to 12 (16 if the
         'V' bit is enabled).

      Float64
         This represents floating point values of double precision as
         described by [30].  The 64 bit value is transmitted in network
         byte order. The AVP Length field MUST be set to 16 (20 if the
         'V' bit is enabled).

      Float128
         This represents floating point values of quadruple precision as
         described by [30].  The 128 bit value is transmitted in network
         byte order. The AVP Length field MUST be set to 24 (28 if the
         'V' bit is enabled).

      Grouped
         The Data field is specified as a sequence of AVPs.  Each of
         these AVPs follows - in the order in which they are specified -
         including their headers and padding.  The AVP Length field is
         set to 8 (12 if the 'V' bit is enabled) plus the total length
         of all included AVPs, including their headers and padding.

4.4 AVP Derived Data Formats
      In addition to the AVP Base Data Formats, applications may define
      data formats derived from the AVP Base Data Formats.  New AVP Derived 
      Data Formats MUST be registered with IANA.  A derived Data Format
      can only be defined in one active (non-obsolete) RFC.

      An application that uses AVP Derived Data Formats other than those
      defined in the base protocol MUST have a section "AVP Derived Data
      Formats" that includes each of these formats.  In that section, 
      each format is either defined or listed with a reference to the
      RFC that defines this format.  If the AVP Derived Data Format is
      defined, it SHOULD use a format similar to the format
      definitions below.

      The below AVP Derived DATA Formats are commonly used by applications.
      
      Address
	 The Address format is derived from the OctetString AVP Base 
         Format. It represents 32 bit (IPv4) [17] or 128 bit (IPv6)
         [16] address, most significant octet first. The format of the
         address (IPv4 or IPv6) is determined by the length. If the
         attribute value is an IPv4 address, the AVP Length field MUST
         be 12 (16 if 'V' bit is enabled), otherwise the AVP Length
         field MUST be set to 24 (28 if the 'V' bit is enabled) for
         IPv6 addresses.
      
      Time
         The Time format is derived from the Unsigned32 AVP Base
	 Format.  This is 32 bit unsigned value containing the four
         most significant octets returned from NTP [18], in network byte
         order.
	 
	 This represent the number of seconds since 0h on 1 January
	 1900 with respect to the Coordinated Universal Time (UTC).

	 On 6h 28m 16s UTC, 7 February 2036 the time value will overflow.
	 NTP [18] describes a procedure to extend the time to 2104.
      
      UTF8String
	 The UTF8String format is derived from the OctetString AVP
         Base Format.  This is a human readable string represented
         using the ISO/IEC IS 10646-1 character set, encoded as an
         OctetString using the UTF-8 [29] transformation format
         described in RFC 2279.

         0x00000000 is prohibited, no octet will contain a value 
         of 0x00.

	 The use of control codes SHOULD be avoided. When it is
         necessary to represent a newline, the control code sequence
         CR LF SHOULD be used.

         The use of leading or trailing white space SHOULD be avoided.

         For code points not directly supported by user interface
         hardware or software, an alternative means of entry and
         display, such as hexadecimal, MAY be provided.

	 For information encoded in 7-bit US-ASCII, the UTF-8
         encoding is identical to the US-ASCII encoding.

         UTF-8 may require multiple bytes to represent a single
         character / code point; thus the length of a UTF8String in
         octets may be different from the number of characters
         encoded.

         Note that the size of an UTF8String is measured in octets,
         not characters."

	 The UTF8String MUST not contain any octets with a value of 
         zero.

      DiameterIdentity
	 The DiameterIdentity format is derived from the OctetString AVP
         Base Format.  It uses the UTF-8 encoding and has the same
	 requirements as the UTF8String.  In addition, it must follow
         the Uniform Resource Identifiers (URI) syntax [29] rules specified 
         below:

          Diameter-Identity  = [protocol] fqdn [ port ]
                               [ transport ]

          protocol-name      = ( "diameter" | "radius" | "tacacs+" )

          protocol           = protocol-name "://"
          ; If absent, the default is "diameter://"

          fqdn               = Fully Qualified Host Name

          port               = ":" 1*DIGIT
          ; If absent, the default Diameter port (TBD) is assumed.

          transport          = ";transport=" ( "tcp" | "sctp" | "udp")
          ; If absent, the default SCTP [26] protocol is assumed.
          ; UDP is ONLY used when the protocol is set to RADIUS

       The following are examples of valid Diameter host identities:

          host.abc.com:6666;transport=tcp
          diameter://host.abc.com
          diameter://host.abc.com:6666
          diameter://host.abc.com;transport=tcp
          diameter://host.abc.com:6666;transport=tcp
          radius://host.abc.com:1813;transport=udp

      Enumerated
         Enumerated is Derived from the Integer32 AVP Base Format.
         This contains a list of valid values and their interpretation 
         and is described in the Diameter application introducing the AVP.