IETF Logo Mail Archive

[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:27 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 5070FC1CAF2A for <media-types@ietfa.amsl.com>; Tue, 19 Mar 2024 20:27:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.115
X-Spam-Level:
X-Spam-Status: No, score=-1.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=no 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 rEeL3DCfJIjK for <media-types@ietfa.amsl.com>; Tue, 19 Mar 2024 20:27:11 -0700 (PDT)
Received: from smtp.alvestrand.no (unknown [IPv6:2a01:4f9:c010:a44b::1]) (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 D6A53C18DB95 for <media-types@ietf.org>; Tue, 19 Mar 2024 20:27:10 -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 AB2744E779; Wed, 20 Mar 2024 04:27:03 +0100 (CET)
Message-ID: <ed01e7f9-49a5-46f3-b0e9-f9f516f55f98@alvestrand.no>
Date: Wed, 20 Mar 2024 13:27:00 +1000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: 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>, Martin Thomson <mt@lowentropy.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>
From: Harald Alvestrand <harald@alvestrand.no>
In-Reply-To: <CAN8C-_K5EvziAE6h4AMnLtmFsfdNxi=ar16pzWZzfaj9cGBAtA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/media-types/gIEazVBmB8Zih1KNsUHfvdFpV9Q>
Subject: [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:27:15 -0000

One particular note:

On 3/8/24 04:38, Orie Steele wrote:
> Servers could decide to respond with content types they support, not 
> necessarily what the client requested with the accept header, so you 
> might see:
>
> GET https://issuer.example/credentials/123 --accept application/foo+jwt
> => response => content-type application/foo+json+jwt

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.

I don't think we should say anything that sounds like we're encouraging 
that.

v2.23.0 | Report a Bug | By Email