On Mon, Apr 29, 2019 at 02:53:40PM +0000, Rob Wilton (rwilton) wrote: > > My aim with this text is to: > - encourage clients to use canonical format, since that seems to cause the > least problems. > - align the v4 and v6 definitions. > - retain the existing flexibility for servers to choose what they support, > noting that any change in behaviour here will be non-backwards compatible. >
The 'should' text is of limited value since the 'should' text does not change what is allowed. I hope the newly proposed text spells out more clearly that a server turns values into canonical format that are not in canonical format and implementors can then conclude that using canonical format in the first place is perhaps a good idea - or it is convenient to have the conversion done by the server. Note that the canonical format for IPv6 prefixes has much more to it than setting the non-prefix bits to zero, see RFC 5952 for all the details that affect the text representation of the address part. I believe we are not in the position to tell clients that they should or should not do. If I push the config value 2001:DB8::/64 (since my database has values stored using uppercase characters) and it comes back as 2001:db8::/64, then so be it; it might be convenient for me to be allowed to push 2001:0DB8:0:0:0:0:0:0/64 and not having to worry about how to produce the RFC 5952 representation in my glue code that ties into my database backend. Why would we say clients should not send values in non-canonical format? Why would we say clients have to take the pain to ensure everything is turned into 2001:db8::/64 (to continue the example) before sending values to the server? Note that the ipv6-address definition has the same canonicalization properties (if we consider the address portion of ipv6-prefix) and there is no text saying you should send 2001:db8::1 instead of 2001:0DB8::1. I think our mission instead is to make it clear what the canonical format is and that servers will turn lexical representations they accept into canonical lexical representation. This way people can take informed decisions about what is appropriate for their specific clients. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
