Re: [BEHAVE] one week WGLC, draft-ietf-behave-ftp64-05

<soapbox>
This thread underscores why standardizing an ALGs is terribly 
difficult.  In this case, the addition of a new feature (LANG
command) on the client and server requires the ALG to either
break that new feature or to fully support the new feature.
For the ALG to fully support LANG, that means an ALG has 
to support all possible languages that can be expressed by 
LANG.

... and, remember, FTP is a "simple" protocol.
</soapbox>

The best solution I see is the FTP64 ALG has to (MUST) 
remove LANG from the server's FEAT response, and translate
the LANG command to NOOP and return a 5xy response to the
client.

If an FTP client, running on an IPv6-only machine, does not
like LANG being disabled, there are two solutions:

  1. the FTP client has to implement the "ALGS DISABLE64" 
     command, and ensure the IPv4-only FTP server it is 
     using properly supports the EPSV command.  This
     is, effectively, draft-ietf-ftpext2-ftp64-00.
OR
  2. have the FTP server add an AAAA record, and properly
     support the EPSV command.  This causes the FTP traffic
     to not use the NAT64 or FTP64 ALG.

-d

> -----Original Message-----
> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
> Behalf Of Dave Thaler
> Sent: Wednesday, December 22, 2010 9:19 AM
> To: Dave Thaler; Iljitsch van Beijnum
> Cc: draft-ietf-behave-ftp64@tools.ietf.org; ftpext@ietf.org; Behave WG
> Subject: Re: [BEHAVE] one week WGLC, draft-ietf-behave-ftp64-05
> 
> One more comment...
> 
> [...]
> > > Ideally, the ALG would observe the LANG negotiation and then send
> text
> > > in the desired language. However, there is no way to make sure that
> > > the ALG supports all the languages that clients and servers may
> > > support, so even if the ALG makes this attempt, there will be cases
> > > when it can't provide text in the desired language.
> > >
> > > When that happens, there are two choices:
> > >
> > > 1. block the LANG negotiation and use the default language
> > >
> > > 2. ignore the LANG negotiation and use the default language
> >
> > Yes for LANG (as opposed to the FEAT exchange), those are the same as
> I
> > described in my email.
> >
> > > The advantage of 1 is consistency. However, this is more complex to
> > > implement and despite some evidence of LANG support I fear that
> actual
> > > use of this feature is too low to see good real-world testing, so
> > > there is a significant risk of bugs that won't come to light until
> the
> > > ALG is widely deployed. Another downside is that the user is now
> > > deprived of text in the desired language for text sent by the
> server that isn't
> > touched by the ALG. Most notably, this would be the greetings.
> > > With failed LANG negotiation, users probably also wouldn't be able
> to
> > > use UTF-8 user names, passwords or path names.
> >
> > The last sentence is not correct.   The LANG command only controls
> the
> > language
> > of the server's text responses.  It has no effect on the ability for
> the client (or
> > server) to use UTF-8 user names, passwords, or path names.
> >
> > But yes, the advantage is consistency, and the disadvantage is that
> you're
> > limited to languages supported by both the server and the ALG.
> >
> > >
> > > The advantage of 2 is implementation simplicity and that the
> majority
> > > of the text is still in the desired language. However, some server
> > > responses will be in the ALG's (default) language rather than in
> the
> > > negotiated language. (But informed users can still see what's going
> on
> > > from the numeric response, the text is merely additional
> information.)
> >
> > To repeat my earlier point, the disadvantages are
> > 1) Text from the ALG may render as garbage (even overwriting the
> numeric
> > response,
> >    making it impossible for the user to see what's going on...
> remember some
> > languages
> >    are bidirectional so this isn't just about the backspace
> character)
> > 2) Some clients might even crash or have other unexpected behavior,
> since
> >     2 appears to violate RFC 2640 and hence could easily have
> untested behavior.
> >
> > To me, the above disadvantages are strong arguments against 2.
> 
> Of course, in theory, neither of the above *should* be a problem
> if implementations deal with text correctly.  I guess the main point
> is about RFC compliance and levels of testing.
> 
> I wouldn't want to apparently violate RFC 2640 without the
> FTPEXT group's consent, so that would be the question to the FTPEXT
> list.
> 
> -Dave
> 
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave