Subject: [radext] #172: i18n review for closure of NFC form

From: "radext issue tracker" <[email-masked]>
Date: Mon, 04 Nov 2013 21:28:22 -0000

#172: i18n review for closure of NFC form

 Q: can the proxy normalize utf-8 to NFC?

 If so, under what circumstances?  If not, what circumstances?

 The current assumption is:

 - if supplicant and proxy are same unicode version, YES, the proxy can
 always create NFC

 - if supplicant is NEWER unicode version than proxy, then MAYBE sometimes
 the proxy can create NFC.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-radext-
  [email-masked]          |  [email-masked]
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:
Component:  nai                      |    Version:
 Severity:  -                        |   Keywords:
-------------------------------------+-------------------------------------

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

---

From: "radext issue tracker" <[email-masked]>
Date: Tue, 05 Nov 2013 01:49:00 -0000

Comment (by [email-masked]):

 Sam and I talked with Pete Resnick this afternoon.  The summary is this:

 - the end user machine (e.g. supplicant) SHOULD normalize the realm for
 the NAI.  Only it has the information necessary to determine the users
 intent

 - intermediate proxies *may* be able to normalize the realm.  The IDNA
 mappings document describes some of these normalizations.  However, this
 normalization is not always possible.

 - if the realm cannot be normalized, there's nothing the proxy can do.  It
 has an identifier which is an opaque blob, and which may not match any
 realm it knows about.

 - we should reference also the precis documents which talk about these
 issues.

 Severity:  -                        |  Resolution:
 Keywords:                           |

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

---

From: "radext issue tracker" <[email-masked]>
Date: Thu, 07 Nov 2013 00:34:28 -0000

Changes (by [email-masked]):

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

Comment:

 Fixed by updated text in -05.

 On further examination, the precis documents don't seem to help here.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-ietf-radext-
  [email-masked]          |  [email-masked]
     Type:  defect                   |      Status:  closed
 Priority:  major                    |   Milestone:
Component:  nai                      |     Version:
 Severity:  -                        |  Resolution:  fixed
 Keywords:                           |
-------------------------------------+-------------------------------------

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