From nobody Mon Feb 14 00:45:22 2022 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FBA93A0C97 for ; Mon, 14 Feb 2022 00:45:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 fb5i_Q7Yv_2V for ; Mon, 14 Feb 2022 00:45:15 -0800 (PST) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 2ECC23A0C87 for ; Mon, 14 Feb 2022 00:45:15 -0800 (PST) Received: by mail-io1-xd31.google.com with SMTP id y84so19071751iof.0 for ; Mon, 14 Feb 2022 00:45:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zgfL9WswNM/JssionSLMY5kWzdODTFmv0p2jujv+J0Q=; b=AtzOqI/+FLLuhvYXDPrjZPBfVVrmXsbiM1crpmDhx6J4U7fcnJcwbH18XtU3LR03Nh sLRiebtNV8xegqfrKSay/NM8Hhm3vyEE1C3ObP4nQ3rMnZ63kcb3oL9vowRcf2JloP5N J1Dx0kbsfG9FhwZwkkcJd26KfEpd4a0gx/GT6kbd+fUV/npl6e08aJ0fVLfY6GVM+DU+ ctp+WgIIljx9k/csYR+kkiOAE+TxA2S2W7QqCVwssgkzpqI/ZEpidHlsaZITzomG5Iqr KJ4y33WVU5WFZ/prg1CuK9AN3NLeq6SgVZ8qENSpZFVcvr3BZiQOo0OAvJgdtMA4jiip ZmRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zgfL9WswNM/JssionSLMY5kWzdODTFmv0p2jujv+J0Q=; b=v10Up6H2XH0XoZ6UYSHYFyXE+B53+FXxU0l/KweCeq8Q9Dr6JqHmv8jGTUXMN8zcWm dLd2wUAcPBNvjrOuq+JfDrncf+EljX8IblXXFALiVifwaG75vPynen+V/NEUwzvLaL/h hq2mqyASwsBN3rO5J0GPLfnSS/BnQChNtB56WQso+0k5pvGIZlSwxmEianF0KRn42LcU WrjaHMv5dz8dCMxXR1bJCaP+SFnN+JlDpjFzRq/rI8YwZj0kH7ZYjZOEqNghezBszXwO uoZD8ioHGJIKB1XFLtaazS5+Cye+n6S6ur/O9MqTJRSTbMWhgncLKZjNPQCTvU2pzBda AxDg== X-Gm-Message-State: AOAM531EE0I8UgW9FPh81kIky+dJx8jH6X5lL/Jw0qv1O/br9AelGTPs V/nrYY/RMMWbmrf8SpxG3B7o5VX/rEspkivXZ2OKQXTo8ezIpw== X-Google-Smtp-Source: ABdhPJwlKGem9Pj/FwfCL6gYh76CAFwleoYpObrfIqmHjctd0AaBAFg9MjBKukuqFDAnAxKyO3Ik+/BeZ3k3oVyTAHM= X-Received: by 2002:a05:6602:2a48:: with SMTP id k8mr6596413iov.147.1644828313384; Mon, 14 Feb 2022 00:45:13 -0800 (PST) MIME-Version: 1.0 References: <054f7a17-d8df-42a6-9d36-0f3aca00c159@beta.fastmail.com> In-Reply-To: <054f7a17-d8df-42a6-9d36-0f3aca00c159@beta.fastmail.com> From: Herbert Van de Sompel Date: Mon, 14 Feb 2022 09:45:02 +0100 Message-ID: To: Martin Thomson Cc: HTTP APIs Working Group Content-Type: multipart/alternative; boundary="00000000000055fa6805d7f66fc7" Archived-At: Subject: Re: [httpapi] Using Date in requests X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2022 08:45:22 -0000 --00000000000055fa6805d7f66fc7 Content-Type: text/plain; charset="UTF-8" Dear Martin, Probably not really relevant for you but the Memento "Time Travel for the Web" protocol [1] uses dates in requests using the Accept-Datetime header as a means to do content negotiation in the datetime dimension. The major motivation for devising the protocol was achieving a level of interoperability across web archives. But the protocol can be supported by all systems that support datetime-based resource versioning such as wikis etc. Greetings Herbert Van de Sompel [1] HTTP framework for time-based access to resource states - Memento. Herbert Van de Sompel, Michael L. Nelson, Robert Sanderson. RFC 7089. http://www.rfc-editor.org/rfc/rfc7089.txt On Wed, Feb 9, 2022 at 6:30 AM Martin Thomson wrote: > Hi Everyone, > > I've just posted > https://www.ietf.org/archive/id/draft-thomson-httpapi-date-requests-00.html > which talks about how to use Date in requests. This is not a typical thing > you see, but some of the things we're doing elsewhere makes this relevant. > For example, signing requests [1] and oblivious HTTP [2] - depending on > circumstances - might want to use Date for managing anti-replay. > > I'm bring this here as I think that this group has more direct expertise > and the work is related to some of the other stuff you are doing, like the > idempotency-key, which is complementary. This also uses the problem > details work (RFC 7807bis) for signaling when Date is missing or incorrect. > > I'm happy to go into the use case in more detail if the content of the > draft isn't clear enough. Mostly, I'm just doing this so there is a > complete and robust solution for how to manage replay for the > aforementioned work. > > Cheers, > Martin > > > [1] > https://httpwg.org/http-extensions/draft-ietf-httpbis-message-signatures.html > [2] > https://ietf-wg-ohai.github.io/oblivious-http/draft-ietf-ohai-ohttp.html > > -- > httpapi mailing list > httpapi@ietf.org > https://www.ietf.org/mailman/listinfo/httpapi > -- ================== Herbert Van de Sompel https://hvdsomp.info https://orcid.org/0000-0002-0715-6126 --00000000000055fa6805d7f66fc7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Martin,

