[netmod] types-011: multiple lexical representations

[Juergen Schoenwaelder <[e-mail]>]

Some types allow multiple representations of the same value. A good
example are IPv6 addresses, e.g. ::1 and 0:0:0:0:0:0:0:1. This raises
several questions:

1) We need to define how comparisions are done. At the interim, there
   was agreement that comparisons are done in the value space so the
   fact that there might be different lexical representations for the
   same value becomes a non-issue. (This needs to be confirmed on the
   mailing list.)

2) At the interim meeting, there was agreement to define normalization
   rules - the basic idea here is the following:

   a) implementations MUST accept normalized values as input
   b) implementations MUST generate normalized values as output
   c) implementations MAY accept non-normalized values as input

   In general, it was preferred that implementations do not have to
   remember the representation that was used to configure a value.  It
   should be sufficient to just store the value.  (This needs to be
   confirmed on the mailing list.)

3) There was no agreement how we write down normalization rules are the
   interim meeting. There are several options:

   (1) we simply add text to description statements

   (2) we introduce a separate statement with a separate description
       clause, e.g.

       normalization {
         description "turn all characters to lower case";
       }

   (3) we introduce a separate statement with a separate description
       clause and allow an additional pattern that can be more
       restrictive for normalized values, e.g.

       normalization {
         pattern "[a-z]";
	 description "normalized representation is in lower case";
       }

   In option (1) and (2), it remains unclear whether the retrictions
   (pattern etc.) associated with a type only cover the normalized
   representation or also other representations that implementations
   MAY allow. One option is to simply just define what MUST be allowed
   and leave everything else to the Postel principle (implementations
   may be lenient in what they accept). This will work for several
   types, but might not work for all of them.

4) I got the task to go over all definitions in the -type document to
   identify types that may need normalization rules.  I have done that
   and for each type we need to decide between the following options:

   (i)  we further restrict the lexical space so that we have a 1:1
        mapping of the lexical representation to the value space

   (ii) we define what the normalization rules are

   * date-and-time: 2008-10-26T10:35:00Z
                    2008-10-26T10:35:00+00:00

   * ipv4-address:  numeric versus textual zone index

   * ipv6-address:  shortened and mixed forms, zone index

   * ipv4-prefix:   unused bits (127.0.0.0/8 vs. 127.1.2.3/8)

   * ipv6-prefix:   shortened and mixed forms, unused bits

   * domain-name:   lower-case normalization, make this mandatory
                    like in the uri description statement?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/netmod