IETF Logo Mail Archive

Re: [radext] I-D Action: draft-ietf-radext-nai-02.txt

Emile van Bergen <emile@e-advies.nl> Wed, 20 March 2013 08:40 UTC

Return-Path: <emile@e-advies.nl>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE0E21F8675 for <radext@ietfa.amsl.com>; Wed, 20 Mar 2013 01:40:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.504
X-Spam-Level:
X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdeHgsU9W5Hv for <radext@ietfa.amsl.com>; Wed, 20 Mar 2013 01:40:57 -0700 (PDT)
Received: from host.e-advies.nl (host.e-advies.nl [93.174.104.94]) by ietfa.amsl.com (Postfix) with SMTP id D7E1621F8A64 for <radext@ietf.org>; Wed, 20 Mar 2013 01:40:56 -0700 (PDT)
Received: (qmail 31965 invoked by uid 33); 20 Mar 2013 08:40:53 -0000
To: Stefan Winter <stefan.winter@restena.lu>
X-PHP-Originating-Script: 0:func.inc
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Date: Wed, 20 Mar 2013 09:40:53 +0100
From: Emile van Bergen <emile@e-advies.nl>
In-Reply-To: <51497429.9090607@restena.lu>
References: <20130128155031.8392.45953.idtracker@ietfa.amsl.com> <5147172F.8090100@restena.lu> <08fd01ce23f5$cf8d0b90$6ea722b0$@augustcellars.com> <tslfvzsvd24.fsf@mit.edu> <091f01ce240a$6705a860$3510f920$@augustcellars.com> <51476C2C.5070000@deployingradius.com> <5148192B.90507@restena.lu> <514868A0.2040207@deployingradius.com> <5148822F.5070708@restena.lu> <5148A6FB.9050807@deployingradius.com> <51497429.9090607@restena.lu>
Message-ID: <a57bcde8fb3b0cf818a8f9fa854ca159@localhost>
X-Sender: emile@e-advies.nl
User-Agent: RoundCube Webmail/0.3.1
X-Mailman-Approved-At: Wed, 20 Mar 2013 05:39:37 -0700
Cc: radext@ietf.org
Subject: Re: [radext] I-D Action: draft-ietf-radext-nai-02.txt
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Mar 2013 08:41:57 -0000

Hi,

On Wed, 20 Mar 2013 09:32:41 +0100, Stefan Winter
<stefan.winter@restena.lu> wrote:

> Great. I think an extra sentence in addition to the above should make
> this fit nicely:
> 
> "See [RFC5198] and section 2.6 of this specification for a discussion of
>  normalization. Strings which are not in Normal Form Composed (NFC) are
>  not valid NAIs and SHOULD NOT be treated as such.
> 
>  Implementations which expect to receive a NAI, but get non-normalised
>  (but otherwise valid) UTF-8 strings instead SHOULD attempt to normalise
>  the input to NFC for local processing."
> 
> ?

I read these as two slightly conflicting clauses, both written from the
receiver's viewpoint. 

I've often found the way that IETF documents dissect 'validity' into
separate requirements for senders and receivers. How about:

 "See [RFC5198] and section 2.6 of this specification for a discussion of
  normalization. Strings which are not in Normal Form Composed (NFC) are
  not valid NAIs and MUST NOT be sent by compliant implementations.
 
  Implementations which expect to receive a NAI, but get non-normalised
  (but otherwise valid) UTF-8 strings instead SHOULD attempt to normalise
  the input to NFC for local processing."

Following Jon Postel's "be conservative in what you send, be liberal in
what you accept"?

Kind regards,


Emile van Bergen.

v2.46.0 | Report a Bug | By Email | System Status