Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02

[Alan DeKok <[e-mail]>]

> On May 2, 2017, at 5:29 PM, Dave Dolson <[e-mail]> wrote:
> 
> I guess the safest thing to do here is to continue to reference RFC2486 with END_USER_NAI in Subscription-Id-Type,
> and specify RFC7542 for the new Subscription-Id-NAI AVP.

  I would argue that there is no compatibility issues between RFC 7542 and RFC 2486.

  On top of that, referencing a document from 18 years ago which has been deprecated *twice* is probably a bad idea.

> Even though I suspect that in practice non-ASCII is being used in Subscription-Id-Type with END_USER_NAI.

  non-ASCII was forbidden by RFC 2486 Section 3.  It is allowed by RFC 4282, but I think that use-case is rare today.

  Responding to earlier messages in the thread:

> Following 3 issues are noted in appendix A of RFC4282:
>  
>    o  International character set support has been added for both
>       usernames and realms.  Note that this implies character codes 128
>       - 255 may be used in the username portion, which may be
>       unacceptable to nodes that only support RFC 2486.  Many devices
>       already allow this behaviour, however.
>  
>    o  Username privacy support has been added.  Note that NAIs without a
>       username (for privacy) may not be acceptable to RFC 2486-compliant
>       nodes.  Many devices already allow this behaviour, however.
>  
>    o  A recommendation to support NAI length of at least 253 octets has
>       been added, and compatibility considerations among NAI lengths in
>       this specification and various AAA protocols are discussed.  Note
>       that long NAIs may not be acceptable to RFC 2486-compliant nodes.
>  
> And from appendix A of RFC7542 (as you noted):
>  
> *  The formal syntax in Section 2.1 has been updated to forbid
>       non-UTF-8 characters (e.g., characters with the "high bit" set).
>  
> This means that there is incompatibility in both directions between RFC2486 and RFC7542.

  I think the issue is compatibility between 4282 and 7542.

> As I see it, operators require UTF-8 strings, and are probably already using them, so we should update the END_USER_NAI.

  Are any operators using non-UTF8 strings with the high bit set?  I would suggest that is rare to non-existent.

  It's one thing to use a non-standard character set within your private organization.   But as soon as you do roaming or other interoperation, UTF-8 is pretty much your only choice.

  Alan DeKok.