Return-Path: X-Original-To: httpapi@mail2.ietf.org Delivered-To: httpapi@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 7DA8B12D6BCEB for ; Fri, 21 Aug 2026 08:55:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1787327704; bh=pKwo8YLBVMxosS27Ob16hv95yKzhx5vK0FNTNo/uKUc=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject; b=nr8SX6U8kJ3x9fbdVq5AxIaVUP+tRzIlh134JPg6NlUaQwfjG/gwxiedWLv5xTIMf MgWVtJiFb77wL7SwlUMmscTV7a6hOWyQ8gXKOm3Vq9+KBcl9pbc70c8d5R3pe/5cE0 CyD1y6QJ6lauwuSyotKcEhC9ufV3HPdq/8otDBck= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujG859UM2r6a for ; Fri, 21 Aug 2026 08:55:03 -0700 (PDT) Received: from sonic322-26.consmr.mail.bf2.yahoo.com (sonic322-26.consmr.mail.bf2.yahoo.com [74.6.132.81]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 8BF8A12D6BC95 for ; Fri, 21 Aug 2026 08:55:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1787327697; bh=W6TjwQLwxtjLhu0U1R0+iYeOsBKHjDNZC6+eSAjg+p4=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=UksUVwgsyYzfN2Kgekgf2TwpC7XPLi4RSZosHJxHKCWDxR0mXRW68HJgJanKNkCzHTKbDZmnUWTcj6Uo1ZaVvnCimdj2LB3knTNzOA5DCekWhtlmitb9Mh4+9BdfA55KaNttqWtp6MujfpV4vLxRCRANlx4j2KO+a3nf8R+82L7lsGRr+ljJwGJ5XFYRomZaj3bS/thxWCAkXDvsgZ80QGteT02fcIJcJOpGuPEQAqhEBJcP4CkmqshRIWY91Z4hRSBC0vLW+VMVXMTgBUbhmhIhO7DRzGiXVUkK+k7eZ3x+oX2X9rrY+81j9J+gi3PacCI39DJlHJWIYya0UaX/mQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1787327697; bh=oI1vj1hefI00gEw+vh0oLqDlWWYi6Q0BiUQ7YEHcGHL=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=Ym4qkwwSjOE9puo6MCQ8MSpdJVE0dA8bOYWXuNVMnfYy2FHgah26eem79ml7cNa9ixlVjHv1ETSQgUxG50uRUycbn0fRkBuFd6GLZboOE0Xqs2EG60k6647rxg9rhGR1pFCStRSCm9u+Kg/cKXNCRtmVgazVMnuFrP5PUM5T4HYjqMkjaMMW7CFbc+ox1dUFLfDYqxeWaDPkhf3WQ+g7MHM5xTqkb0aqTG0hADME8LREch+SZv6nvqpIHMxu5JCNnhL5WOj9EHdwSL8kCA71K74UmzXfYYA1G8Ybs8ceIwsjg0y0vrz2uu780mAoi23JKYRlimQCaJkowXsejqUVeg== X-YMail-OSG: 27f5kpAVM1m2UOqRmqG1Nl77vmt9XuqsgWgv7RZiqq4Y2AP.ep8uLMR7cAcDBEH wdT0FF2J16QfSdWd66yMhy5UmwbwjQNJ6LtxuzEOkOzPaX3mHxqjD_kyUn3RYZBwlAinb1L6VAle JSCxetW.u6SyVhApvCQ.trhrRLiKmjKG8oF8QvJc2MKZbudbkUMH61V3Zge1RVLYtT9gnLI8APNw zYrIbp8XWzlCvC5ZXKoAHAvM9hcEbKCbYvPoaslOHkgRZBZqnsDDqGWpgxcwfbKTihFBUAIa_fT4 uKi0sx6BxrXf.iybKhZneTwM6ibAgvEyECi7AtPJZDQmF33s3xRXGbuwu7etg1umfSgTaarwF0iA 9JuExxv07OEPSIk99XY9Xqw51.9LicUNmJOJbg3GKk_iOEaXolt5ctgszZwQx1zmIgE1CB9XAVfV 652ttG1viapFx22uGP75kx.V4CMqDViWASubucirz9y6WI3uCMVf3j14JS.H7yA3HqqCUV0Ik43y bl8jzxsadcSl5kTxLp7X8Fs3i.nda9k9QIkpzsZ2OWHOu.9IIDF0Lgx10ALlSCpt7Ejqy7aDTcj2 btf3V0l10gkfky6KjJXfFO36QraQ72CK0ggtWwhSvmpsiDfBRbnVtr559Kr3MXuf99MqYFx5Nu2K 4mMHYUrbEbuBpCNJrM4D6.98lrrehPAiDFTpYPM24StxFOOnLQAldvTn6ChHPa9GpMGxXjoqWuw0 H.iLan5iFqN1Z3C_eRz4HQ_6i7DaGcKHeGXU7fVtCfRuXIGUAXpa7XTAtA6Uo1DYPVsYEmA1qZsf y.VLPCvJeBNzYlOKpe4urJ7sxM0DzNENnVSGY4k79MgZoXWqqCNCzuBlGeIEcBXStntQHZGGG1Fq 72VaxyrkKnHsospgW.7RFVvs1tKq_hHiWK51NFoq21q1jZvIN9wp7OTK6RkDS.sdebAUumRvnnv4 c1DQqcNIuHcSyYs6OG3CpN.QJtyUWf232cTECZ85e6RA4UvD73TGmRTCerfatMdD0kJYZDL0Uq60 wtD2ga8W6MDkD.LNfmT146BUKUfAlIv47vDJGO66L.yfVZFKYES.30mpb0SLKO6QOj2505auMC4y ngQUnsrhW5K0qqTfAQJppbpQ0w1QNc51MkLGeJOiqIFtVUOmuY9NJ.slJ_WyQc6wC1OJbAqKg4rX aqszsFscFmiY5FVajRT8xLQZ48GNJoBDOQNYMfDnL8k16_4Cq9KjdGpVwk3Kdw7W8r_L9ldhsxuV FXsJ6.mexOc59UI9KLCnP3PeagTtMPK7vKzQJovb3Oui2zXc.aj9kWv_t8l30c9GWbOlWAv7neBh tmfTH5mw3jDak2MI6XKlxTXYqhc5grZRqU_QPjV1NNlYUNktOssmwKGPDVaMdObuggoolfb8RZf0 jNrmADyFejHVGI39pdfyoQ7G2VBadSdkq_M3eLHYmXe_nlMiCMRsyzTB8awQn0ztNoElT2Y87q8X 7neoi5Heve8mt3CIlCRK.bW5c9CdHcX_V7PYOJcC.rnOVmPYJOn5vU268OoKwwT5bBAsHZRTa6Na 9Tquy9oCV_R8pdjvr1PWRTWFq1tT2GvhlYvyxHPy15i7NfZOEJv8U5sjod4yw869dg3v19kagsTB Ak2REpymKK8fD7kd7EmxzXKh5.ufDot3ONybqrjsTHFybRdjXTUYCCJYpl854g99SHcFbP22aqZ6 DQMcaA85sN6kHjG873RrwzMMQBYIog3BdTtdT6cQzcx9W7hVhqtbsFVdJgP6hI0U5AWMIgCdH0WC gYrkJ_sIKOPheOSpAXDTLIMo1kEl66fQE6UYU148CpLMaslhxIUWh9GdA83LGCYgZPx33yoCj5H2 wh4EwSL1wNpxM49vdr0u3RglV76e.8DXOXf.nRszTpZjzR8OcZgmE4PcnUmSCbHxLq5ej4MxzYA6 VAwit9qXdMyOxWWuwVKHVst.buxPf1fr3pyWVHFgx5EPLfIhP4Cb_eCaWvLlIAnY4v9B2kU4dHJ1 fPymoPk0Cd1jECGaCt_Y1bTskBnrxhfDaGz9jFRdmxLsk8MqyXEgSNtB6OPLKo0f9AXYkAeqPDoW hve5gpnu5W9YfNKITTyCBYOlaT_8Hm2.k2kCvtUnY1IKAn9IWS9vuymSwCEp.QyGzf1DO.vrLc5K 0yiwYSuAZndHrEAr_dEn8aLtBY6vGjOZ0Re.Cr2WP.65S5rnheyErZ0EUWwyciuIViEnEkd8rZb5 Cldc2cqqayCe18ekWdhW5NEG3IJgad8DF7Inq4hXzHShliIeTQmucHzi1KDdLCogxSY3Pa8N7Xa1 brEIww0aX0v564we.DNeHfo1W2wL9uZALq8rWorDomEqUBf_nsC77DeKydFJFYQ-- X-Sonic-MF: X-Sonic-ID: 6ea92c56-15ed-4d34-996c-7ea48111c7e1 Received: from sonic.gate.mail.ne1.yahoo.com by sonic322.consmr.mail.bf2.yahoo.com with HTTP; Fri, 21 Aug 2026 15:54:57 +0000 Date: Fri, 21 Aug 2026 15:54:56 +0000 (UTC) From: Henry Andrews To: "Salz, Rich" , "sanjay.dalal@cal.berkeley.edu" , "httpapi@ietf.org" , Sami Rmili Message-ID: <1617799397.3154817.1787327696423@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3154816_204808381.1787327696420" X-Mailer: WebService/1.1.26254 YMailNorrin Message-ID-Hash: 2PUOOMNHVS7D2OE7NACWDBWC5D7YOTWU X-Message-ID-Hash: 2PUOOMNHVS7D2OE7NACWDBWC5D7YOTWU X-MailFrom: andrews_henry@yahoo.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9rc6 Precedence: list Reply-To: Henry Andrews Subject: =?utf-8?q?=5Bhttpapi=5D_Re=3A_New_draft=3A_draft-rmili-httpapi-deprecation-m?= =?utf-8?q?anifest-00_=28field-level_deprecation_signalling=29?= List-Id: Building Blocks for HTTP APIs Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: ------=_Part_3154816_204808381.1787327696420 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It's worth noting that in OpenAPI-land, we are spinning off a Lifecycle sp= ecification to work on concepts related to this.=C2=A0 It will be a separat= e specification but not a separate JSON/YAML description document.=C2=A0 We= are just modularizing the specification.=C2=A0 This work is just getting s= tarted and the main discussion is at=C2=A0https://github.com/OAI/sig-lifecy= cle/discussions/5 thanks,-henry On Thursday, August 20, 2026 at 02:24:09 AM PDT, Sami Rmili wrote: =20 =20 Rich, Sanjay, Rich, thanks for the welcome. I wrote -00 in kramdown-rfc but built it by h= and, so I will set the draft up properly on i-d-template for -01, this is a= ll very new to me. Sanjay, I'm excited to learn that this is of interest to you and I would lo= ve to collaborate on this topic. One clarification though: the Link does no= t point at the OpenAPI document. It points at the manifest, a small document discovered at runtime from the resource being called via rel=3D"de= precation", which names the specific request or response member and gives i= ts deprecation and sunset dates. Very happy to take a call on this, and a review whenever suits. Thanks, -- |=20 |=20 |=20 |=20 Sami RMILI Software Engineer srmili@wiremind.io 16, boulevard Poissonni=C3=A8re - 75009 Paris, France | |=20 | | | | | | Le=C2=A0mer. 19 ao=C3=BBt 2026 =C3=A0=C2=A019:39, Salz, Rich a =C3=A9crit=C2=A0: Thanks for the note, and (a) welcome to the IETF and (b) congrats on your f= irst draft. Looking at it, I assumed you used the i-d-template draft toolin= g, which is really what I=E2=80=99d recommend anyway :) I assume that things crossed in the mail, and that you saw Sanjay=E2=80=99s= reply of being interested in this. On 8/19/26, 12:02=E2=80=AFPM, "Sami Rmili" wrote: This Message Is From an External SenderThis message came from outside your = organization.=C2=A0Hi Rich, As far as I know I'm the only person interested in it so far, no reviews on= -list. The need came out of our implementation of OSDM (an open UIC rail-distribut= ion API standard). The shared OpenAPI schema marks fields deprecated betwee= n minor versions, but that flag carries no dates and no single implementor = can edit the shared schema=C2=A0to declare their own deployment's timeline.= Ans as far as I could find, there's no standard way to say which field exa= ctly is deprecated:=C2=A0RFC 9745 and RFC 8594 operate at the granularity o= f a resource, not a member inside a request or response body. That gap is t= he whole reason I wrote the draft. I'm actively trying to get OSDM to adopt this as we speak, so I do expect t= here to be real interest behind it. In the meantime I'd be very glad of a r= eview of the draft. I should say this is my first time writing an Internet-Draft, so pointers o= n process are as welcome as technical comments. And I'm happy to explain th= e need in more detail, over a call too if that would help. Thanks,-- |=20 |=20 |=20 |=20 Sami RMILI Software Engineer srmili@wiremind.io 16, boulevard Poissonni=C3=A8re - 75009 Paris, France | |=20 | | | | | | Le=C2=A0mer. 19 ao=C3=BBt 2026 =C3=A0=C2=A015:54, Salz, Rich a =C3=A9crit=C2=A0: Has anyone reviewed or read this draft? Is anyone interested in working on it? On 6/29/26, 6:31=E2=80=AFAM, "Sami Rmili" wrote: Hi all, I've posted a -00 that I'd appreciate feedback on: https://datatracker.ietf= .org/doc/draft-rmili-httpapi-deprecation-manifest/ The gap: =C2=A0The Deprecation (RFC 9745) and Sunset (RFC 8594) header fields signal= lifecycle at the granularity of a resource. They cannot, by design, name a= n individual member inside a JSON request or response body. The mechanisms = that can name a member, the deprecated keyword in OpenAPI and JSON Schema a= re design-time, carry no dates, and live in a single shared description. So= an operator of a multi-party API spec has no standard way to say "on my de= ployment, this particular field stops being accepted on this date." The proposal: =C2=A0An application/deprecations+json document,=C2=A0 a "Deprecation Manif= est" in which an operator declares dated deprecation and sunset timelines f= or specific request/response members. It's discovered via the existingrel= =3D"deprecation" link relation, is decoupled from any API description, and = is purely informational, it never changes the wire behaviour of a resource.= It reuses the date semantics of RFC 9745/8594 rather than replacing them. Origin:=C2=A0This comes from a real need as an implementor/contributor ofOS= DM (an open UIC rail-distribution API standard). The OpenAPI schema is shar= ed by everyone who implements the standard, and it evolves: between two min= or versions, a field gets marked deprecated in favour of a replacement. But= that deprecated flag in the shared schema is undated, and no single implem= entor can edit the shared schema to add their own dates. So even though the= standard says a field is on its way out, each operator is left with no sta= ndard way to declare when their own deployment will stop accepting or retur= ning it (i.e. its actual deprecation and sunset dates). The manifest lets e= ach implementor publish that per-deployment timeline without touching the s= hared contract. I expect to ship one in the OSDM ecosystem, which should gi= ve the design some running code to evaluate. I'd particularly welcome views on whether this belongs as a discovery docum= ent alongside RFC 9727 (api-catalog), and on the selector design (JSONPath = / JSON Pointer). Thanks,-- |=20 |=20 |=20 |=20 Sami RMILI Software Engineer srmili@wiremind.io 16, boulevard Poissonni=C3=A8re - 75009 Paris, France | |=20 | | | | | | The content of this email is confidential and intended for the recipient sp= ecified in message only. The content of this email is confidential and intended for the recipient sp= ecified in message only. The content of this email is confidential and intended for the recipient sp= ecified in message only.--=20 httpapi mailing list -- httpapi@ietf.org To unsubscribe send an email to httpapi-leave@ietf.org =20 ------=_Part_3154816_204808381.1787327696420 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It's worth noting that in Op= enAPI-land, we are spinning off a Lifecycle specification to work on concep= ts related to this.  It will be a separate specification but not a sep= arate JSON/YAML description document.  We are just modularizing the sp= ecification.  This work is just getting started and the main discussio= n is at https://github.com/OAI/sig-l= ifecycle/discussions/5

=
thanks,
-henry


=20
=20
On Thursday, August 20, 2026 at 02:24:09 AM PDT, Sa= mi Rmili <srmili=3D40wiremind.io@dmarc.ietf.org> wrote:


=20 =20
=
Rich, Sanjay,

Rich, thanks for the welcome. I wrote= -00 in kramdown-rfc but built it by hand, so I will set the draft up prope= rly on i-d-template for -01, this is all very new to me.

Sanjay, I'm= excited to learn that this is of interest to you and I would love to colla= borate on this topic. One clarification though: the Link does not point at = the OpenAPI document. It points at the manifest, a small
document discov= ered at runtime from the resource being called via rel=3D"deprecation", whi= ch names the specific request or response member and gives its deprecation = and sunset dates.

Very happy to take a call on this, and a review wh= enever suits.

Thanks,
--
=

3D"img"

Sami RMILI
Software Engineer<= br>srmili@wiremind.io<= /a>

16, boulevard Poissonni=C3=A8re - 75009 Paris, France<= /span>

3D"linkedin"=3D"web"
<= /td>



Le mer. 19 ao=C3=BBt 2026 =C3=A0 19:= 39, Salz, Rich <rsalz=3D40akamai.com@dmarc.ietf.org> a =C3=A9crit :
Thanks for the note, and (a) welcome to the IETF and (b) congrats on your f= irst draft. Looking at it, I assumed you used the i-d-template draft toolin= g, which is really what I=E2=80=99d recommend anyway :)