Probably not re= ally relevant for you but the Memento "Time Travel for the Web" p= rotocol [1] uses dates in requests using the Accept-Datetime header as a me= ans to do content negotiation in the datetime dimension. The major motivati= on for devising the protocol was achieving a level of interoperability acro= ss web archives. But the protocol can be supported by all systems that supp= ort datetime-based resource versioning such as wikis etc.

Greetings

Herbert Van de Sompel
=
[1] HTTP framework for time-based access to resource states = - Memento.=20 Herbert Van de Sompel, Michael L. Nelson, Robert Sanderson. RFC 7089. http://www.rfc-editor.org/= rfc/rfc7089.txt

On Wed, Feb 9, 2022 at 6:30 AM Martin Thomson= <mt@lowentropy.net> wrote:<= br>
Hi Everyone,

I've just posted http= s://www.ietf.org/archive/id/draft-thomson-httpapi-date-requests-00.html= which talks about how to use Date in requests.=C2=A0 This is not a typical= thing you see, but some of the things we're doing elsewhere makes this= relevant.=C2=A0 For example, signing requests [1] and oblivious HTTP [2] -= depending on circumstances - might want to use Date for managing anti-repl= ay.

I'm bring this here as I think that this group has more direct expertis= e and the work is related to some of the other stuff you are doing, like th= e idempotency-key, which is complementary.=C2=A0 This also uses the problem= details work (RFC 7807bis) for signaling when Date is missing or incorrect= .

I'm happy to go into the use case in more detail if the content of the = draft isn't clear enough.=C2=A0 Mostly, I'm just doing this so=C2= =A0 there is a complete and robust solution for how to manage replay for th= e aforementioned work.

Cheers,
Martin


[1] https://httpwg.org/= http-extensions/draft-ietf-httpbis-message-signatures.html
[2] https://ietf-wg-ohai.git= hub.io/oblivious-http/draft-ietf-ohai-ohttp.html

--
httpapi mailing list
httpapi@ietf.org<= br> https://www.ietf.org/mailman/listinfo/httpapi


--
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Herbert Va= n de Sompel
--00000000000055fa6805d7f66fc7--