Re: [media-types] HTTP replying with what clients don't support (Re: Last tracker issue for mediaman-suffixes)

Harald Alvestrand <harald@alvestrand.no> Wed, 20 March 2024 03:46 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: media-types@ietfa.amsl.com
Delivered-To: media-types@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F092C151093 for <media-types@ietfa.amsl.com>; Tue, 19 Mar 2024 20:46:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuyiSByzW00Q for <media-types@ietfa.amsl.com>; Tue, 19 Mar 2024 20:46:34 -0700 (PDT)
Received: from smtp.alvestrand.no (smtp.alvestrand.no [65.21.189.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A050EC1D4A61 for <media-types@ietf.org>; Tue, 19 Mar 2024 20:46:28 -0700 (PDT)
Received: from [31.133.131.210] (dhcp-83d2.meeting.ietf.org [31.133.131.210]) by smtp.alvestrand.no (Postfix) with ESMTPSA id 389844E77C; Wed, 20 Mar 2024 04:46:23 +0100 (CET)
Message-ID: <bf331b0b-57e7-453a-82ed-6dd3139f0a05@alvestrand.no>
Date: Wed, 20 Mar 2024 13:46:23 +1000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Martin Thomson <mt@lowentropy.net>, Orie Steele <orie@transmute.industries>, Carsten Bormann <cabo@tzi.org>
Cc: Manu Sporny <msporny@digitalbazaar.com>, Michael Jones <michael_b_jones@hotmail.com>, IETF Media Types <media-types@ietf.org>, Darrel Miller <darrel@tavis.ca>, Mark Nottingham <mnot@mnot.net>
References: <CAMBN2CQbfAW2pmmxZZgbBOTUzY+TdYe5S8ve5cX_R30PXZJ=+w@mail.gmail.com> <CAN8C-_JGre8jtAenDCrV7JSwJWPhf9K7K6HiC4_cX6E+YLru+Q@mail.gmail.com> <CAMBN2CQy6GzJiZvU2fkvrDSLGpk=K-HUxv1Gwd8cDxEhjojtHw@mail.gmail.com> <PH0PR02MB7430A03285ECC49CADF584FAB7232@PH0PR02MB7430.namprd02.prod.outlook.com> <68739467-3819-4D6C-81F4-17AFE3D0A3E9@tzi.org> <CAMBN2CQVKmc9=hmm+rK2wK4aNVJfR_YDMEYUQJadzUiZCVTCkA@mail.gmail.com> <39D0F672-53F7-4AE6-8FCE-B0CA18355E05@tzi.org> <CAN8C-_K5EvziAE6h4AMnLtmFsfdNxi=ar16pzWZzfaj9cGBAtA@mail.gmail.com> <ed01e7f9-49a5-46f3-b0e9-f9f516f55f98@alvestrand.no> <a596e2ac-a252-4e9e-9168-3fe215aa9a91@app.fastmail.com>
From: Harald Alvestrand <harald@alvestrand.no>
In-Reply-To: <a596e2ac-a252-4e9e-9168-3fe215aa9a91@app.fastmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/media-types/xTSqx8eKh_s-eHS8iEjMrRg_CHY>
Subject: Re: [media-types] HTTP replying with what clients don't support (Re: Last tracker issue for mediaman-suffixes)
X-BeenThere: media-types@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." <media-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/media-types>, <mailto:media-types-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/media-types/>
List-Post: <mailto:media-types@ietf.org>
List-Help: <mailto:media-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/media-types>, <mailto:media-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Mar 2024 03:46:39 -0000

On 3/20/24 13:28, Martin Thomson wrote:
> On Wed, Mar 20, 2024, at 13:27, Harald Alvestrand wrote:
>> This, as I understand it, is a HTTP violation no matter how I hold it:
>> the server is responding with a media type that the client has said that
>> it did not support.
> Content negotiation can be ignored.  This is not a violation of the protocol.  The response might not be useful, but it is valid.

Thanks for the correction!