Subject: [radext] #163: Section 2.7

From: "radext issue tracker" <[email-masked]>
Date: Sun, 09 Jun 2013 00:27:50 -0000

#163: Section 2.7

 transported as "fred@example%2Ecom", whereas the NAI for that user is
    "[email-masked]".  Any comparison, validation, or use of the NAI
    MUST be done on its un-escaped (i.e. utf8-clean) form.

 [BA] This statement, while making some amount of sense, contradicts the
 statement in Section 2.6, which is that the NAI is always normalized prior
 to entering the AAA system.

 Really, what needs to be done here is to create a section that specifies
 what steps need to be taken in comparing NAI realms. Conversion to the
 UTF8-clean form would be a first (but not the only step).

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-radext-
  [email-masked]          |  [email-masked]
     Type:  defect                   |     Status:  new
 Priority:  critical                 |  Milestone:  milestone1
Component:  nai                      |    Version:  1.0
 Severity:  In WG Last Call          |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://wiki.tools.ietf.org/wg/radext/trac/ticket/163>
radext <http://tools.ietf.org/radext/>

---

From: "radext issue tracker" <[email-masked]>
Date: Sun, 09 Jun 2013 13:46:20 -0000

#163: Section 2.7

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

Comment:

 There is no contradiction.  The concept of "normalization" applies to
 taking unicode strings, and converting them to a NFC form.

 The concept of "escaping" applies to protocols which are not 8-bit clean,
 and which require certain input byte sequences to be replaced by other
 byte sequences prior to transport..

 Conversion to the UTF8-clean form is a process which is specific to each
 protocol.  e.g. data coming *out* of HTTP is un-escaped, according to the
 HTTP rules.  But that process is done by the HTTP layer.  The AAA layer
 has no idea where the NAI came from, and doesn't care.

 I'll clarify that in the document.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-ietf-radext-
  [email-masked]          |  [email-masked]
     Type:  defect                   |      Status:  closed
 Priority:  critical                 |   Milestone:  milestone1
Component:  nai                      |     Version:  1.0
 Severity:  In WG Last Call          |  Resolution:  fixed
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/163#comment:1>
radext <http://tools.ietf.org/radext/>