Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754143AbbLCG4E (ORCPT ); Thu, 3 Dec 2015 01:56:04 -0500 Received: from mail-wm0-f51.google.com ([74.125.82.51]:38025 "EHLO mail-wm0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750950AbbLCG4D (ORCPT ); Thu, 3 Dec 2015 01:56:03 -0500 MIME-Version: 1.0 In-Reply-To: <20151201201326.GA11267@rhlx01.hs-esslingen.de> References: <20151201201326.GA11267@rhlx01.hs-esslingen.de> From: Michal Suchanek Date: Thu, 3 Dec 2015 07:55:22 +0100 Message-ID: Subject: Re: Non-ascii mantainers To: Andreas Mohr Cc: Al Viro , Linux Kernel Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2326 Lines: 47 On 1 December 2015 at 21:13, Andreas Mohr wrote: > Hi, > >> I don't really care if the maintainers are encoded or whatever. >> However, neither get_maintainers nor git format-patch encodes them and >> the listserver rejects them when not encoded. > > "neither ... nor" - IMHO transcoding should always be done at exactly *one* layer > transition (namely prior to entering the layer which might happen to be > using non-encoded same-char values as used by payload data as control chars, > or which might happen to have a "reduced" encoding only requirement [think 7bit vs. 8bit], > and only there, and of course also correctly [transcodes full set of > control chars, and properly]). ;) > > So, since git-format-patch (according to git-format-patch(1)) itself > declares that it does "Prepare patches for e-mail submission", > it would seem that format-patch would definitely need to provide > readily submittable content i.e. > support submitting (i.e., generating) such content in *fully compatible* format > (maybe it would not need to generate this as MIME encoding always > - since there might be different encoding technologies to be chosen - > but at least it should offer an encoding cmdline option, > with this option then definitely defaulting to the mainstream choice, probably MIME). > IOW, I would consider this to be a git-format-patch "missing crucial i18n support" bug > (a bug for this should probably be filed). > > (and, due to my reasoning above, transcoding would *not* be the job of get_maintainers) > The transcoding would be normally the job of a MUA which is git format-patch here. If it were really required, that is. I am not sure what exactly is the position of the SMTP standard here on 8bit headers. However, as with all RFCs it's suggested that you are strict in what you send and lenient in what you accept. Here git format-patch can be held responsible for lack of interoperability with 7-bit only SMTP servers and the LKML mail server for enforcing 7-bit only in 2015 when most mail servers are 8-bit transparent. Thanks Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/