Re: Straw-man charter for http-bis

Martin Duerst <duerst@it.aoyama.ac.jp> Sun, 10 June 2007 23:40 UTC

Return-path: <discuss-bounces@apps.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxX16-0001WG-PP; Sun, 10 Jun 2007 19:40:16 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HxX14-0001WA-SD for discuss-confirm+ok@megatron.ietf.org; Sun, 10 Jun 2007 19:40:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxX14-0001W2-IZ for discuss@apps.ietf.org; Sun, 10 Jun 2007 19:40:14 -0400
Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxX12-0004pS-Oh for discuss@apps.ietf.org; Sun, 10 Jun 2007 19:40:14 -0400
Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l5ANe56K027128 for <discuss@apps.ietf.org>; Mon, 11 Jun 2007 08:40:05 +0900 (JST)
Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 261a_ea826e2e_17ab_11dc_95f4_0014221fa3c9; Mon, 11 Jun 2007 08:40:05 +0900
X-AuthUser: duerst@it.aoyama.ac.jp
Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:53723) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <SBA0D1> for <discuss@apps.ietf.org> from <duerst@it.aoyama.ac.jp>; Mon, 11 Jun 2007 08:38:15 +0900
Message-Id: <6.0.0.20.2.20070610165356.0a69cec0@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Version 6J
Date: Sun, 10 Jun 2007 17:05:44 +0900
To: Julian Reschke <julian.reschke@gmx.de>, Paul Hoffman <phoffman@imc.org>
From: Martin Duerst <duerst@it.aoyama.ac.jp>
Subject: Re: Straw-man charter for http-bis
In-Reply-To: <465D9142.9050506@gmx.de>
References: <BA772834-227A-4C1B-9534-070C50DF05B3@mnot.net> <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <p06240843c2833f4d7f2f@[10.20.30.108]> <465D9142.9050506@gmx.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: Apps Discuss <discuss@apps.ietf.org>, Mark Nottingham <mnot@mnot.net>, Felix Sasaki <fsasaki@w3.org>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, Richard Ishida <ishida@w3.org>
X-BeenThere: discuss@apps.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <discuss.apps.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=unsubscribe>
List-Post: <mailto:discuss@apps.ietf.org>
List-Help: <mailto:discuss-request@apps.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=subscribe>
Errors-To: discuss-bounces@apps.ietf.org

At 23:59 07/05/30, Julian Reschke wrote:
>Paul Hoffman wrote:
>> Serious question, not a gratuitous opening of a big can-o-worms: would the WG also consider extensions to HTTP that would go into different documents? That is, is the WG only for the revision of the base spec, or also open to ( animated && lengthy && contentious ) discussion of other documents as well?
>
>I guess the idea was that the more we restrict the scope of what we want to do, the easier it'll be to gather the right group of people to do it.
>
>For instance, RFC2617 needs a revision badly as well (for instance, wrt to I18N of usernames and passwords, and, as far as I can recall, certain problems with the definition of Digest Auth). IMHO; this should occur in a separate working group.

There are some i18n-related fixes needed in RFC 2616 as well.

The two main ones I know of are:

- RFC 2616 prescribes that headers containing non-ASCII have to use
  either iso-8859-1 or RFC 2047. This is unnecessarily complex and
  not necessarily followed. At the least, new extensions should be
  allowed to specify that UTF-8 is used.
- RFC 2616 prescribes a default of iso-8859-1 for the 'charset'
  parameter for text/* mime types. At least in two very important
  cases, this is not followed: For text/html, there is no default,
  or put in other words, the default is whatever your browser is
  set to. For text/xml and related types, the default is US-ASCII.
  At a miminum, the spec should make sure the implementers get
  an idea of this, rather than having to find out the hard way.

Regards,    Martin.



#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@it.aoyama.ac.jp