Subject: Re: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-02.txt

From: Ben Harris <[email-masked]>
Date: Thu, 16 Jun 2005 00:47:47 +0100

In article <[email-masked]> you write:
>	Title		: SCP/SFTP/SSH URI Format
>	Author(s)	: S. Suehring, J. Salowey
>	Filename	: draft-ietf-secsh-scp-sftp-ssh-uri-02.txt
>	Pages		: 8
>	Date		: 2005-6-15

I'd really like to see this draft finished, but there are various dull
things that need to be fixed:

The secsh-architecture and secsh-filexfer drafts should be cited in the
introduction when the protocols are first mentioned.

"SSH", "SFTP" and "SCP" all need to be expanded on their first use in each
of the title, abstract, and body text.

The syntax notation used isn't defined.  This should probably be done by
reference to RFC 2234.

Assuming that the syntax notation is intended to be RFC-2234 ABNF, many of
the rules are invalid (having '_' and '=' in rule names, not leaving spaces
between concatenated elements).

The various URI formats seem to allow a userinfo and host not
separated by "@".

The rules conn-parameter=value, sftp-parameter=value, and abs_path aren't
defined.

The translation from the octets specified by the URI into filenames sent
over SFTP isn't specified.  In particular, the state of the
filename-translation-control extension isn't defined.

The meaning of "typecode=a" isn't clear to me, since "text file" doesn't
tell me what character set to expect.

The examples should come with prose descriptions of their meanings.

Using unqualified hostnames in examples is probably a bad idea.

The sixth example is incorrect, since it puts an SFTP parameter in the
conn-parameter=value field.

There's no IANA Considerations section.

-- 
Ben Harris

---

From: Ben Harris <[email-masked]>
Date: Thu, 16 Jun 2005 16:29:34 +0100

>	Filename	: draft-ietf-secsh-scp-sftp-ssh-uri-02.txt

Some more substantive comments (these might need discussion):

SCP URIs should go, since there's no standard definition of SCP.

I'm a little worried that this draft will get stuck in the RFC-Editor queue
waiting for its normative reference to SFTP to be fulfilled.  It would be a
pity if SSH URIs got held up because of this.

The interpretation of the password part of userinfo isn't specified.  In
particular, it's not clear whether it only applies to "password"
athentication, or also to "keyboard-interactive".

Regarding the various kinds of parameters, the draft says that "Additional
parameters MAY be used", but doesn't specify how such parameters should be
named or what an implementation should do upon receiving such an
unrecognised parameter.

-- 
Ben Harris