Re: Other comments on draft-ietf-secsh-publickey-subsystem

[Jon Bright <jon%siliconcircus.com@localhost>]

Nicolas Williams wrote:
> On Sun, Aug 27, 2006 at 11:20:29PM -0400, Sam Hartman wrote:
>
>  - I18N, L10N:
>
> > 5) Please use RFC 3066 for language tags.
>
>    And the proper reference for UTF-8 is not RFC2279 either but
>    RFC3629/STD0063.

Have updated this.

>    Also, since SSHv2 itself performs language negotiation, and since
>    Unicode provides codepoints for indicating the language of a
>    string/sub-string, why does this protocol need a slot for RFC3066
>    language tags at all?

>    I think you should just remove/deprecate the language tag field and
>    rely on the language negotiation performed by SSHv2.

SSH2 negotiation negotiates a list of the languages to be used (or 
doesn't - that negotiation is optional).  The tags specify which of 
those languages is in use.  (In much the same way that the language tag 
for, say, SSH_MSG_DISCONNECT does.)

As for why we don't use Unicode language indicators - no idea, but I'd 
prefer to keep this consistent with all the messages in the other RFCs 
which also don't.

>  - I'd rather the "mandatory" attribute of attributes be named
>    "critical"...

This would change a sentence like "If the server does not implement a 
mandatory attribute, it MUST fail the add.." to "If the server does not 
implement a critical attribute, it MUST fail the add..".  The first 
seems preferable to me.

>  - Are attributes like "x11" and so on booleans?  Or does their
>    presence/absence act as a boolean?  And if so, what kind of values do
>    they take on?

Their presence/absence act as boolean.  As for their values, "The 
attribute-value field SHOULD be empty for this attribute.".

>  - Clients need to know what kind of environment "command-override"
>    values will be evaluated in. 

Under what circumstances?

>    Should there be a request by which a
>    client can ask for a description of said environment, and a status
>    reply by which a server can list attributes of the environment like
>    the OS it runs, OS release, values of certain environment variables,
>    etc...  I would think so, something like:
>
>       string "status"
>       uint32 SSH_PUBLICKEY_ENVIRONMENT
>       uint32 env_count
>         string envvar_name
>         string envvar_value
>
>    along with some pre-defined environment variable names, like OS,
>    OSREL, ARCH, PATH etc...

Even if it's desirable, I think it's too late for this kind of change.

>  - How should the command-override and subsystem attributes interact?

command-override overrides SSH_MSG_CHANNEL_REQUESTs with "shell" or 
"exec".  subsystem places limits on SSH_MSG_CHANNEL_REQUESTs with 
"subsystem".  They're independent.

>  - How much of the execution environment of command-overrides be
>    specified here?

If I've understood the question correctly: the only thing it specifies 
is the path.  I don't really know when you'd need to specify more?

>  - An attribute is needed to set environment variables for the
>    environment where the command/shell/subsystem is executed.

Why?  Again, I think it's too late for this kind of substantive change.

--
Jon Bright
Silicon Circus Ltd.
http://www.siliconcircus.com