Re: Remaining open issues for RFC-2401bis

[Paul Hoffman / VPNC <paul.hoffman@vpnc.org>]

At 11:15 PM -0500 3/19/04, Bill Sommerfeld wrote:
>  >	Well, if we allow this to be any octet string,
>>	then it presents complications for the user/management
>>	interface.  So we'd like to limit it to a text string
>>	containing alphanumeric characters, but not a binary
>>	string, etc.
>
>current best practice for ietf protocols is that strings which are
>intended for human display in protocols should come with language
>tags.  (why do I know?  sshv2 bit this bullet a while ago...).  see
>rfc3066

That is a mis-reading of RFC 3066. RFC 3066 shows how to do it if 
there is a need for using different languages: it does *not* 
recommend adding language tags to any particular text. Language tags 
should be used on free text that is meant to be read and understood 
by a reader where the ambiguity might cause problems. That is not 
true for names.

Having said that, if we have a field that is supposed to handle 
human-generated names such as "account names" (the words used in 
IKEv2), it needs to handle the names of people whose language is 
other than English. IKEv2 says "octet stream", and it means "octet 
stream"; it does not mean "octet stream where we impose this 
particular text encoding and then limit it further by saying which 
characters are and are not allowed".

This is an exact-lookup field; if the user/management interface can't 
handle all values that might appear, that is a problem with the 
interface, not the protocol.

--Paul Hoffman, Director
--VPN Consortium