I assume that things crossed in the mail, and that you saw Sanjay=E2=80=99s= reply of being interested in this.



This Message Is From an External Sender
This message came from outside your organization.
 
Hi Rich,

As far as I know I'm the only person interested in it so far, no reviews on= -list.

The need came out of our implementation of OSDM (an open UIC rail-distribution API standard). The shared OpenAPI s= chema marks fields deprecated between minor versions, but that flag carries= no dates and no single implementor can edit the shared schema to decl= are their own deployment's timeline. Ans as far as I could find, there's no standard way to say which field exa= ctly is deprecated: RFC 9745 and RFC 8594 operate at the granularity o= f a resource, not a member inside a request or response body. That gap is t= he whole reason I wrote the draft.

I'm actively trying to get OSDM to adopt this as we speak, so I do expect t= here to be real interest behind it. In the meantime I'd be very glad of a r= eview of the draft.
I should say this is my first time writing an Internet-Draft, so pointers o= n process are as welcome as technical comments. And I'm happy to explain th= e need in more detail, over a call too if that would help.

Thanks,
--

3D"img"

= Sami RMILI
Software Engineer
srmili@wiremind.io=

16, boulevard Poissonni=C3=A8re - 75009 Paris, France
3D"linkedi= 3D"web"

=
Le mer. 19 ao=C3=BBt 2026 =C3=A0 15:54, Salz, Rich <rsalz=3D40akamai.com@dmarc.ietf.org> a =C3=A9crit :
Has anyone reviewed or read this draft?

