Subject: Ftp-WG: RE: draft-ietf-ftpext-intl-ftp-05.txt

From: "Martin J. Duerst" <[email-masked]>
Date: Sun, 13 Dec 1998 01:09:09 -0500

Hello Bill, hello everybody,

I spoke with Patrik yesterday at the IETF in Orlando, and we agreed
that I would send a mail to the list to move this issue (and therefore
the whole draft) forward. Bill, do you think you can come up with
something, or should I propose some text? (I would do so now if I
were online, but I'm now in a plane between Chicago and Tokyo,
somewhere over Alaska).

Regards,   Martin.

At 11:41 98/10/06 -0400, Curtin, William wrote:
> I'm looking at the ADs comments to the I18n draft (see below).       
> It seems that Patrick is asking me to mandate UTF encoding of the text 
> part of command responses (i.e. "error messages" per RFC 2130). I 
> assume this is for 100-500 command responses and not just the 400- 
> 500 command responses. While RFC 2130 page 21 does mention language 
> tagging for banners and error messages (but doesn't really mention
> UTF8 encoding), I thought there was discussion of this on the list
> and that the decision was to continue to use ASCII. Also section 10 
> of the MLST draft suggests that the only encoding for protocol 
> responses is ASCII.
>           
> It seems to me that based on section 10 of the MLST draft that the encoding
> should not be UTF-8 but ASCII. I can address Patrick's suggestion to include
> a Lang feature to negotiate a language that the banner and protocol textual
> responses should be returned in. This too may be a slippery slope as many 
> languages can not be expressed in ASCII. 
>           
> Do I need to include UTF8 encoding for the text part of the command 
> responses? If so I guess that Section 10 of MLST would have to be 
> changed.
> 
> My inclination is to require that banners and the text part of responses
> be encoded in utf-8, and that a Lang feature be added to negotiate a language
> that they will be returned in.
>           
>                                         Any thoughts?
>           
>           
>                                             bill
> 
> 
> > -----Original Message-----
> > From: Patrik FSltstr$B�N(J [SMTP:[email-masked]] 
> > Sent: Thursday, September 10, 1998 3:04 PM
> > To: William Curtin; Paul Hethmon [SMTP:[email-masked]] 
> > Cc: Harald Tveit Alvestrand 
> > [SMTP:[email-masked]] ; Keith
> > Moore [SMTP:[email-masked]] 
> > Subject: draft-ietf-ftpext-intl-ftp-05.txt
> > 
> > 
> > These are the issues that were brought up when discussing 
> > this I-D in the IESG.
> > 
> > Question:
> > 
> > This document deals only with internationalization of file names.
> > As identified by RFC 2130, internationalization is also 
> > needed in error
> > messages.
> > 
> > The WG may choose to:
> > 
> > - Explicitly defer the problem to another, later document
> > - (Do the Right Thing and) declare that servers with UTF8 in 
> > FEAT will also
> >   use UTF8 in error messages, when appropriate
> > - As above, but also add a LANG feature to let the client 
> > select language
> >   for error messages
> > 
> > Not mentioning it is not an option.
> > 
> > Nits:
> > 
> > - Section 1 needs to refer to 2277, not 2130
> > - Section 3.2 hasn't indented "UTF8" in the example response, 
> > even though
> >   the very next sentence says the indentation is required.
> > 
> > 
> > Please address these issues, and submit a new version of the 
> > I-D to the
> > repository. Also, please send answers (and questions) to this 
> > mail to all
> > persons on the To and Cc of this mail.
> > 
> >    Regards, Patrik F$BgM(Jtstr$B‹N(J
> >    Area Director, Applications Area
> > 
> 
> 
> 

#-#-#  Martin J. Du"rst, World Wide Web Consortium
#-#-#  mailto:[email-masked]   http://www.w3.org

---

From: Robert Elz <[email-masked]>
Date: Sun, 13 Dec 1998 01:39:35 -0500

Date:        Sun, 13 Dec 1998 01:09:09 -0500
    From:        "Martin J. Duerst" <[email-masked]>
    Message-ID:  <[email-masked]>

  | At 11:41 98/10/06 -0400, Curtin, William wrote:
  | > Do I need to include UTF8 encoding for the text part of the command
  | > responses? If so I guess that Section 10 of MLST would have to be
  | > changed.

That's not a problem - that part of the MLST draft is just at attempt
to avoid making a change to FTP in there which isn't really any part of
what MLST is doing.

If FTP has already been altered to specify that UTF-8 is allowed in the
messages that accompany server responses, then there would no longer be
any possibility of confusion in MLST, and teh relevant sentence would simply
be omitted.

I would suggest adding a FEAT indicator for servers to use if they are
going to be using more than ascii in responses.

If one wanted to get fancy, the FEAT line could indicate in which languages
the messages could be returned, and an OPTS command could be used by the
client to select one of them...

kre

---

From: Patrik Faltstrom <[email-masked]>
Date: Sun, 13 Dec 1998 11:39:27 -0500

Note that it is up to the wg to choose which way the problem is solved:

>   FEAT will also use UTF8 in error messages, when appropriate
>   select language for error messages
> 

Pick one route, and move (as you seem to be doing now -- GREAT!).

   Patrik

---

From: Stephen Tihor <[email-masked]>
Date: Sun, 13 Dec 1998 13:03:01 -0500

I also vote for the UTF8 route with a note that for maximum interoperability
and backwards compatibility messages expressed in the ASCII subset of UTF8 are 
certain to be readable and properly displayable by all reasonable old clients
as well.

---

From: Dave Cridland <[email-masked]>
Date: Tue, 15 Dec 1998 10:11:42 -0500

// I also vote for the UTF8 route with a note that for maximum interoperability
// and backwards compatibility messages expressed in the ASCII subset of UTF8 are 
// certain to be readable and properly displayable by all reasonable old clients
// as well.

Agreed, with the addition that, until negotiated, (By FEAT/OPT, presumably), 
all responses MUST be in ASCII, and that any "initial" messages (before the 
client has had an opportunity to change language) SHOULD be repeated. That 
essentially means the initial server "Welcome" message - 220.

The initial language is, of course, up to the implementor. Mainly becasue 
insisting on any particular language would simply start a massive flamewar. :-)

reasoning behind the first paragraph:

 - If the client's language preferences are unknown, then we should assume 
that the client doesn't understand our language options, and by inference 
cannot be expected to cope with UTF-8.
 - Secondly, the initial welcome message may contain useful information, 
directed at the human user. Since it is reasonable to expect that, unless we 
hear otherwise, the user doesn't speak the same language as us (We being the 
server) we ought to repeat whatever we said in his language, once we know.

Does all that make sense, or am I just returning extended information?

Dave.

---

From: Robert Elz <[email-masked]>
Date: Wed, 16 Dec 1998 02:52:11 -0500

Date:        Tue, 15 Dec 1998 10:11:42 -0500
    From:        Dave Cridland <[email-masked]>
    Message-ID:  <[email-masked]>

  | and that any "initial" messages (before the 
  | client has had an opportunity to change language) SHOULD be repeated. That 
  | essentially means the initial server "Welcome" message - 220.

That's probably necessary - but perhaps even better, could we create
a command whose sole purpose was to generate that welcome message, and
which could be issued any time (including before authentication)?

With that, it could be issued after agreement to UTF-8 messages (and perhaps
language selection) - it might also just mean that implementations might
stop issuing multi-page welcome banners to those who have no desire whatever
to see the things (I do most of my FTP via scripts which simply fetch files,
none of the noise is ever displayed to me - sending it to my client is a
waste of time and bandwidth).

kre

---

From: Alun Jones <[email-masked]>
Date: Wed, 16 Dec 1998 07:29:22 -0500

>which could be issued any time (including before authentication)?

At the risk of sounding like I'm beating the same old drum, the proposed
"HOST" command already presents the greeting.  A HOST command with no
parameters could, for instance, be interpreted as "use currently negotiated
options and start me up with this host again".

Alun.
~~~~

--
Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find it
1602 Harvest Moon Place | at web site http://www.wftpd.com or email
Cedar Park TX 78613     | us at [email-masked].  VISA / MC accepted.
Fax +1 (512) 378 3246   | NT based ISPs, be sure to read details of
Phone +1 (512) 378 3246 | WFTPD Pro, NT service version - $100.
*******-- Alpha processors now supported under Windows NT --*******

---

From: Robert Elz <[email-masked]>
Date: Wed, 16 Dec 1998 07:39:43 -0500

Date:        Wed, 16 Dec 1998 07:29:22 -0500
    From:        Alun Jones <[email-masked]>
    Message-ID:  <[email-masked]>

  | A HOST command with no
  | parameters could, for instance, be interpreted as "use currently negotiated
  | options and start me up with this host again".

That's a reasonable idea.    I'll include that interpretation in the draft,
which (believe it or not) is just about ready to get sent to the I-D 
directories (that is, mlst-05).   I'm just waiting for an OK from my co-editor.

kre

---

From: Michael Chapman <[email-masked]>
Date: Wed, 16 Dec 1998 08:09:09 -0500

UNSUBSCRIBE

	Thanks & best wishes,

---

From: Dave Cridland <[email-masked]>
Date: Wed, 16 Dec 1998 10:02:38 -0500

// At the risk of sounding like I'm beating the same old drum, the proposed
// "HOST" command already presents the greeting.  A HOST command with no
// parameters could, for instance, be interpreted as "use currently negotiated
// options and start me up with this host again".

That sounds like a plan to me. There's not much I can add to that at all.

Dave.
-- 
Dave Cridland -- Research & Development Manager -- Cerbernet Ltd
Civilization is the limitless multiplication of unnecessary necessities.
		-- Mark Twain

---

From: Alun Jones <[email-masked]>
Date: Wed, 16 Dec 1998 11:29:27 -0500

>That sounds like a plan to me. There's not much I can add to that at all.

Then why don't I add...

The HOST command should not preserve PORT/PASV settings, REST settings,
user and password info, or negotiated listing formats.  At a rough guess,
I'd say the only setting worth preserving for the HOST command is that of
the language selected.

Now, obviously, this does increase the standard login sequence to:

connect.
Receive 220 message (in ASCII, whatever language the site chooses).
send FEAT command to discover language capabilities
receive FEAT response
send OPTS command to select language
receive OPTS response
send HOST command to re-connect
receive 220 message
send USER and PASS commands as normal...

Are there any other options than the language that should be kept through
the HOST command?  Should we expect the HOST command to connect us possibly
to a new host with a different FEAT setting?  Are there any FEAT settings
that should _not_ be communicated to non-authorised users (i.e. before a
USER and PASS setting)?  Obviously a very important security consideration
is what information is given, and what settings are allowed, before the
user can be verified.  Already I have plenty of paranoid people asking me
to remove the product identifier from the 220 greeting message (I don't
because too many FTP clients use that to determine what listing format they
will expect)

Alun.
~~~~

---

From: Robert Elz <[email-masked]>
Date: Wed, 16 Dec 1998 12:29:53 -0500

Date:        Wed, 16 Dec 1998 11:29:27 -0500
    From:        Alun Jones <[email-masked]>
    Message-ID:  <[email-masked]>

  | At 10:02 AM 12/16/98 -0500, you wrote:
  | >That sounds like a plan to me. There's not much I can add to that at all.

Actually, when I started to write the text for this, I realised
that we don't really need HOST without parameters for this at all.

It is expected that any client that supports HOST (which it would
have to do for this scheme to make sense) will send it with the
hostname in any case - it has to do that in case the server implements
virtual hosts.

I don't see that allowing the hostname part to be omitted gains anything,
and I don't see any particular advantage that will give anyone.  It might
just allow the client to "forget" what host it connected to, but I
somehow don't see that as a big enough deal to cause me to make the hostname
optional rather than required (and hence complicate the servers).

So, unless there is objection, what I propose is simply to note that
the response to the host command is the perfect time to issue welcome
messages, and that done there the server will have the advantage of
the client having had a chance to negotiate language choice.

Wrt:

  | The HOST command should not preserve PORT/PASV settings, REST settings,
  | user and password info, or negotiated listing formats.

The (new, soon to appear) draft already makes it clear (in the section
on REST) that REST values are never preserved (never defined to be
preserved) over anything at all.  You do REST RETR, or REST STOR, or
you forget about REST.   PORT/PASV are (I believe) already defined to
have short term effect, but I will make sure the HOST command is clear
that all that kind of thing is reset.  Also the current type, mode,
etc (though those ones appear in server defined state after a connect
anyway I think, and so a server that chooses to leave them as last set
would not be non-conforming, but nor would one that resets them).

On listing formats, and other negotiated options that way, I think I'd
also prefer to leave it server defined - in any case, the default format
is for it to choose, what matters is that after a HOST command the
client doesn't assume that it will remain untouched.

  | AT setting?  Are there any FEAT settings
  | that should _not_ be communicated to non-authorised users

This is really something that ought be considered as each FEAT is
defined.   None of those that exist so far exposes any kind of
problem that I can see.   The FEAT RFC does mention that FEAT can
provide information to unauthenticated users in its security considerations
section, and goes on to say...

   The security of any additional features that might be reported by the
   FEAT command, and manipulated by the OPTS command, should be
   addressed where those features are defined.

As long as we do that, I think we'll be OK.

kre

---

From: Craig Metz <[email-masked]>
Date: Wed, 16 Dec 1998 13:34:01 -0500

>UNSUBSCRIBE

FLAME