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

Asmus Freytag <> Sat, 09 May 2020 23:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F13413A0C70 for <>; Sat, 9 May 2020 16:44:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key); domainkeys=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qsEww3J9MRnb for <>; Sat, 9 May 2020 16:44:10 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EEC9E3A0C12 for <>; Sat, 9 May 2020 16:44:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dk12062016; t=1589067850; bh=3qCfSm0NFJgIcM48kMGTfutUu4mHV27Sit3v MncH9WE=; h=Received:Subject:To:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language: X-ELNK-Trace:X-Originating-IP; b=G2Qhzy1uN058qNBfSIremKStHR2xp/MHA sV6kD7M5sFbztg2S6rk1x0xh1Y5x0IIZdvs0pz4hshJq+vGKRcVXqiS9o4Rilnzy8HS f2h23FiJpYL2PfUb3j4sD4yhXTGqePd1FhdrRt6p+jf0EtFfrGqNke5t07876ZmdI6L VLiRn30FNDU3DXfAdD/EIrM9sb++xXi7O/zo+oJ9r5xSYdPGAesPfFYfdXiVJ3bcVEx Zfg76JpGAT1foPYE8y2lJBvgrN1JA2KlcoHjIBgwLLaRbKUnaXA3qDnFBmknj/Vi0dC AWBTxOWh0JZ898ZrZpMbOJRyr3X5dDBWW8B7Mkn/Q==
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016;; b=W1uyvDH1S9j/A0aHKfTdS5SCz7VeGvYfv/LR8T12jvZFCI1ulxQjmvEe9WCnQp5WKBVyJoEfh04XeD3Z/wWPVtgtifWy1rpsX2dUSQqVV/2VxKIRcL67G+PI4tJdBkI3B3aoVYcLJs8VuutA1SPhIiixtWDlOK5TPoukLMYoRi84jgDxAJf3T49LxjcrRu1EwU/R9NkPhiWEVarPiCutORBVA6Q+WuAhjHXVHLI/8ZpuI5/+VyNnC0Ypxn6qbyNJKGTiojXqvHigfWv4NyFlAMYqdxmT5bQuAKHFqQ1Jru6KgwerhO1Sdlh4Mq4i1tqBOBaAdmEEgxbgxW8wh+f+nQ==; h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language:X-ELNK-Trace:X-Originating-IP;
Received: from [] (helo=[]) by with esmtpa (Exim 4) (envelope-from <>) id 1jXZ8a-0000UZ-4l for; Sat, 09 May 2020 19:44:08 -0400
References: <> <> <> <alpine.OSX.2.22.407.2005081926580.81728@ary.qy> <> <alpine.OSX.2.22.407.2005091233350.84818@ary.qy> <>
From: Asmus Freytag <>
Message-ID: <>
Date: Sat, 9 May 2020 16:44:08 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------FC83B5CA68D9CDE69F05A046"
Content-Language: en-US
X-ELNK-Trace: 464f085de979d7246f36dc87813833b26976a2cdabd2db7ab0abad036aa18d0d8ba8cbc20ba0acc8350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
Archived-At: <>
Subject: Re: [I18ndir] I18ndir early review of draft-ietf-dispatch-javascript-mjs-07
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Internationalization Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 09 May 2020 23:44:12 -0000

On 5/9/2020 11:36 AM, Barry Leiba 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's formulation possibly implies that there's some third alternative 
that SHOULD / MAY allows without mentioning it. However, if that is the 
case, the new formulation allows this third alternative in every case 
where the implementer deviates from SHOULD for any reason other than the 
one given in the MUST phrase.

MUST be one of...

SHOULD not use text/javascript unless ...

This way the limitation to the two possible forms is explicit and the 
grounds for the exception are attached to a SHOULD phrase, which 
conceptually does imply the need for a justification.

You could also quibble that a MUST phrase that has an implementer 
defined "out" is against the spirit of the thing.