Subject: Re: [abfab] Comments on draft-ietf-abfab-gss-eap-naming-01

From: Sam Hartman <[email-masked]>
Date: Mon, 12 Mar 2012 18:00:17 -0400

Scott, thanks for the proposed text regarding name attributes.

In your original text you proposed to mandate that the display form of
SAML attributes should be UTF-8 encoded. I agree that's reasonable for
the raw form but I'm not actually sure that we should standardize that
for the display form.

I'd appreciate comments from the WG, especially from Nico, Leif and
others who have worked on the base naming extensions spec.

I'm wondering for example whether implementations will want to present
display names in the local character set of the current system locale
for hosted environments that have such.

---

From: "Cantor, Scott" <[email-masked]>
Date: Mon, 12 Mar 2012 23:18:33 +0000

>Scott, thanks for the proposed text regarding name attributes.

<swapping back in...>

>the raw form but I'm not actually sure that we should standardize that

I'm working with an absence of understanding of exactly how the display
form would be used, but my experience with XML data in general is that
sticking with UTF-8 where possible tends to keep things simpler, since an
application can always do whatever converting it wants to from that
baseline.

But in a related question, wouldn't it be bad to have different name
attributes expressing themselves in either raw or display form with
different encodings? How would the application know what the encoding was
meant to be in each case?

-- Scott

---

From: Sam Hartman <[email-masked]>
Date: Mon, 12 Mar 2012 19:41:19 -0400

>>>>> "Cantor," == Cantor, Scott <[email-masked]> writes:

    Cantor,> I'm working with an absence of understanding of exactly how
    Cantor,> the display form would be used, but my experience with XML
    Cantor,> data in general is that sticking with UTF-8 where possible
    Cantor,> tends to keep things simpler, since an application can
    Cantor,> always do whatever converting it wants to from that
    Cantor,> baseline.

Me too.
I'm not really sure what you'd do with the display form other than dump
into a debug log.

I was hoping to get input from those who added the display form to the
API.

    Cantor,> But in a related question, wouldn't it be bad to have
    Cantor,> different name attributes expressing themselves in either
    Cantor,> raw or display form with different encodings? How would the
    Cantor,> application know what the encoding was meant to be in each
    Cantor,> case?

That's part of my concern.  I'm wondering whether the display form is
expected to have encoding under the implementation's control rather than
under the attribute's control?

I really don't know what the right answer is. I've left it unspecified
in the current version and will be happy to change that if we figure out
what should be done there.

---

From: Nico Williams <[email-masked]>
Date: Tue, 13 Mar 2012 01:34:53 -0500

> I was hoping to get input from those who added the display form to the

I did that.  It was in the original.  It was intended for tools like,
say, a GSS version of klist (hand waiving).

Now, the GSS-API specifies somewhere that it deals in Latin-1.
Clearly we're NOT going to have consensus on using Latin-1 as that's
just ridiculous.

UTF-8 would certainly be a lot better than "unspecified" or "Latin-1",
but I think in practice applications that care for display forms of
attribute values will want something that is in the current locale's
codeset.

I'd be OK with saying these must be UTF-8, and I'd be OK with saying
these must be in the application's locale's codeset.  Applications
that need to send these display forms over the wire (e.g., in log
messages) will want UTF-8.  Applications displaying these in UIs will
want the current locale's codeset.

In the interest of speeding a consensus I'll go with UTF-8.

Nico
--