Re: [dispatch] Fwd: WGLC: draft-ietf-dispatch-javascript-mjs-02.txt

Bradley Meck <bradley.meck@gmail.com> Thu, 19 July 2018 13:02 UTC

Return-Path: <bradley.meck@gmail.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69129130DE0; Thu, 19 Jul 2018 06:02:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 eR4xtARelWDb; Thu, 19 Jul 2018 06:02:15 -0700 (PDT)
Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18FF91277CC; Thu, 19 Jul 2018 06:02:15 -0700 (PDT)
Received: by mail-io0-x233.google.com with SMTP id q9-v6so6967793ioj.8; Thu, 19 Jul 2018 06:02:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CNUf4YyycZEOpGBl/5ZPjPCdkadLQnVnGQfIujWiwls=; b=R1p4ghHkEIZk52qA7r7HnpReQyxheTRAlRS9JtAorKm+qDgI+hxK1MWSvZeLiJF8Pt LSbPsuA1esqyJ6rgWrT5m8CS9Lo6UpX8yghSo/LeHgkO6pdMhuOrhQ3cL12z7Ono4/mn hqsWkZhnKq4oBMuzxayZ2WFscLGCIdy8z6hkbZfJClJ3+9OgZMQoptG6AzoPKdSr4lc9 +tPUSfoNAXoEon7uL2HIsTpMIspt/ntZjL3OENYhGGQSnd7U7HbEQRNjEj+iiPTnzy3S Uw7AsyYQ6OHUg+fC36+F2vo/2VC7GKbcmkGc/jCWoQqiBdabwHD/IGFY2YDxkprmNka3 q7wQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CNUf4YyycZEOpGBl/5ZPjPCdkadLQnVnGQfIujWiwls=; b=sOrQroc8qEUjO+3K7e6X+dLHYJGaiJzpgvZ5zJOf08aBTpsbCNayNZFxC587sQCUqi 3c/dYGWgxXiAyvNt2VeJQw3bfdSy+NkOPvh5eQw9v55mukvtEE/bc9tphS4SNdtdPnCM 5U0VXspB4SGXAz+1Pc1IjMJgONjMUy23eexbCbWyLMF3CWhnLZmuiPdXNbCbcO2T6v+L mmG4d3UgI2e5EBRKl6G+0F5468LApq73qa/tQFOg7WMcWWq3UzViGQ4qhrGnpjwi5/yq eUW/HiXts48AFDgIANttsV5VceJXEAMYiOZlEYJsaOJnTW/kgYszgHl/EJUxOJlGs4vj twSA==
X-Gm-Message-State: AOUpUlG15fOpvI+VI9dPgfQ8iFbVW4CXk/wVLX9h+Hduf09AJg154x1P sptdNfyx+V/CdABfxtZ6TPo08RSHdilPn0LlCZleMw==
X-Google-Smtp-Source: AA+uWPzES69C2MyHtozlEiexLJjX7l6G3Z9RlfhtRfOuHGiu6oL1ryCiTaLbYrFkS+fzgesf69X2meKagjLUoAik9lo=
X-Received: by 2002:a6b:2614:: with SMTP id m20-v6mr8204663iom.211.1532005334353; Thu, 19 Jul 2018 06:02:14 -0700 (PDT)
MIME-Version: 1.0
References: <CAHBDyN5kB=yi_eFty2hRO4LpadKrSSY0KY-BAS2447Y84pPoWg@mail.gmail.com> <CABkgnnXEbYtc7VKisvyTEAiTbteQPT=gXF9HY=VgeSrSCo7FCg@mail.gmail.com> <CANnEKUaUuRQ5NrLafcg_BtVKTdf+NNgDUEfn0h2oWh4R1F6+xw@mail.gmail.com> <CANnEKUbBY4XsFsR_-zP1v_PJnav6mhtFUBC5YOGt1OrzNNSzew@mail.gmail.com> <CABkgnnWnhoW8Om9DKgiTXMcC466d9y_4zDy0newrb5LFWqO47Q@mail.gmail.com> <000001d41dd8$a2ad12e0$e80738a0$@acm.org> <CANnEKUZCyb29-_e-6FKrqM0vbJyiZkOSuFj_0GZAq5ve4H=wFg@mail.gmail.com> <00a501d41f17$63233e70$2969bb50$@acm.org>
In-Reply-To: <00a501d41f17$63233e70$2969bb50$@acm.org>
From: Bradley Meck <bradley.meck@gmail.com>
Date: Thu, 19 Jul 2018 08:02:04 -0500
Message-ID: <CANnEKUZA7YWVhDGV7t5LescEivOoNWq3sbasXuJtd9orwHrj=g@mail.gmail.com>
To: Larry Masinter <LMM@acm.org>
Cc: DISPATCH <dispatch@ietf.org>, draft-ietf-dispatch-javascript-mjs@ietf.org
Content-Type: multipart/alternative; boundary="000000000000bf8b9d057159c9d8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/YzdMxH6m4ilr1Dv3tliXW-vFA9A>
Subject: Re: [dispatch] Fwd: WGLC: draft-ietf-dispatch-javascript-mjs-02.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Jul 2018 13:02:18 -0000

I think reflecting reality is important, is the only concern the number of
types / review time? Should that be split into a separate RFC to add all
the obsolete types so that it can take more time to land all of those.
Regardless of intent, there MIMEs are in use and part of the web standards
used by browsers. Having them documented/registered seems important if the
MIME registry is intended to reflect actual usage.

On Wed, Jul 18, 2018 at 11:17 PM Larry Masinter <LMM@acm.org> wrote:

> I was hoping to avoid stuffing the MIME registry with (and making everyone
> review) lots of useless obsolete templates; the use of OBSOLETE in
> “Intended use” should only be for previously registered types. Not new
> (dubious) registrations.
>
>
>
> *Sent:* Tuesday, July 17, 2018 7:25 AM
> *To:* LMM@acm.org
> *Cc:* DISPATCH <dispatch@ietf.org>rg>;
> draft-ietf-dispatch-javascript-mjs@ietf.org
> *Subject:* Re: [dispatch] Fwd: WGLC:
> draft-ietf-dispatch-javascript-mjs-02.txt
>
>
>
> Per https://github.com/bmeck/I-D/issues/2
>
>
>
> The extra registrations are to match up with the Web specification on
> accepted MIME types for historical reasons
> https://mimesniff.spec.whatwg.org/#javascript-mime-type
>
>
>
> On Tue, Jul 17, 2018 at 9:15 AM Larry Masinter <LMM@acm.org> wrote:
>
> ➢ Only `text/javascript` is not obsolete per
> https://html.spec.whatwg.org/multipage/scripting.html#scriptingLanguages
> <https://html.spec..whatwg.org/multipage/scripting.html#scriptingLanguages>
>
> I wonder about the utility of newly registering (or updating the
> registration) of types that are obsolete.
> If there’s significant deployment of names that new implementations need
> to be aware of, then ‘obsolete’ isn’t the right status; if not, then who
> would use the new, but obsolete, definition?
>
> Larry
> http://LarryMasinter.net
>
>
>
>