Re: [BEHAVE] one week WGLC, draft-ietf-behave-ftp64-05
Dave Thaler <dthaler@microsoft.com> Wed, 22 December 2010 17:17 UTC
Return-Path: <dthaler@microsoft.com>
X-Original-To: behave@core3.amsl.com
Delivered-To: behave@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B75B43A67FD; Wed, 22 Dec 2010 09:17:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.539
X-Spam-Level:
X-Spam-Status: No, score=-110.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNEFBSKZ-A9w; Wed, 22 Dec 2010 09:17:11 -0800 (PST)
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id D6AC83A6B30; Wed, 22 Dec 2010 09:17:11 -0800 (PST)
Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 22 Dec 2010 09:19:10 -0800
Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.1.255.3; Wed, 22 Dec 2010 09:19:09 -0800
Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.151]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Wed, 22 Dec 2010 09:19:09 -0800
From: Dave Thaler <dthaler@microsoft.com>
To: Dave Thaler <dthaler@microsoft.com>, Iljitsch van Beijnum <iljitsch@muada.com>
Thread-Topic: [BEHAVE] one week WGLC, draft-ietf-behave-ftp64-05
Thread-Index: ActY6jKKLqeAf6WHSOikuiNZqgewtAH/d6IwBraFzQAJXXikgAAN1huAACguIwAABqYt8AALsh7Q
Date: Wed, 22 Dec 2010 17:19:08 +0000
Message-ID: <9B57C850BB53634CACEC56EF4853FF653447F599@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com>
References: <0cac01cb58ea$32d19a60$9874cf20$@com> <9B57C850BB53634CACEC56EF4853FF65343005F2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <B166ACF7-FA96-4954-8411-A86BC7923A76@muada.com> <9B57C850BB53634CACEC56EF4853FF653447D195@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447ECAF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <8B73074C-5B7E-425F-B8B2-C28757FB7CD6@muada.com> <9B57C850BB53634CACEC56EF4853FF653447F40D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com>
In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653447F40D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "draft-ietf-behave-ftp64@tools.ietf.org" <draft-ietf-behave-ftp64@tools.ietf.org>, "ftpext@ietf.org" <ftpext@ietf.org>, Behave WG <behave@ietf.org>
Subject: Re: [BEHAVE] one week WGLC, draft-ietf-behave-ftp64-05
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Dec 2010 17:17:12 -0000
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] one week WGLC, draft-ietf-behave-ftp64-05 Dan Wing
- Re: [BEHAVE] one week WGLC, draft-ietf-behave-ftp… Dave Thaler
- Re: [BEHAVE] one week WGLC, draft-ietf-behave-ftp… Iljitsch van Beijnum
- Re: [BEHAVE] one week WGLC, draft-ietf-behave-ftp… Dave Thaler
- Re: [BEHAVE] one week WGLC, draft-ietf-behave-ftp… Iljitsch van Beijnum
- Re: [BEHAVE] one week WGLC, draft-ietf-behave-ftp… Dave Thaler
- Re: [BEHAVE] one week WGLC, draft-ietf-behave-ftp… Iljitsch van Beijnum
- Re: [BEHAVE] one week WGLC, draft-ietf-behave-ftp… Dave Thaler
- Re: [BEHAVE] one week WGLC, draft-ietf-behave-ftp… Dave Thaler
- Re: [BEHAVE] one week WGLC, draft-ietf-behave-ftp… Dan Wing
- Re: [BEHAVE] one week WGLC, draft-ietf-behave-ftp… Iljitsch van Beijnum
- Re: [BEHAVE] one week WGLC, draft-ietf-behave-ftp… Dan Wing
- Re: [BEHAVE] one week WGLC, draft-ietf-behave-ftp… Iljitsch van Beijnum
- [BEHAVE] FTP64 LANGuage [was RE: one week WGLC, d… Dan Wing
- Re: [BEHAVE] FTP64 LANGuage [was RE: one week WGL… Iljitsch van Beijnum
- Re: [BEHAVE] FTP64 LANGuage [was RE: one week WGL… Dave Thaler
- Re: [BEHAVE] FTP64 LANGuage [was RE: one week WGL… Fred Baker
- Re: [BEHAVE] FTP64 LANGuage [was RE: one week WGL… Iljitsch van Beijnum
- Re: [BEHAVE] FTP64 LANGuage [was RE: one week WGL… Dan Wing
- Re: [BEHAVE] FTP64 LANGuage [was RE: one week WGL… Dave Thaler