Subject: RE: set-passwd protocol and stringpreps, again

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Sun, 18 Jul 2004 19:03:55 -0700

Nicolas Williams wrote:
> And for many here support for localization could be a requirement
(e.g., due to the laws of various nations), so this 
> spec had better deal with the matter, and for extensibility's sake 
> requiring the server to perform any localization is 
> the way to go.  This is how several other IETF protocols deal with 
> l10n; for example: SASL, SSHv2.

It is sad that way, but it is not the end of the world, see below.

>  See the ASN.1 module in the last version of the draft.  You can see 
> that the relevant bits are extensible, 

Can you explain which are bits that can I extend? 

> though the 
> text of the spec limits extensions to those defined in IETF specs.  >
> And minor version negotiation is already there, so 
> this should not be an issue.

it is not acceptable if it takes an IETF action to introduce an error
code: we simply can not wait for that kind of process.

In the past, we have to use the error data field to convey more
meaningful errors to the clients, and this is bad because we are forced
to give up interoperability and it also forces you to buy a windows
machine to get the good user experience.

If you use my approach, to add a new error code, I just need to add it
into the IANA registry (we can have one for it), would that be more
agile? It would also solve the
un-implemenatable-if-you-have-the-server-to-localize-the-error-text-but-
that-is-what-everybody-else-does-anyway problem.

Larry

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Sunday, July 18, 2004 6:41 PM
To: Liqiang(Larry) Zhu
Cc: Sam Hartman; [email-masked]
Subject: Re: set-passwd protocol and stringpreps, again

On Sun, Jul 18, 2004 at 06:19:53PM -0700, Liqiang(Larry) Zhu wrote:
>  
> Nicolas Williams wrote:
> > A2:  Try again with a different randomly generated password, up to N
> >     times, then fail and tell the sysadmin to set a better policy on
> >     the given principal (see A1).
> 
> This sounds as a reasonable solution.
> 
> > The error codes are extensible, so future minor versions can have 
> > more specific errors.
> 
> I am trying to avoid using the minor version to indicate the set of 
> error codes the client supports.
> 
> In complex systems, we just need to deal with new error codes.
> 
> > And see above.
> 
> No existing systems either sends localized texts or depends on the 
> remote clients to localized the error text and display it properly.

Clients cannot be expected to localize messages from the server,
otherwise we'd have to standardize the messages, so that the message
catalogs could be standardized, and we don't want to do this -- we might
as well have an error code for every imaginable pw quality policy
instead.

As for servers and localization, well, with the client sending language
tags to the server the server can, indeed localize its messages,
provided that it has a suitable message catalog.  Presumably server
implementors will take care to include message catalogs for their
messages related to password quality policies.  I don't think this is
unreasonable.

And for many here support for localization could be a requirement (e.g.,
due to the laws of various nations), so this spec had better deal with
the matter, and for extensibility's sake requiring the server to perform
any localization is the way to go.  This is how several other IETF
protocols deal with l10n; for example: SASL, SSHv2.

> 
> > That said, I'll add a set of password quality policy hint codes that

> > could be used by sufficiently smart clients...  These can't be very 
> > specific, so for humans the policy description text is better.
> 
> In fact this is not hard to do, you just need to send an integer by 
> the client to indicate the largest error code value it can understand,

> and stating that if a client understands error code x+1, it must also 
> understand error code x. what do you think?

See the ASN.1 module in the last version of the draft.  You can see that
the relevant bits are extensible, though the text of the spec limits
extensions to those defined in IETF specs.  And minor version
negotiation is already there, so this should not be an issue.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 18 Jul 2004 21:26:31 -0500

> Can you explain which are bits that can I extend? 

Wherever you see '...' in the ASN.1 module.

> code: we simply can not wait for that kind of process.

We should discuss this at the meeting.  See below.

> machine to get the good user experience.

There is a way to do this in the protocol, just not with error codes,
but with text instead.

> that-is-what-everybody-else-does-anyway problem.

We can always use RELATIVE-OID or OIDs for extensions, but first I'd
like to identify where we need non-IETF-originated extensions, if at
all.  Again, we should discuss this at the meeting.

Cheers,

Nico
--