IETF Logo Mail Archive

Re: [I18ndir] I18ndir early review of draft-ietf-dispatch-javascript-mjs-07

Patrik Fältström <patrik@frobbit.se> Sun, 10 May 2020 04:49 UTC

Return-Path: <patrik@frobbit.se>
X-Original-To: i18ndir@ietfa.amsl.com
Delivered-To: i18ndir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994683A073E; Sat, 9 May 2020 21:49:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=frobbit.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qoTzPsCgMVRd; Sat, 9 May 2020 21:49:07 -0700 (PDT)
Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66E603A0736; Sat, 9 May 2020 21:49:06 -0700 (PDT)
Received: from [192.165.72.241] (unknown [IPv6:2a02:80:3ffc:0:1906:82e6:93dc:cd08]) by mail.frobbit.se (Postfix) with ESMTPSA id 8CB4A288C6; Sun, 10 May 2020 06:49:03 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=frobbit.se; s=mail; t=1589086143; bh=ANTXe3qQw9MpXJXe7nzPcu/6MXc8RswKRL6wTnuFszE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=v/47i7S+Vv2bGvRp2A+SjrUt/TxyfJ2u/5CWqPk06AmntcAXOK81wW9FLbKuW8rYz ZGkkuCobNAtvZpNmQ3yfNG+wc29LjAqZpxCY3vkQELNLDnBFPNG6wMhuhPT7VKwgXs R8P6o2rcqn11QL/Cb7a3aZayPiTfxI1hf9FCkMH8=
From: Patrik Fältström <patrik@frobbit.se>
To: John C Klensin <john-ietf@jck.com>
Cc: Barry Leiba <barryleiba@computer.org>, John R Levine <johnl@taugh.com>, Myles Borins <mylesborins@google.com>, DISPATCH WG <dispatch@ietf.org>, draft-ietf-dispatch-javascript-mjs.all@ietf.org, i18ndir@ietf.org
Date: Sun, 10 May 2020 06:49:02 +0200
X-Mailer: MailMate (1.13.1r5676)
Message-ID: <BE31D0EF-AD57-46A6-B7B2-42D6D86B39C2@frobbit.se>
In-Reply-To: <5C4E8FFB57EBAE9A3C3BEA61@PSB>
References: <158896904545.17044.5288882047334991439@ietfa.amsl.com> <CALaySJ+CRJumYtDCxvGsSwzanz4y=7icuqd+toc0wMivf-mJGg@mail.gmail.c om> <CAD7Fb3diej1-3fAgqZsS_E9wOs1KC=OwVWbvxV5mVjOdQEQm5g@mail.gmail.com> <alpine.OSX.2.22.407.2005081926580.81728@ary.qy> <C6B94276-EB9F-4A5B-9E1B-0DE170A05EBC@frobbit.se> <alpine.OSX.2.22.407.2005091233350.84818@ary.qy> <CALaySJKbxdXRQejP3izri8NOmimVwqoNf5XEgzPStD=gKbEwOA@mail.gmail.com> <5C4E8FFB57EBAE9A3C3BEA61@PSB>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_67D30FDB-D23F-44AF-A950-2C0307E03404_="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i18ndir/vzqOLFryQSS0rGCiECcUhqzf0iI>
Subject: Re: [I18ndir] I18ndir early review of draft-ietf-dispatch-javascript-mjs-07
X-BeenThere: i18ndir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Internationalization Directorate <i18ndir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i18ndir>, <mailto:i18ndir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i18ndir/>
List-Post: <mailto:i18ndir@ietf.org>
List-Help: <mailto:i18ndir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i18ndir>, <mailto:i18ndir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 May 2020 04:49:12 -0000

On 9 May 2020, at 22:28, John C Klensin wrote:

> +1, fwiw.

Agree

>    john
>
>
> --On Saturday, May 9, 2020 14:36 -0400 Barry Leiba
> <barryleiba@computer.org> wrote:
>
>>> It occurs to me that http clients can send an Accept header,
>>> so how about saying that modules SHOULD be text/jsmodule, but
>>> MAY be text/javascript for backward compatibiltiy with
>>> clients that don't handle text/jsmodule?
>>
>> I'm very much not fond of the SHOULD... but MAY construction,
>> because I think the MAY contradicts the SHOULD.
>>
>> I think the right way to say this is more along the line of
>> "SHOULD use text/jsmodule.  If that is not practical because
>> backward compatibility with clients that do not support
>> text/jsmodule is necessary, then the alternative MUST be
>> text/javascript."
>>
>> Barry

v2.23.0 | Report a Bug | By Email