Re: [mif-arch-dt] Strawman solution proposals for DHCPv6 and RA support for multiple provisioning domains

>>But if is a human-readable for end-users, as you seem to assume above, then we enter into the languages, scripts, i18n, normalization and 

As I understand, there are a few examples like SSID, APN names etc which are typically (or perhaps can't be?) localized. Is there a guidance document at the IETF which prohibits introduction of new types of human-readable identifiers w/o internationalization support?
________________________________________
From: Marc Blanchet <marc.blanchet@viagenie.ca>
Sent: Friday, November 22, 2013 12:38 PM
To: Ted Lemon
Cc: Jouni Korhonen; mif-arch-dt@ietf.org; Suresh Krishnan; Dmitry Anipko
Subject: Re: [mif-arch-dt] Strawman solution proposals for DHCPv6 and RA support for multiple provisioning domains

Le 2013-11-22 à 15:33, Ted Lemon <ted.lemon@nominum.com> a écrit :

> On Nov 22, 2013, at 12:11 PM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:
>> Domain names and alike possible PVD-IDs are ok since they already are "human readable". However, I would put zero energy trying to add something readable data into PVDs if the used PVD-ID itself is e.g. a binary blob. I just see no value of that if it increases the data size of the PVD container or ID.
>
> If the PVD ID is a blob, you need a mechanism for assigning a name to it and validating it.
>
> Think about the possible flow here.   We want to be able to present this information to the user in a chooser, right?   So that means that if what's contained in the ID is a binary blob, we need a way to translate it.   Also, if the blob is something we've already seen and can cryptographically authenticate based on a previous leap of faith, then we need the signature to authenticate.  And if we don't have the name at this point, we need a process for finding the name associated with the blob after we've decided to try it.
>
> It might be better to have a name that we can do all that too that's human-readable.

be careful. If it is a protocol parameter that is not shown to the user, then human readable is one design choice to help troubleshoot and ...  But if is a human-readable for end-users, as you seem to assume above, then we enter into the languages, scripts, i18n, normalization and ....  I'm not sure we want to go there for a PVD-ID...  I would assume a protocol element and then some end-user mapping in his own language/script/locale that is outside of the scope of this work/spec.

Marc.

>  Then we can do cryptographic validation if we have already seen the name, and avoid connecting to a fraudulent version of the PVD (which we could also do with the blob).   But if we haven't seen the name before, and haven't yet accepted it, we want something to present to the user, don't we?
>
> This bears thinking about.   I'm not saying you're wrong, but don't be too quick to leap to conclusions about this!
>
> _______________________________________________
> mif-arch-dt mailing list
> mif-arch-dt@ietf.org
> https://www.ietf.org/mailman/listinfo/mif-arch-dt