Is anyone interested in working on it?

On 6/29/26, 6:31=E2=80=AFAM, "Sami Rmili" <srmili=3D40wiremind.io@dmarc.ietf.org> wrote:

Hi all,

I've posted a -00 that I'd appreciate feedback on: https://datatracker.ietf.org/doc/draft-rmili-httpapi-deprecation-manifest/<= /a>

The gap:
 The Deprecation (RFC 9745) and Sunset (RFC 8594) header fields signal= lifecycle at the granularity of a resource. They cannot, by design, name a= n individual member inside a JSON request or response body. The mechanisms = that can name a member, the deprecated keyword in OpenAPI and JSON Schema are design-time, carry no dates, and li= ve in a single shared description. So an operator of a multi-party API spec= has no standard way to say "on my deployment, this particular field stops = being accepted on this date."

The proposal:
 An application/deprecations+json document,  a "Depreca= tion Manifest" in which an operator declares dated deprecation and suns= et timelines for specific request/response members. It's discovered via the= existing rel=3D"deprecation" link relation, is decoupled from any API descrip= tion, and is purely informational, it never changes the wire behaviour of a= resource. It reuses the date semantics of RFC 9745/8594 rather than replac= ing them.

Origin:
 This comes from a real need as an imple= mentor/contributor of OSDM (an open UIC rail-distribution API standard). The OpenAPI schema i= s shared by everyone who implements the standard, and it evolves: between t= wo minor versions, a field gets marked deprecated in favour of a replacemen= t. But that deprecated flag in the shared schema is undated, and no single implementor can edit the shared sc= hema to add their own dates. So even though the standard says a field is on= its way out, each operator is left with no standard way to declare when th= eir own deployment will stop accepting or returning it (i.e. its actual deprecation and sunset dates). The manife= st lets each implementor publish that per-deployment timeline without touch= ing the shared contract. I expect to ship one in the OSDM ecosystem, which = should give the design some running code to evaluate.

I'd particularly welcome views on whether this belongs as a discovery docum= ent alongside RFC 9727 (api-catalog), and on the selector design (JSONPath = / JSON Pointer).

Thanks,
--

3D"img"

= Sami RMILI
Software Engineer
srmili@wiremind.io=

16, boulevard Poissonni=C3=A8re - 75009 Paris, France
3D"linkedi= 3D"web"

The content of this email is confident= ial and intended for the recipient specified in message only.

The content of this email is confident= ial and intended for the recipient specified in message only.
<= /div>

The content of this email i= s confidential and intended for the recipient specified in message only.
--
httpapi mailing list -- httpapi@ietf.org
To = unsubscribe send an email to httpapi-leave@ietf.org
------=_Part_3154816_204808381.1787327696420--