From nobody Thu Oct 8 05:01:47 2020 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 0E8323A0AC6 for ; Thu, 8 Oct 2020 03:50:46 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=teamdigitale.governo.it 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 VlDud5dimvHF for ; Thu, 8 Oct 2020 03:50:44 -0700 (PDT) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 F36D33A02BB for ; Thu, 8 Oct 2020 03:50:43 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id 33so5296086edq.13 for ; Thu, 08 Oct 2020 03:50:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=teamdigitale.governo.it; s=google; h=mime-version:from:date:message-id:subject:to; bh=YMzKObFDxygE1SMKopaQJv3rrRSu5kj89Z1wCEzf+ME=; b=NbjvvNlRxuCQOwZj4kGkezhPu8Q7VKzRj8RXck6Z1epyL8kwx+JI4ZlCvSP1qJrU4x lEhJNJkj6h4Ed3iJB+NVJltfkn2u5qotA9J3Aeh2//RHFu7sshG0HVk38JBOTGSkP5u5 G9baThu4IyYYdKGQmPFh20slTuJGRQGPsJ0gxviJZfPrDjsatybqCYmbf0auX4fO28Pb alyblfWV7gaHrdbobTLrk8CJy8A2vC9fVXnjXytIoRYyMP2CrPnnBvXw6k9QFP0q7Z1M geltsIaGoXfZHWqmGnfZpzITDFFroIZNsCGdf2mgttheNYT5iKWieMVORow2PAqQYi1z gb+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=YMzKObFDxygE1SMKopaQJv3rrRSu5kj89Z1wCEzf+ME=; b=VgqXRRz0Yt8YILz6sMUbqAolziX27kOt8LaUtFAeuqwFTlo2VSv1uTQFaIueJBwvuR 6N5gke56XRxDfRrxsF1vEbeu3kOvOF4EZzUVqRkyTeVb67wrzJwoVT/yfi0gggUOnVQM 96twbnS2n3GjN53FaAO7hGuMejrAgiDLZarWSZ9UlhFwXGRVcaz4SLSf/gZxf91yLF4i l3P7vQGB7Tp2ejcQSFAchXzYvqQQPgzbM2z+f6esELetdqaQzz/sRmcs+4SGkOrMmv6A /GQbTs1u2bHS9rc1Kq8FgKSCQvcD5uNSC7gBDyAi2Y1a8e57SFYu/na+F8KmiaEp/sqY xjqQ== X-Gm-Message-State: AOAM5305UPkf/TFAzlu3ZyvIpSWseaAP+s/7qBhK77SG3yblimdH9SB3 rAWShxtX/G7DdiLw/WEbHSkCEmy5rqAY9udyjNv0gA== X-Google-Smtp-Source: ABdhPJxB/UFIQ/3HggoQwDznlt3GOnIc1eVatnVB6iDd/c/48FQaPgKUSMHkSLl1eeKGtktxHq5+l0dApgCHXUx2hzM= X-Received: by 2002:a05:6402:214:: with SMTP id t20mr8479936edv.85.1602154242008; Thu, 08 Oct 2020 03:50:42 -0700 (PDT) MIME-Version: 1.0 From: Roberto Polli Date: Thu, 8 Oct 2020 12:50:31 +0200 Message-ID: To: iesg@ietf.org, httpapi@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: X-Mailman-Approved-At: Thu, 08 Oct 2020 05:01:46 -0700 Subject: [httpapi] WG Review: Building Blocks for HTTP APIs (httpapi) 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: Thu, 08 Oct 2020 10:50:46 -0000 Dear IESG, I think the creation of this workgroup is helpful. In those years, many API communities and organizations produced competing specifications to fulfill common use cases; some of them made it into the IETF, others were (widely) deployed without a standardization attempt nor a thorough review, thus paving the way to a non-interoperable future. I see this HTTP API Workgroup as an influential table where standards' stakeholders - API gateway vendors, opensource community, and even the public sector - can coordinate to design interoperable solutions to provide better and more reliable services to people. The involvement of folks from both the OpenAPI Initiative and the HTTP Workgroup is a good starting point, and I can see that even in public institutions there is a growing interest in this topic. Kind regards, Roberto Polli - Italian Digital Transformation Department From nobody Fri Oct 9 10:01:25 2020 Return-Path: X-Original-To: httpapi@ietf.org Delivered-To: httpapi@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D33843A0D07; Fri, 9 Oct 2020 10:01:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: avezza@amsl.com, barryleiba@computer.org, httpapi-chairs@ietf.org, httpapi@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160226288338.21354.1780955066793249004@ietfa.amsl.com> Date: Fri, 09 Oct 2020 10:01:23 -0700 Archived-At: Subject: [httpapi] httpapi - New Meeting Session Request for IETF 109 X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2020 17:01:24 -0000 A new meeting session request has just been submitted by Amy K. Vezza, on behalf of the httpapi working group. --------------------------------------------------------- Working Group Name: Building Blocks for HTTP APIs Area Name: Applications and Real-Time Area Session Requester: Amy Vezza Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 50 Conflicts to Avoid: Technology Overlap: httpbis, quic, wpack, webtrans, cbor People who must be present: Rich Salz Barry Leiba Darrel Miller Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Oct 20 00:47:53 2020 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 2725D3A0A81 for ; Tue, 20 Oct 2020 00:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 0X-4gFHvctuF for ; Tue, 20 Oct 2020 00:47:49 -0700 (PDT) Received: from postoffice.gristmillmedia.com (dret.net [209.188.86.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 542CE3A0A82 for ; Tue, 20 Oct 2020 00:47:49 -0700 (PDT) Received: from 7.58.0.85.dynamic.wline.res.cust.swisscom.ch ([85.0.58.7]:50518 helo=dretpro.home) by postoffice.gristmillmedia.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1kUmN0-0000lV-RC; Tue, 20 Oct 2020 03:47:47 -0400 References: <160286059075.7187.5962795602210808788@ietfa.amsl.com> To: HTTP APIs Working Group Cc: Phil Archer , Herbert Van de Sompel , Dominique Guinard From: Erik Wilde X-Forwarded-Message-Id: <160286059075.7187.5962795602210808788@ietfa.amsl.com> Message-ID: <2f22c1f8-b304-59c7-7a55-6bf551efa42c@dret.net> Date: Tue, 20 Oct 2020 09:47:45 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <160286059075.7187.5962795602210808788@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - postoffice.gristmillmedia.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dret.net X-Get-Message-Sender-Via: postoffice.gristmillmedia.com: authenticated_id: birdhouse@dret.net X-Authenticated-Sender: postoffice.gristmillmedia.com: birdhouse@dret.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: [httpapi] Fwd: New Version Notification for draft-wilde-linkset-07.txt 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: Tue, 20 Oct 2020 07:47:51 -0000 hello! it's great to see this new working group picking up steam! attached please find a draft that we have been working on for quite a while, and which is we believe in a stage that warrants publication as an RFC. we've been told that this new working group would be a good fit, and that's definitely the case. but we also want to make sure to progress with this as quickly as possible, as we have some major implementation work (first and foremost the GS1 work listed in the draft) depending on that. it would be great to move forward with this as soon as possible. please let us know what the next steps are to make this happen. thanks a lot and cheers, dret. -------- Forwarded Message -------- Subject: New Version Notification for draft-wilde-linkset-07.txt Date: Fri, 16 Oct 2020 08:03:10 -0700 From: internet-drafts@ietf.org To: Erik Wilde , Herbert Van de Sompel A new version of I-D, draft-wilde-linkset-07.txt has been successfully submitted by Erik Wilde and posted to the IETF repository. Name: draft-wilde-linkset Revision: 07 Title: Linkset: Media Types and a Link Relation Type for Link Sets Document date: 2020-10-16 Group: Individual Submission Pages: 29 URL: https://www.ietf.org/archive/id/draft-wilde-linkset-07.txt Status: https://datatracker.ietf.org/doc/draft-wilde-linkset/ Htmlized: https://datatracker.ietf.org/doc/html/draft-wilde-linkset Htmlized: https://tools.ietf.org/html/draft-wilde-linkset-07 Diff: https://www.ietf.org/rfcdiff?url2=draft-wilde-linkset-07 Abstract: This specification defines two document formats and respective media types for representing sets of links as stand-alone resources. One format is JSON-based, the other aligned with the format for representing links in the HTTP "Link" header field. This specification also introduces a link relation type to support discovery of sets of links. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Tue Oct 20 10:09:11 2020 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 B11CD3A0BD7 for ; Tue, 20 Oct 2020 10:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bzfx.net 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 EK_LO1zb40AK for ; Tue, 20 Oct 2020 10:09:07 -0700 (PDT) Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (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 D1B3E3A0BC0 for ; Tue, 20 Oct 2020 10:09:07 -0700 (PDT) Received: by mail-pj1-x102e.google.com with SMTP id hk7so1290106pjb.2 for ; Tue, 20 Oct 2020 10:09:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bzfx.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tf8mPcFlcPPUxJfWs1syrBvemijJ49w6AKIsEUKaF48=; b=y5RF9oFxrCs5ss8I34pZqwrF/02V6o8bCeocNCrv7AumDtb3NrOtwu1VWyGr2iMqo6 apKKXNDOmDn4uJKf6MbLSuQ/VXrArgw4aMzmF6py6ByOiIR0CWscH+NKtvsNxhSNOLyH oxxZNVuqvnzVp7uM+jPZx9BhNtBLUQ7vLx1iQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tf8mPcFlcPPUxJfWs1syrBvemijJ49w6AKIsEUKaF48=; b=NA9RF+I8BNCDLEdL/anLe8MsibiHTYd765uxThgnyzf0pAakjN548d78EMJ6UOSvHs Ew2pywuz57AfM0geMNQ22RVT8VfUXnwUI/QLwdg8fkUdUYltt6+N7v18EoAJVRY/t+m5 SrFfV+AE1zkrQwAFEwEnVI/0GSIBvLb14nR0OAHx5qSx0WOotmAAHvAhepalFnM80FDH 8pm0R//d/Wgkr7doo3mNe732LOU33bEMOn87hVmujbt0rTTzVMQ9HYu+nzga6ltcLT9N IahRjKAOTo5ldoe58wumLjVAuNqjnLL7+KrjLHFqDiBhUO07jDbjfL2uvikEbDJzyn8E 5bKg== X-Gm-Message-State: AOAM531SD12LpKHsNT3+5mXxfBTkKJErDGqr8GVcRUZV1tfbJUSfasoz QbeG1nQYtzqOvCgHx8IaLObDslqaxO6+xkgB X-Google-Smtp-Source: ABdhPJyhN5WuhV973UvR6YLRnpXVVVs0srsPKBG5+zcyxuBeQGP8F7yfR2lFDsYMP1rQEKDaUhBGaw== X-Received: by 2002:a17:902:d896:b029:d2:288e:bafc with SMTP id b22-20020a170902d896b02900d2288ebafcmr3980103plz.43.1603213746843; Tue, 20 Oct 2020 10:09:06 -0700 (PDT) Received: from [192.168.0.116] (71-223-75-65.phnx.qwest.net. [71.223.75.65]) by smtp.gmail.com with ESMTPSA id a11sm2366372pju.22.2020.10.20.10.09.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Oct 2020 10:09:05 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Austin Wright In-Reply-To: <2f22c1f8-b304-59c7-7a55-6bf551efa42c@dret.net> Date: Tue, 20 Oct 2020 10:09:04 -0700 Cc: HTTP APIs Working Group , Dominique Guinard , Herbert Van de Sompel , Phil Archer Content-Transfer-Encoding: quoted-printable Message-Id: <07D8E404-53F0-4603-A6A4-A5F0BB54A32C@bzfx.net> References: <160286059075.7187.5962795602210808788@ietfa.amsl.com> <2f22c1f8-b304-59c7-7a55-6bf551efa42c@dret.net> To: Erik Wilde X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [httpapi] New Version Notification for draft-wilde-linkset-07.txt 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: Tue, 20 Oct 2020 17:09:10 -0000 Quick question: How is the application/linkset media type different from = the application/link-format media type in RFC 6690? Would it make sense to cite this as prior art? Thanks, Austin. > On Oct 20, 2020, at 00:47, Erik Wilde wrote: >=20 > hello! >=20 > it's great to see this new working group picking up steam! >=20 > attached please find a draft that we have been working on for quite a = while, and which is we believe in a stage that warrants publication as = an RFC. >=20 > we've been told that this new working group would be a good fit, and = that's definitely the case. but we also want to make sure to progress = with this as quickly as possible, as we have some major implementation = work (first and foremost the GS1 work listed in the draft) depending on = that. >=20 > it would be great to move forward with this as soon as possible. = please let us know what the next steps are to make this happen. >=20 > thanks a lot and cheers, >=20 > dret. >=20 >=20 > -------- Forwarded Message -------- > Subject: New Version Notification for draft-wilde-linkset-07.txt > Date: Fri, 16 Oct 2020 08:03:10 -0700 > From: internet-drafts@ietf.org > To: Erik Wilde , Herbert Van de Sompel = >=20 >=20 > A new version of I-D, draft-wilde-linkset-07.txt > has been successfully submitted by Erik Wilde and posted to the > IETF repository. >=20 > Name: draft-wilde-linkset > Revision: 07 > Title: Linkset: Media Types and a Link Relation Type = for Link Sets > Document date: 2020-10-16 > Group: Individual Submission > Pages: 29 > URL: = https://www.ietf.org/archive/id/draft-wilde-linkset-07.txt > Status: https://datatracker.ietf.org/doc/draft-wilde-linkset/ > Htmlized: = https://datatracker.ietf.org/doc/html/draft-wilde-linkset > Htmlized: https://tools.ietf.org/html/draft-wilde-linkset-07 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-wilde-linkset-07 >=20 > Abstract: > This specification defines two document formats and respective media > types for representing sets of links as stand-alone resources. One > format is JSON-based, the other aligned with the format for > representing links in the HTTP "Link" header field. This > specification also introduces a link relation type to support > discovery of sets of links. >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 >=20 > --=20 > erik wilde | mailto:erik.wilde@dret.net | > | http://dret.net/netdret | > | http://twitter.com/dret | >=20 > --=20 > httpapi mailing list > httpapi@ietf.org > https://www.ietf.org/mailman/listinfo/httpapi From ghobona@ogc.org Tue Oct 20 10:34:16 2020 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 34B893A0C99 for ; Tue, 20 Oct 2020 10:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ogc-org.20150623.gappssmtp.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 vBFs0jM7WylA for ; Tue, 20 Oct 2020 10:34:14 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 134153A0C96 for ; Tue, 20 Oct 2020 10:34:13 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id t9so3169298wrq.11 for ; Tue, 20 Oct 2020 10:34:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ogc-org.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:to; bh=ydp49qlkIkW3qoE0VR7q+F7VW2f4cgQVC5Wf6b8OgP0=; b=g5WnMyT4BFv2I/Ht/sR3N6/GA9vY+Y/UI9fwSXp2Oje/qzHREFbzBdH3B0s4vpPZUs sFrcwf5cEpIZTYV+gLKeBYVR5O5sMZpr8Ts28dvEm8fXmZlffDYP2+3zSQz623v7I+Wn rERJ1n/gkXXjDdJjafl0yWBF9p8SusdjTKGevz41t5bpwvE9b2AY6WOGgc/7dacKQDYX oAe2e+mAxDKmoq3zeTjXDP4qv2qK73/KIiVSwKDzK+D69NkIP2u0bvDZ6QZJAl1PloI+ VohLnoem335rKeJOEFKfWilRkcqnsPyZgdckbRtXxmAZalsPeq3KKB8YIwxG+7mrIHTp ElUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=ydp49qlkIkW3qoE0VR7q+F7VW2f4cgQVC5Wf6b8OgP0=; b=AlkOAe8Qbtc4FfBDZfRI8lXbAHmYUhEMnJO8IEuWxaYP7M0wBAmeG1lsPxghAwbtCX BPh39gSZy6KRMo3DXw9VncAwu9RZrQOweFCvqROgFeBme1UAKniodzDEBNSU7BmDZcL7 I15ZZEmqyng38Ngat2o7PZWwoP1DvjAXNuIzLnEVDPan9Z9Ic2vHtdkHz/Djr9xmKbuH 1btx4y07OLO9NlwLtiTDS0HhGJevjHdjZhWnM9howBJ92Z2yCPNvVCqtUcOXb9qEzqJ9 L6Bod9qy0VaOHxTAi2deXvzMrVDYCfOsxrDVBia8axovxhfwGoxyuYcXKNgdQLkhSM7J W+jg== X-Gm-Message-State: AOAM533au/6/QKVB9UMCkhhPK1X4s/06XxmD2EkGljBswpyLpSRioTRM VL2vNVEpP9+li2YLyrMYVRiCqqC0PLk265VHAYaoL9xR/pnYUSO2N5abPpkvpffkYgKMXAVwl/K Au2uxTdZjGfbAZjU71hqGPhkypHoGE+kumbUzHKDGgQ9vyVL7JYCRQ1asyJCd X-Google-Smtp-Source: ABdhPJzvycGtlfJsmvKKr8kg7ZaMM3QAtOje9S11xqIvznk/k4skkTKzlWLVnsYbc+K62ZV7wm5IQA== X-Received: by 2002:adf:a455:: with SMTP id e21mr5193100wra.158.1603215251830; Tue, 20 Oct 2020 10:34:11 -0700 (PDT) Received: from broadband.bt.com ([2a00:23a8:a:9800:a4fd:8ce7:509a:fa0]) by smtp.gmail.com with ESMTPSA id j13sm3959749wru.86.2020.10.20.10.34.11 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Oct 2020 10:34:11 -0700 (PDT) From: Gobe Hobona Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Message-Id: Date: Tue, 20 Oct 2020 18:34:10 +0100 To: httpapi@ietf.org X-Mailer: Apple Mail (2.3608.60.0.2.5) Content-Type: multipart/alternative; boundary="Apple-Mail=_FA66D034-4FC1-4127-A1D0-D662B2239727" Archived-At: Subject: [httpapi] OGC API standards - introduction 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: Tue, 20 Oct 2020 17:35:37 -0000 --Apple-Mail=_FA66D034-4FC1-4127-A1D0-D662B2239727 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" All, I have just joined the mailing list and would like to introduce myself. I work for the Open Geospatial Consortium (OGC) and am leading the developm= ent of the OGC API family of standards [https://ogcapi.ogc.org ]. OGC has been developing a new generation of standards for b= uilding web APIs that make location-referenced information more Findable, A= ccessible, Interoperable, and Reusable (FAIR). OGC API standards define mod= ular API building blocks to spatially enable Web APIs in a consistent way. = The OpenAPI specification is used to define the API building blocks.=20 The first of the standards to be approved is Part 1 of OGC API - Features [= http://docs.opengeospatial.org/is/17-069r3/17-069r3.html ]. The standard has also recently b= een approved by the International Organisation for Standardisation (ISO) un= der the name ISO 19168-1:2020 [https://www.iso.org/standard/32586.html ]. I look forward to participating in discussions on this forum to help align = the IETF and OGC working groups. If there are any questions relating to OGC APIs and location information, I= would be happy to answer or to act as a channel through to the OGC working= groups. Regards, Gobe __________________________________________________________________________ Dr. Gobe Hobona, PhD MRICS Director of Product Management, Standards | Open Geospatial Consortium (OGC= ) Tel: +44 744 409 6781 ghobona@ogc.org | ogc.org | @opengeospatial --=20 --Apple-Mail=_FA66D034-4FC1-4127-A1D0-D662B2239727 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="ISO-8859-1"
All,

I have just joined = the mailing list and would like to introduce myself.
<= br class=3D"">
I work for the Open Geospatial Consorti= um (OGC) and am leading the development of the OGC API family of standards = [https://ogcapi.ogc.org].= OGC has been developing a new generation of standards for building web API= s that make location-referenced information more Findable, Accessible, Inte= roperable, and Reusable (FAIR). OGC API standards define modular API buildi= ng blocks to spatially enable Web APIs in a consistent way. The OpenAPI spe= cification is used to define the API building blocks. 

The first of the standards to be= approved is Part 1 of OGC API - Features [http://docs.opengeospatial.= org/is/17-069r3/17-069r3.html]. The standard has also recently been app= roved by the International Organisation for Standardisation (ISO) under the= name ISO 19168-1:2020 [https://www.iso.org/standard/32586.html].

I look forward to participating = in discussions on this forum to help align the IETF and OGC working groups.=

If there are any= questions relating to OGC APIs and location information, I would be happy = to answer or to act as a channel through to the OGC working groups.

Regards,

Gobe
___= _______________________________________________________________________

Dr. Gobe Hobona, PhD MRICS
Director of Product Management, Standards | Open Geospatial Consortiu= m (OGC)
Tel: +44 744 409 6781
ghobona@og= c.org | ogc.org | @opengeospatial<= /div>


--Apple-Mail=_FA66D034-4FC1-4127-A1D0-D662B2239727-- From nobody Tue Oct 20 10:53:09 2020 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 233BC3A0D4B for ; Tue, 20 Oct 2020 10:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 6ex9yi6t0WOW for ; Tue, 20 Oct 2020 10:53:06 -0700 (PDT) Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (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 B4FD03A1222 for ; Tue, 20 Oct 2020 10:53:05 -0700 (PDT) Received: by mail-ej1-x62d.google.com with SMTP id c22so4058986ejx.0 for ; Tue, 20 Oct 2020 10:53:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; bh=vwpuJiw8dCX08mp/geJbOBatJk/HDxFcD6kZsvafgdk=; b=kL0aMlyZ0mxd1o9CGeh5/d7aWB1dJz8uQCKrbahKVcYV3JJZh+fVXjOkpL8mQLGXua MME7NkxjfXMLaVDodYnLe4QtaiNaezC//sBLnBYR7CDpUQ6byBpsBPbLJ0/WH26cCQJk DLhxjynyW6vcqWgIsEatNpvA58LOa11K59PLfKsB4tz6ZzdMUY8YO2l16AVngqzin3MI Uxkio8mIXfbDR1qp+H7JScYD6MbJqreidgLk2LXngEUEgO1uEVjsxz0q4woXWpm+QvuN JAqbbLAGvgdogtEipomCVLHyDUuOaGK6BHWJX3NUICTG+Al5aHIF/XbugAol1wVg/xnf jDUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:mime-version:subject :from:in-reply-to:date:cc:message-id:references:to; bh=vwpuJiw8dCX08mp/geJbOBatJk/HDxFcD6kZsvafgdk=; b=c0zfR2ibhBZQqwMqm4QIAkEHtHHqjYUofJgHMgKhPYidsE2q5yylvZb1g52WU52XkG UMhkqN2r4sNmdcdzbBPvkPvNZhNTij0WuQlaGwPhGjraIVsM3/2/2J57U+7aNyUmyfXw y5xHJiCC1XVy6UHVvMgynezv9Zj+0AlXbO5K6b2QH1GLPkWNbYm5mS/Xy1ZO4eWe9VS2 EBDtt2IxU/dOHzPz6YiXC7DOwCXPuq4z8cgv+L09mY+VoYpgIWCFVEXOYHSI/koZFF4V gG2bAbMlSNP1yupB1+FqINbp8MB/agcEeKxJDQTdyTXsUPHdWA6tvXgwCBhL/9K8kOIW LxjA== X-Gm-Message-State: AOAM532F9HIUhjZrm2sq1zeNbIxkYcoOII7s8Ps5W+XZq2LdD3ZTEb9b gJz0nKmjCt8/5CBAEVA6nOM= X-Google-Smtp-Source: ABdhPJyWCzsIg6CLD20jQpjjqTgHKR2iWCCWrB80bVJFw0l7qgfgRR75CP/tlR+yqUPF1SRaL0E2mA== X-Received: by 2002:a17:906:1e08:: with SMTP id g8mr406758ejj.358.1603216384217; Tue, 20 Oct 2020 10:53:04 -0700 (PDT) Received: from [192.168.178.25] (83-84-20-152.cable.dynamic.v4.ziggo.nl. [83.84.20.152]) by smtp.gmail.com with ESMTPSA id l9sm3238298edn.75.2020.10.20.10.53.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Oct 2020 10:53:03 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-9BE0BB38-8E2A-4D10-978E-23CB4BB2A6B2 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) From: Herbert Van de Sompel In-Reply-To: <07D8E404-53F0-4603-A6A4-A5F0BB54A32C@bzfx.net> Date: Tue, 20 Oct 2020 19:53:01 +0200 Cc: Erik Wilde , HTTP APIs Working Group , Dominique Guinard , Phil Archer Message-Id: <1D1FDF24-ED36-4BC9-9BB1-57FECBFA1DE5@gmail.com> References: <07D8E404-53F0-4603-A6A4-A5F0BB54A32C@bzfx.net> To: Austin Wright X-Mailer: iPad Mail (18A393) Archived-At: Subject: Re: [httpapi] New Version Notification for draft-wilde-linkset-07.txt 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: Tue, 20 Oct 2020 17:53:08 -0000 --Apple-Mail-9BE0BB38-8E2A-4D10-978E-23CB4BB2A6B2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Oct 20, 2020, at 19:09, Austin Wright wrote: >=20 > =EF=BB=BFQuick question: How is the application/linkset media type differe= nt from the application/link-format media type in RFC 6690? >=20 I have some experience with this issue because I ran into it when doing Meme= nto RFC7089. For that RFC, we needed a media type that exactly aligned with t= he format of the content of the HTTP Link header. At first glance, it looked= like application/link-format was going to be it. However, it turns out that= the media type actually imposes a few extras on top of the format of the c= ontent of the HTTP Link header that are specific to the CoRE perspective, eg= this snippet from RFC6690: The CoRE Link Format is equivalent to the [RFC5988] link format; however, the ABNF in the present specification is repeated with improvements to be compliant with [RFC5234] and includes new link parameters. The link parameter "href" is reserved for use as a query parameter for filtering in this specification (see Section 4.1) and MUST NOT be defined as a link parameter. I remember some interactions with the CoRE people aimed at removing those ex= tras from the media type definition but that went nowhere. Because Memento=E2= =80=99s core focus was the introduction of datetime negotiation, we decided n= ot to bother with registering a media type that didn=E2=80=99t have this CoR= E perspective. We just went with application/link-format, and, in our RFC, c= onveyed our own perspective. In hindsight, that probably wasn=E2=80=99t very= cool but, at that time, it really wasn=E2=80=99t our core concern. Meanwhil= e, application/link-format is used as a MIME type for TimeMaps in all Mement= o compliant applications, which basically includes all public web archives.=20= With the Linkset RFC we do want a media type that exactly aligns with the de= finition of the format for the content of the Link header, ie without the Co= RE extras. That will, btw, also become valuable for Memento because it will a= llow getting rid of its own perspective on the application/link-format media= type ... > Would it make sense to cite this as prior art? >=20 In the sense of clarifying the distinction? That's an idea, indeed. Greetings Herbert > Thanks, >=20 > Austin. >=20 >> On Oct 20, 2020, at 00:47, Erik Wilde wrote: >>=20 >> hello! >>=20 >> it's great to see this new working group picking up steam! >>=20 >> attached please find a draft that we have been working on for quite a whi= le, and which is we believe in a stage that warrants publication as an RFC. >>=20 >> we've been told that this new working group would be a good fit, and that= 's definitely the case. but we also want to make sure to progress with this a= s quickly as possible, as we have some major implementation work (first and f= oremost the GS1 work listed in the draft) depending on that. >>=20 >> it would be great to move forward with this as soon as possible. please l= et us know what the next steps are to make this happen. >>=20 >> thanks a lot and cheers, >>=20 >> dret. >>=20 >>=20 >> -------- Forwarded Message -------- >> Subject: New Version Notification for draft-wilde-linkset-07.txt >> Date: Fri, 16 Oct 2020 08:03:10 -0700 >> From: internet-drafts@ietf.org >> To: Erik Wilde , Herbert Van de Sompel >>=20 >>=20 >> A new version of I-D, draft-wilde-linkset-07.txt >> has been successfully submitted by Erik Wilde and posted to the >> IETF repository. >>=20 >> Name: draft-wilde-linkset >> Revision: 07 >> Title: Linkset: Media Types and a Link Relation Type for Link Sets= >> Document date: 2020-10-16 >> Group: Individual Submission >> Pages: 29 >> URL: https://www.ietf.org/archive/id/draft-wilde-linkset-07.tx= t >> Status: https://datatracker.ietf.org/doc/draft-wilde-linkset/ >> Htmlized: https://datatracker.ietf.org/doc/html/draft-wilde-linkset= >> Htmlized: https://tools.ietf.org/html/draft-wilde-linkset-07 >> Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-wilde-linkset-0= 7 >>=20 >> Abstract: >> This specification defines two document formats and respective media >> types for representing sets of links as stand-alone resources. One >> format is JSON-based, the other aligned with the format for >> representing links in the HTTP "Link" header field. This >> specification also introduces a link relation type to support >> discovery of sets of links. >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of submiss= ion >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >>=20 >>=20 >> --=20 >> erik wilde | mailto:erik.wilde@dret.net | >> | http://dret.net/netdret | >> | http://twitter.com/dret | >>=20 >> --=20 >> httpapi mailing list >> httpapi@ietf.org >> https://www.ietf.org/mailman/listinfo/httpapi >=20 --Apple-Mail-9BE0BB38-8E2A-4D10-978E-23CB4BB2A6B2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Oct 20, 2020, at 19:09,= Austin Wright <aaa@bzfx.net> wrote:

=EF=BB=BFQuick question: How is the application/linkset media typ= e different from the application/link-format media type in RFC 6690?<= br>

I have some exper= ience with this issue because I ran into it when doing Memento RFC7089. For t= hat RFC, we needed a media type that exactly aligned with the format of the c= ontent of the HTTP Link header. At first glance, it looked like application/= link-format was going to be it. However, it turns out that the media type ac= tually imposes a few extras on top of the  format of the content of the= HTTP Link header that are specific to the CoRE perspective, eg this snippet= from RFC6690:

The CoRE Link Format is equivalent=
 to the [RFC5988] link format;
   however, the ABNF in the present specification is repeated with
   improvements to be compliant with [Section 4.1) and
   MUST NOT be defined as a link parameter.

I= remember some interactions with the CoRE people aimed at removing those ext= ras from the media type definition but that went nowhere. Because Memento=E2= =80=99s core focus was the introduction of datetime negotiation, we decided n= ot to bother with registering a media type that didn=E2=80=99t have this CoR= E perspective. We just went with application/link-format, and, in our RFC, c= onveyed our own perspective. In hindsight, that probably wasn=E2=80=99t very= cool but, at that time, it really wasn=E2=80=99t our core concern. Meanwhil= e, application/link-format is used as a MIME type for TimeMaps in all Mement= o compliant applications, which basically includes all public web archives.&= nbsp;

With the Linkset RFC we do want a media type t= hat exactly aligns with the definition of the format for the content of the L= ink header, ie without the CoRE extras. That will, btw, also become valuable= for Memento because it will allow getting rid of its own perspective on the=  application/link-format media type  ...

Would it make sense to cite this= as prior art?


=
In the sense of clarifying the distinction? That's an idea, indeed.

Greetings

Herbert
<= /div>
Thanks,
=
Austin.

On Oct 20, 2020, at 00:47, Erik Wilde <erik.wilde@dret.net&g= t; wrote:

=
hello!
<= blockquote type=3D"cite">
it's great to see this new working group picking up steam!=

attached please find a draft that we have been w= orking on for quite a while, and which is we believe in a stage that warrant= s publication as an RFC.

we've been told t= hat this new working group would be a good fit, and that's definitely the ca= se. but we also want to make sure to progress with this as quickly as possib= le, as we have some major implementation work (first and foremost the GS1 wo= rk listed in the draft) depending on that.

it would be great to move forward with this as soon as possible. please le= t us know what the next steps are to make this happen.

thanks a lot and cheers,

dre= t.


-------- Forwarded Message --------
Subject: New Version Notification for draft= -wilde-linkset-07.txt
Date: Fri, 16 Oct 2020 08:03:10 -0700
From: internet-drafts@ietf.org
To: Erik Wilde <erik.wilde@dret.net>, Herb= ert Van de Sompel <herbert.van.de.sompel@dans.knaw.nl>


A= new version of I-D, draft-wilde-linkset-07.txt
has been successfully submitted by Erik Wilde and= posted to the
IETF r= epository.
Name:       &nb= sp;draft-wilde-linkset
Revision:    07
Title:        Linkset: Media Types and a Link Rel= ation Type for Link Sets
Document date:    2020-10-16
Group:        Individual Submissio= n
Pages:    = ;    29
URL= :            https://= www.ietf.org/archive/id/draft-wilde-linkset-07.txt
Status:       &n= bsp; https://datatracker.ietf.org/doc/draft-wilde-linkset/
Htmlized:     = ;  https://datatracker.ietf.org/doc/html/draft-wilde-linkset
Htmlized:   &nbs= p;   https://tools.ietf.org/html/draft-wilde-linkset-07
Diff:    &n= bsp;      https://www.ietf.org/rfcdiff?url2=3D= draft-wilde-linkset-07

Abstract:
 This specification def= ines two document formats and respective media
 types for representing sets of links as sta= nd-alone resources.  One
 format is JSON-based, the other aligned with the format for<= /span>
 representing l= inks in the HTTP "Link" header field.  This
 specification also introduces a link rela= tion type to support
=  discovery of sets of links.

=

Please note that it may take a couple of minute= s from the time of submission
until the htmlized version and diff are available at tools.ietf.org= .

The IETF Secretariat



--
erik wilde | mailto:erik.wilde@dret.net |=
   &= nbsp;     | http://dret.net/netdret   &nb= sp;|
  &nb= sp;      | http://twitter.com/dret   = ; |

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

= --Apple-Mail-9BE0BB38-8E2A-4D10-978E-23CB4BB2A6B2-- From nobody Wed Oct 21 14:58:13 2020 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 4C43C3A0A6C for ; Wed, 21 Oct 2020 14:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 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, SHORTENED_URL_HREF=0.999, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 uVYyiTPnUevy for ; Wed, 21 Oct 2020 14:58:08 -0700 (PDT) Received: from mail-io1-xd44.google.com (mail-io1-xd44.google.com [IPv6:2607:f8b0:4864:20::d44]) (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 ECFBB3A0A3D for ; Wed, 21 Oct 2020 14:58:07 -0700 (PDT) Received: by mail-io1-xd44.google.com with SMTP id y20so4819661iod.5 for ; Wed, 21 Oct 2020 14:58:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=u/uhCH6lsN96UrShMG6u1WMeB+i7ETEN6bb2OFPc54E=; b=oF1a411+udjaGXvpwQUapZQEXHxFbRaNi5EB8eDeEwm1MErrADN8tpqPwu2++VTbwm i8V+Yxs3OL2sINOIi3CkHaDGYGCA3OhitnVH0JE7dU3wjIAnvTiMJESIjmNhyI+FApdA T5z6vzKk0UbxTTQaATy8fd94rWum3FMVtn4TaK3v0mQOlSt6/5VXJCUk3KD5JmBxZVGC 95EfaOf5255IPcmiwLGGXNSIdBVwgbomfXCwpsLRZJrJ2Q54KIL7q+NRRQJkBXOhLCBU jm0Of4RTPHU0vAPwD6VO6PzFqaG8JDvp5bFc7oD6NoWJmxE3J4SCKmkmJvxPXCSqlhq6 KP2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=u/uhCH6lsN96UrShMG6u1WMeB+i7ETEN6bb2OFPc54E=; b=FL2VyZk65RxBa2erzmRu4u5Wcw1uXre1Z7UzKzya1bmfiPnW5/j3UuWajTHlzjRPSn FF7yZj7DvRcRGhhxXB5axIaAbkKOgOcu3uxelg0cPKFaeCgpV54nMcqu3bYEPTwEbrM+ L5+ym/diUEnwiSu1iMM2yhn6dPfkdMlvEwCHtq6DpooWnReRceDxZJKwc6fbhjbDR/zD 0lDqd+y3uE9TiwvEBPXy389BxKfU9XcZUWooR5O4RsCeACacgf8XU5vnlrMIOwK8AdDF KzbmBLmmuS+wmcWHAutmKQ3vaXsw061svX+4SFcTxhgp63QNoqDBGRE7M2NTQlLlirOm rcHA== X-Gm-Message-State: AOAM530Zkq33qqGtl5e17YNpJLuwSTW3mR1OiL1bLkXtXNY0PRM8Rt6K UN+GFkzGsF21w8plJMG9d+OIoEChW2cPBCnZkBHYJ+bRF+LJWw== X-Google-Smtp-Source: ABdhPJx/lF8L0AfrnNsWA9KSbObemFFUi1b5dSig5eZ5XPW9MiDIgf9hPTXdVdxwALcJh2SzwTxYEy9cfo7ioQmQNdo= X-Received: by 2002:a5d:83cc:: with SMTP id u12mr4284999ior.171.1603317486821; Wed, 21 Oct 2020 14:58:06 -0700 (PDT) MIME-Version: 1.0 From: Roberto Polli Date: Wed, 21 Oct 2020 23:57:56 +0200 Message-ID: To: httpapi@ietf.org Cc: Alex Martinez , f.terpstra@geonovum.nl Content-Type: multipart/alternative; boundary="00000000000043a54b05b2357169" Archived-At: Subject: [httpapi] Standardizing RateLimit headers 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: Wed, 21 Oct 2020 21:58:10 -0000 --00000000000043a54b05b2357169 Content-Type: text/plain; charset="UTF-8" Hi @all, I'm glad that this workgroup started working, and this is my first contribution. In the past months, me and Alex (in CC) worked on this I-D to standardize `RateLimit-*` headers. The document defines the RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset header fields for HTTP, thus allowing servers to publish current request quotas and clients to shape their request policy avoiding being throttled out. The draft is here: - https://tinyurl.com/draft-ratelimit-html And here some slides: - https://docs.google.com/presentation/d/18RWq_XYfKHf2E5TTCAc5xx9rgdIZgrN0tfB0jmVlnSM/edit#slide=id.p This draft has been implemented by: - Red Hat 3scale - Kong - Armeria Java API framework - express-rate-limit - Envoy proxy (almost done) Other implementers (Eg. Traefik) are interested in the I-D but are waiting for an official RFC before investing in the implementation, so it would be great to discuss that in the workgroup. Have a nice day, R. --00000000000043a54b05b2357169 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi @all,

I'm glad that this workgroup started w= orking, and this is my first contribution.

In the past months, me an= d Alex (in CC) worked on this I-D to standardize `RateLimit-*` headers.
=
The document defines the RateLimit-Limit, RateLimit-Remaining,
RateL= imit-Reset header fields for HTTP, thus allowing servers to
publish curr= ent request quotas and clients to shape their request
policy avoiding be= ing throttled out.

The draft is here:

- =C2=A0https://tinyurl.com/draft-ratelimit-h= tml=C2=A0

And here some slides:

=
-=C2=A0https://docs.google.com/= presentation/d/18RWq_XYfKHf2E5TTCAc5xx9rgdIZgrN0tfB0jmVlnSM/edit#slide=3Did= .p

This draft has been implemented by:
- Red Hat 3scale
- = Kong
- Armeria Java API framework
- express-rate-limit
- Envoy pro= xy (almost done)

Other implementers (Eg. Traefik) are interested in = the I-D but are waiting for an official RFC before investing in the impleme= ntation,
so it would be great to discuss that in the workgroup.

Have a nice day,
R.

--00000000000043a54b05b2357169-- From amartine@redhat.com Thu Oct 22 01:24:28 2020 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 3E7123A0EE6 for ; Thu, 22 Oct 2020 01:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.597 X-Spam-Level: X-Spam-Status: No, score=-1.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.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 SwjyaY72yfS7 for ; Thu, 22 Oct 2020 01:24:26 -0700 (PDT) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A81CC3A0ED5 for ; Thu, 22 Oct 2020 01:24:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1603355065; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=jBKkuIZUNR4hkNSGtHii4rQqrRyICTkfwyuryyquQ2I=; b=PKwgd6w7T8uYWVi9pMn54jSsEpTjctL1yRb+antv0p87XPRByW5BruvPEssm0iY1m244J8 XNVtjkOVaMVPYoCSww2eKUN+U5OA9Brs3KSpZRXpRmxd/Q/QxqaAQwMBPpztdjDF8yDYjJ vFLcgH9X7tzbZrMWk4lUzyzhVHsBkqQ= Received: from mail-yb1-f200.google.com (mail-yb1-f200.google.com [209.85.219.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-381-FUzoxSzSOYKdEtVnA1KyTQ-1; Thu, 22 Oct 2020 04:24:22 -0400 X-MC-Unique: FUzoxSzSOYKdEtVnA1KyTQ-1 Received: by mail-yb1-f200.google.com with SMTP id a12so995594ybc.20 for ; Thu, 22 Oct 2020 01:24:22 -0700 (PDT) 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=jBKkuIZUNR4hkNSGtHii4rQqrRyICTkfwyuryyquQ2I=; b=hksD6x48x77GzATI+YnwqpDLF/9dBloQqAjT2V/WHLazHsQU87thWwCbZ6vOnw5NQL 1goJvWyKpGEN1DNLbIb6hoKiqGY/vR+GJkAEH+rP72zgyrv9/SMAIHKyAi8ORskaxMiv +w+fEwlxlJ9ZZfwh2oqNaXREczioqyjM9aReLD8FM4EmGqCrIOh6RGFhnluL3sLMqMhC IJmmFctx/p5Mrt339I2Ng9SV7/9mQIry9xip3+SrHHj/B/AGNhHb3VHYPi+Vvmr0S3++ yGzs01UBNmm1iIMy6hmXMldJDvMtrcgM5Vy3F94HG/gwxh/QRmVJVAhqQ3o3IvjtARjf 2Z+A== X-Gm-Message-State: AOAM5310qDnVtKuhNw/UjlugsuCbn82xublSzXHUwQneNDguRIxllA0w 45/JYyxOe5jThfGbzWamp3q+SM+26/hnfz6I8CU8c6kUvpXhJBDXlbzHe14h6Tf2eKM/J2Gb/oJ EwYcHi/SG/wJj0wQFdz6p8WE2 X-Received: by 2002:a25:75c5:: with SMTP id q188mr1644179ybc.292.1603355061501; Thu, 22 Oct 2020 01:24:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJye1/1L/5UXiiVbZRak8eGBQDOLJFKPhYaLPT4DKobauj5//BzJUg1Incsr+urOfA+jBjvyiUDldEUkOleb/78= X-Received: by 2002:a25:75c5:: with SMTP id q188mr1644162ybc.292.1603355061296; Thu, 22 Oct 2020 01:24:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alex Martinez Date: Thu, 22 Oct 2020 08:24:10 +0000 Message-ID: To: =?UTF-8?B?QW5kcsOpIENlZGlr?= Cc: Roberto Polli , httpapi@ietf.org, f.terpstra@geonovum.nl Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=amartine@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="000000000000e0b11e05b23e30a1" Archived-At: Subject: Re: [httpapi] Standardizing RateLimit headers 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: Thu, 22 Oct 2020 08:53:24 -0000 --000000000000e0b11e05b23e30a1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Andr=C3=A9, On Thu, Oct 22, 2020 at 8:10 AM Andr=C3=A9 Cedik wrote: > One additional thing we are doing is we are returning a fourth header > called RateLimit-Interval that returns the standard time-window. > > So when you get the basic response for a single request e.g. > > RateLimit-Limit: 100 > RateLimit-Remaining: 99 > RateLimit-Reset: 59 > > a client wouldn't know that actually, a second has passed between the > request and setting the header field. > > By returning the RateLimit-Interval field the client is able to adjust > their request window which is something that you are already providing fo= r > other request limit windows by making it possible to add them in the > RateLimit-Limit header. I don't know if having a fourth header is the bes= t > way to do this, since you could also provide this information by adjustin= g > the basic value of the RateLimit-Limit header like this: > > RateLimit-Limit: 100;w=3D60 > > > Is this possible? > I think what you are looking for is covered in Section 3.1 of the draft under the associated time-window for RateLimit-Limit, so no additional header is needed. If not, it would be great to share more details about your use case. Cheers, Alex --000000000000e0b11e05b23e30a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Andr=C3=A9,

On Th= u, Oct 22, 2020 at 8:10 AM Andr=C3=A9 Cedik <andre.cedik@googlemail.com> wrote:
One additiona= l thing we are doing is we are returning a fourth header called RateLimit-I= nterval that returns the standard time-window.=C2=A0

So when you ge= t the basic response for a single request e.g.
Rate= Limit-Limit: 100
RateLimit-Remaining: 99
RateLimit-Reset: 59
a client woul= dn't know that actually, a second has passed between the request and se= tting the header field.=C2=A0

By returning the= =C2=A0RateLimit-Interval field the client is able to adjust their request w= indow which is something that you are already providing for other request l= imit windows by making it possible to add them in the RateLimit-Limit heade= r. I don't know if having a fourth header is the best way to do this, s= ince you could also provide this information by adjusting the basic value o= f the RateLimit-Limit header like this:
RateLimit-Limit: = 100;w=3D60

Is this possible?= =C2=A0

I think what you are loo= king for is covered in Section 3.1 of the draft under the associated time-w= indow for RateLimit-Limit, so no additional header is needed. If not, it wo= uld be great to share more details about your use case.

Cheers,
=C2=A0 Alex
--000000000000e0b11e05b23e30a1-- From nobody Thu Oct 22 02:53:33 2020 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 AAC433A07E6 for ; Thu, 22 Oct 2020 02:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.597 X-Spam-Level: X-Spam-Status: No, score=-1.597 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, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 uGEBB2oGFwtL for ; Thu, 22 Oct 2020 02:53:30 -0700 (PDT) Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 4717A3A03F2 for ; Thu, 22 Oct 2020 02:53:30 -0700 (PDT) Received: by mail-il1-x134.google.com with SMTP id p9so1142306ilr.1 for ; Thu, 22 Oct 2020 02:53:30 -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=NjEbnw8jSdxVCPFy3/0beq+bOKCffLdrDLhn0GgdG+4=; b=cDqBEOtnOBpcM8iSxA9xE2rchLYrWYi3NHPpn+sqGKIA5lC+2I5+h9gkCsRyrBcZ24 qZ03xhF635InX5x2XZ89GwEUVjfvDjqN7ch8sORsrtAkjY6EO7FVug6X5u144s/qliq9 GDSnzI1wt81XBIpS5gedyVHYUItK6EhNRs1TRoSD4S25kfOYo+sCxFEFKbfQGbxKSra6 odsBGA213EIsK9Zc7HNqGJp9kjMlYWh3Y/cqdutUMY2NEr9x5QGjSoUhTELXG7HISS74 u/31jbpN2vuRBRsI8YsdhzWU0LBhm6d9lez95PZNM5PQtg15DDksv/UAQuRoKVZx82Q9 t2wg== 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=NjEbnw8jSdxVCPFy3/0beq+bOKCffLdrDLhn0GgdG+4=; b=nrSef+llDAYT446b4FjzscDzcuNWmSlIYgFdUbswZ/p1SLueg1TyawNtDsnMh7V3uc NpU4ZQO6ev+xUUs91jzss/xIGCEOOU1WVCPmMTNTpxVi6UQWjKviE7siDjegCx6ni/bl mAd7lC1JopzQeo95c6m5AqVTV6ZeCJd+I8n2CcKiJ7eiIYmtHtTray6rVPQ0r/GzZXt1 REhY/BdqwG7f7TsAcNfBUwEp8ub/7hA1eRZ2zU4Bdr2Tn67vkZpF5gFfDZbuRrMl2sWQ 1qfc0EA/TivBDql3H4NprR3qZ6AW6Qljc4APr6FYBTqc259j85SdPD3TdQyhRIykIIJZ M8UQ== X-Gm-Message-State: AOAM530yQ2LDK7Mnw17hCbWN4yrds6F1wNVI/Yi69193zxWfJzWwpiRY wA01GqN8vR445jyG9rpEpdsn9d9T1svZWzaWkvI= X-Google-Smtp-Source: ABdhPJwqxFR94B8q7ggRiEVfzFkBfqnTKVfXnAbVmRRyAMFnF1czAVgF+/apVBXcu11g/kMaKa+xn2Ml9Lhtez5tRh0= X-Received: by 2002:a92:9f42:: with SMTP id u63mr1244999ili.146.1603360409452; Thu, 22 Oct 2020 02:53:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Roberto Polli Date: Thu, 22 Oct 2020 11:53:18 +0200 Message-ID: To: Alex Martinez Cc: =?UTF-8?B?QW5kcsOpIENlZGlr?= , httpapi@ietf.org, f.terpstra@geonovum.nl Content-Type: multipart/alternative; boundary="000000000000a7067f05b23f6f9c" Archived-At: Subject: Re: [httpapi] Standardizing RateLimit headers 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: Thu, 22 Oct 2020 09:53:32 -0000 --000000000000a7067f05b23f6f9c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Andr=C3=A9, Il giorno gio 22 ott 2020 alle ore 10:24 Alex Martinez ha scritto: >> >> One additional thing we are doing is we are returning a fourth header called RateLimit-Interval that returns the standard time-window. >> [..] you could also provide this information by adjusting the basic value of the RateLimit-Limit header like this: >> >> RateLimit-Limit: 100;w=3D60 >> >> Is this possible? > > I think what you are looking for is covered in Section 3.1 > If not, it would be great to share more details about your use case. just for completeness, from Section 3.1 https://ioggstream.github.io/draft-polli-ratelimit-headers/draft-polli-rate= limit-headers.html#name-ratelimit-limit ``` A time-window associated to expiring-limit can be communicated via an optional quota-policy value, like shown in the following example RateLimit-Limit: 100, 100;w=3D10 ``` This allows "lazy/old" parsers to be able to process the first item as an integer, and ignore everything after the comma. Let us know, R: --000000000000a7067f05b23f6f9c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Andr=C3=A9,



Il giorno gio 22 ott 2020 al= le ore 10:24 Alex Martinez <amr@redhat= .com> ha scritto:
>>
>> One additional thing we ar= e doing is we are returning a fourth header called RateLimit-Interval that = returns the standard time-window.
>> [..] you could also provide = this information by adjusting the basic value of the RateLimit-Limit header= like this:
>>
>> RateLimit-Limit: 100;w=3D60
>>=
>> Is this possible?
>
> I think what you are lookin= g for is covered in Section 3.1
> If not, it would be great to share = more details about your use case.
just for completeness, from Secti= on 3.1=C2=A0https://iog= gstream.github.io/draft-polli-ratelimit-headers/draft-polli-ratelimit-heade= rs.html#name-ratelimit-limit

```
=C2=A0A time-win= dow associated to expiring-limit can be communicated via an optional quota-= policy value, like shown in the following example

=C2=A0 =C2=A0RateL= imit-Limit: 100, 100;w=3D10
```

This allows "lazy/old= " parsers to be able to process the first item as an integer, and igno= re everything after the comma.

Let us know,= =C2=A0
R:
--000000000000a7067f05b23f6f9c-- From nobody Thu Oct 22 06:24:59 2020 Return-Path: X-Original-To: httpapi@ietf.org Delivered-To: httpapi@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 943993A0983; Thu, 22 Oct 2020 06:24:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: httpapi-chairs@ietf.org, httpapi@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <160337309807.8053.17339408012219488959@ietfa.amsl.com> Date: Thu, 22 Oct 2020 06:24:58 -0700 Archived-At: Subject: [httpapi] Alissa Cooper's Block on charter-ietf-httpapi-00-02: (with BLOCK) X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 13:24:59 -0000 Alissa Cooper has entered the following ballot position for charter-ietf-httpapi-00-02: Block When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-httpapi/ ---------------------------------------------------------------------- BLOCK: ---------------------------------------------------------------------- "New work items can be added after a Call for Adoption on the working group mailing list and consultation with the Area Director." Without more context, this is trivially true of all working groups. I think this is the bit that is trying to justify approving a charter without milestones, right? After the group has been around awhile that context will be lost and it will be immaterial anyway, I think, that the charter was approved without milestones. I would suggest dropping this and re-ordering things a bit: "To be successful, this Working Group will need to have active and broad representation from across the industry -- e.g., API gateway vendors (and other intermediaries), API consultants, API tool vendors, in-house API teams. Therefore, adopted proposals should have public support from multiple implementers and/or deployments before being sent to the IESG. To assess whether the group is functioning well, this charter will be reviewed by the IESG nine months after chartering." From nobody Thu Oct 22 06:51:26 2020 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 501263A0BEC; Thu, 22 Oct 2020 06:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 xrbxpML0MDn1; Thu, 22 Oct 2020 06:51:23 -0700 (PDT) Received: from mail-vs1-f41.google.com (mail-vs1-f41.google.com [209.85.217.41]) (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 ED6873A0BFF; Thu, 22 Oct 2020 06:51:19 -0700 (PDT) Received: by mail-vs1-f41.google.com with SMTP id n18so911042vsl.2; Thu, 22 Oct 2020 06:51:19 -0700 (PDT) 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=aW7rj6P16dJwUUZSBnXLi7oqYfk1FBW+y5hkyFLndbw=; b=iY8jVbN1WkyT2GsvVXRwoQ5eJVtX6G5RbVZs+YDIo//wAidaUv/y9UY8sWSz28/G9H ryXI60MWbN2yNcVLwXRmmuJq56+xpjXoG3sanKZ8hIzfj3mjqrizoe+cOvNeV320xEoj /IpFad5xhFke0KxTOPcdyXY3cKY388QWjtnGO8deblCYfyMpClPfp6uc+QUpVQAmFXsH 4jHmlEiZtnCkqqooWDjtqnEBsnAmdDi2dgUJk7sXn5GomWnDtd8avuqlT5za0lrG0V6y lIckh9avJtDMIodih8+04EqvmG9lsPslB989q4KShpCfoC//6AsjtxKyWvIJCsmZH4a1 uWRQ== X-Gm-Message-State: AOAM5303eTHdSMJNaeHLu0xyZ3hiGIRtwC1mi3nDTOcLgUCEKPhQCxtL vaHOJIqAUkGaxwsbSGCDkT4jgou84kzApo/IwtKNeZlSnWw= X-Google-Smtp-Source: ABdhPJz6lPL6AZ6R9WCxQMS+BBG9h+M/MDI79KxetTi/5RWf793zUb9hVC3myaoCdf57yl8uQCdpAxEox5n3zTzKtno= X-Received: by 2002:a67:e988:: with SMTP id b8mr1746191vso.9.1603374678755; Thu, 22 Oct 2020 06:51:18 -0700 (PDT) MIME-Version: 1.0 References: <160337309807.8053.17339408012219488959@ietfa.amsl.com> In-Reply-To: <160337309807.8053.17339408012219488959@ietfa.amsl.com> From: Barry Leiba Date: Thu, 22 Oct 2020 09:51:07 -0400 Message-ID: To: Alissa Cooper Cc: The IESG , httpapi@ietf.org, httpapi-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [httpapi] Alissa Cooper's Block on charter-ietf-httpapi-00-02: (with BLOCK) 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: Thu, 22 Oct 2020 13:51:24 -0000 Done in -00-03. I'm surprised that this didn't come up before External Review, rather than after. Barry On Thu, Oct 22, 2020 at 9:25 AM Alissa Cooper via Datatracker wrote: > > Alissa Cooper has entered the following ballot position for > charter-ietf-httpapi-00-02: Block > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-httpapi/ > > > > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- > > "New work items can be added after a Call for Adoption on the working group > mailing list and consultation with the Area Director." > > Without more context, this is trivially true of all working groups. I think > this is the bit that is trying to justify approving a charter without > milestones, right? After the group has been around awhile that context will be > lost and it will be immaterial anyway, I think, that the charter was approved > without milestones. I would suggest dropping this and re-ordering things a bit: > > "To be successful, this Working Group will need to have active and broad > representation from across the industry -- e.g., API gateway vendors (and other > intermediaries), API consultants, API tool vendors, in-house API teams. > Therefore, adopted proposals should have public support from multiple > implementers and/or deployments before being sent to the IESG. > > To assess whether the group is functioning well, this charter will be reviewed > by the IESG nine months after chartering." > > > > > From nobody Thu Oct 22 07:44:59 2020 Return-Path: X-Original-To: httpapi@ietf.org Delivered-To: httpapi@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2630B3A101C; Thu, 22 Oct 2020 07:44:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: httpapi-chairs@ietf.org, httpapi@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <160337789106.9706.2101316281936020641@ietfa.amsl.com> Date: Thu, 22 Oct 2020 07:44:51 -0700 Archived-At: Subject: [httpapi] Alissa Cooper's No Objection on charter-ietf-httpapi-00-04: (with COMMENT) X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 14:44:54 -0000 Alissa Cooper has entered the following ballot position for charter-ietf-httpapi-00-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-httpapi/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my comment. From nobody Fri Oct 23 10:20:23 2020 Return-Path: X-Original-To: httpapi@ietf.org Delivered-To: httpapi@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 536573A104B; Fri, 23 Oct 2020 10:20:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Cc: httpapi-chairs@ietf.org, httpapi@ietf.org, The IESG MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID: <160347361732.20064.8971595941101788063@ietfa.amsl.com> Date: Fri, 23 Oct 2020 10:20:17 -0700 Archived-At: Subject: [httpapi] WG Action: Formed Building Blocks for HTTP APIs (httpapi) X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 17:20:17 -0000 A new IETF WG has been formed in the Applications and Real-Time Area. For additional information, please contact the Area Directors or the WG Chairs. Building Blocks for HTTP APIs (httpapi) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: Darrel Miller Rich Salz Assigned Area Director: Barry Leiba Applications and Real-Time Area Directors: Barry Leiba Murray Kucherawy Mailing list: Address: httpapi@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/httpapi Archive: https://mailarchive.ietf.org/arch/browse/httpapi/ Group page: https://datatracker.ietf.org/group/httpapi/ Charter: https://datatracker.ietf.org/doc/charter-ietf-httpapi/ In addition to its use for web browsing, HTTP is often used for machine-to-machine communication, facilitated by HTTP APIs. This Working Group will standardise HTTP protocol extensions for use in such cases, with a focus on building blocks for separate or combined use. Its output can include the following: • Specifications for HTTP extensions that relate to HTTP APIs (typically, new HTTP header and/or trailer fields) • Specifications for new message body formats, or conventions for their use in HTTP APIs (e.g., patterns of JSON objects) • Best practices and other documentation for HTTP API designers, consumers, implementers, operators, etc. Other items are out of scope. In particular, this WG will not take on work items for HTTP APIs for specific applications or services, and it will not define new HTTP extension points. APIs for HTTP itself (e.g., in clients and servers) are also out of scope. To be successful, this Working Group will need to have active and broad representation from across the industry -- e.g., API gateway vendors (and other intermediaries), API consultants, API tool vendors, in-house API teams. Therefore, adopted proposals should have public support from multiple implementers and/or deployments before being sent to the IESG. To assess whether the group is functioning well, this charter will be reviewed by the IESG nine months after chartering. This Working Group will also need to coordinate closely with the HTTP Working Group, in particular when new methods and status codes are proposed. Work items that are more broadly applicable (e.g., for implementation in Web browsers) are likely to be more appropriate in the HTTP Working Group, but it is expected that coordination and discussion between the groups' Chairs and Area Director(s) will guide work items to the appropriate venue. From nobody Fri Oct 23 11:04:50 2020 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 BB2E53A0982; Fri, 23 Oct 2020 11:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 NvlmcVkJeN4T; Fri, 23 Oct 2020 11:04:46 -0700 (PDT) Received: from mail-ua1-f43.google.com (mail-ua1-f43.google.com [209.85.222.43]) (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 2FC603A097F; Fri, 23 Oct 2020 11:04:46 -0700 (PDT) Received: by mail-ua1-f43.google.com with SMTP id q20so660278uar.7; Fri, 23 Oct 2020 11:04:46 -0700 (PDT) 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:content-transfer-encoding; bh=qZzBPmNRBNrLMrKi2m1CLIytA7guPe6xqDK3ufgkIrU=; b=PN8J7zp+AFG+mLRnJMONiuRAWMwRqTteMc6LpMNb4BljycUStCLiwqUhka0CHyd9dQ pDtEm+FGa3AETeI89leUZG6dYSBLQcPpqpjZP+WQIh7p3O4VcGbGT71Yg8qjYsE6ZCp9 fZsVthur9rtmSuaHSYp+SeFiFgg8tahGTrEiUTg0s95EzGQOcSsQVGYG19lUsWFLyLAh aIBJ7E+D7VW9aLFCrmXQmuJQHjNgjtbSgYTMG0+lO6mPSh58bo+rHF8gHrlQ3xWa397/ u4WnUnEJu09Sh3tUgpBYe9dOl6FcLUkku7++7KMF3QaNx+pRwTDjVuy8Mpu94G0qorBn HjZg== X-Gm-Message-State: AOAM533JhtdiwGdSo4rp1z1FEcptEkxH8Bx5BPrlz1cMILdfRiD9n5Vi LL0j6DLKZ6nWZKH8KBXoMzLEHSMH3Wf6aZcdAi+7MqPMAKc= X-Google-Smtp-Source: ABdhPJyZjiz5kkUS8ujdTQy0ewsEAdY40A36ysawGiRI+bjUR7dVvNZ6I3GY1LUF1WSPsKazi0NCoTkk8ISpqMQq3Uw= X-Received: by 2002:ab0:48ae:: with SMTP id x43mr2284594uac.114.1603476284601; Fri, 23 Oct 2020 11:04:44 -0700 (PDT) MIME-Version: 1.0 References: <160347361732.20064.8971595941101788063@ietfa.amsl.com> In-Reply-To: <160347361732.20064.8971595941101788063@ietfa.amsl.com> From: Barry Leiba Date: Fri, 23 Oct 2020 14:04:32 -0400 Message-ID: To: httpapi-chairs@ietf.org Cc: httpapi@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [httpapi] WG Action: Formed Building Blocks for HTTP APIs (httpapi) 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: Fri, 23 Oct 2020 18:04:48 -0000 Aaaand, we're off! Thanks to Darrel Miller and Rich Salz for taking on chairing responsibilities here. I look forward to seeing the group decide on some items to work on and for the chairs to post some milestones. Barry On Fri, Oct 23, 2020 at 1:20 PM The IESG wrote: > > A new IETF WG has been formed in the Applications and Real-Time Area. For > additional information, please contact the Area Directors or the WG Chair= s. > > Building Blocks for HTTP APIs (httpapi) > ----------------------------------------------------------------------- > Current status: Proposed WG > > Chairs: > Darrel Miller > Rich Salz > > Assigned Area Director: > Barry Leiba > > Applications and Real-Time Area Directors: > Barry Leiba > Murray Kucherawy > > Mailing list: > Address: httpapi@ietf.org > To subscribe: https://www.ietf.org/mailman/listinfo/httpapi > Archive: https://mailarchive.ietf.org/arch/browse/httpapi/ > > Group page: https://datatracker.ietf.org/group/httpapi/ > > Charter: https://datatracker.ietf.org/doc/charter-ietf-httpapi/ > > In addition to its use for web browsing, HTTP is often used for > machine-to-machine communication, facilitated by HTTP APIs. This Working > Group will standardise HTTP protocol extensions for use in such cases, wi= th a > focus on building blocks for separate or combined use. > > Its output can include the following: > > =E2=80=A2 Specifications for HTTP extensions that relate to HTTP APIs (ty= pically, new > HTTP header and/or trailer fields) > > =E2=80=A2 Specifications for new message body formats, or conventions for= their use > in HTTP APIs (e.g., patterns of JSON objects) > > =E2=80=A2 Best practices and other documentation for HTTP API designers, = consumers, > implementers, operators, etc. > > Other items are out of scope. In particular, this WG will not take on wor= k > items for HTTP APIs for specific applications or services, and it will no= t > define new HTTP extension points. APIs for HTTP itself (e.g., in clients = and > servers) are also out of scope. > > To be successful, this Working Group will need to have active and broad > representation from across the industry -- e.g., API gateway vendors (and > other intermediaries), API consultants, API tool vendors, in-house API te= ams. > Therefore, adopted proposals should have public support from multiple > implementers and/or deployments before being sent to the IESG. > > To assess whether the group is functioning well, this charter will be > reviewed by the IESG nine months after chartering. > > This Working Group will also need to coordinate closely with the HTTP Wor= king > Group, in particular when new methods and status codes are proposed. Work > items that are more broadly applicable (e.g., for implementation in Web > browsers) are likely to be more appropriate in the HTTP Working Group, bu= t it > is expected that coordination and discussion between the groups' Chairs a= nd > Area Director(s) will guide work items to the appropriate venue. > From nobody Fri Oct 23 14:19:37 2020 Return-Path: X-Original-To: httpapi@ietf.org Delivered-To: httpapi@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B993A1393; Fri, 23 Oct 2020 14:16:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: httpapi@ietf.org, barryleiba@computer.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160348777797.5087.14518074466374395931@ietfa.amsl.com> Date: Fri, 23 Oct 2020 14:16:17 -0700 Archived-At: Subject: [httpapi] httpapi - Requested session has been scheduled for IETF 109 X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 21:16:21 -0000 Dear Amy Vezza, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. httpapi Session 1 (1:00 requested) Friday, 20 November 2020, Session II 1430-1530 Room Name: Room 1 size: 501 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/109/sessions/httpapi.ics Request Information: --------------------------------------------------------- Working Group Name: Building Blocks for HTTP APIs Area Name: Applications and Real-Time Area Session Requester: Amy Vezza Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 50 Conflicts to Avoid: Technology Overlap: httpbis quic wpack webtrans cbor People who must be present: Rich Salz Barry Leiba Darrel Miller Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Oct 28 04:31:50 2020 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 0B7EE3A0CD7 for ; Wed, 28 Oct 2020 04:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=endjin.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 es36IovlmI6W for ; Wed, 28 Oct 2020 04:31:47 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2120.outbound.protection.outlook.com [40.107.20.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C4883A0C8A for ; Wed, 28 Oct 2020 04:31:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BePSa2T2+Yvnd1ACoA1GCDX/fuJl7gHjOaE8wsqNKwjbKfNVnENKegvXef4DDL1ZNq4BzEV+ou35DBMLtITxjbr160Q9lvWRpe2IfTDIR/gy4+wUuM4i7U0YihnuYQ0bYXjTUdQGVqH5JToHkiV+Pa092nZpiSn7wCIyXUxFRtMiyhd4Z6uVUWTPJ3upgo3TzSSfrh4kwNMIaYe6IwMjMfM1TO9INscB6alX6A9JEMw2BHxdaxSz5O5n4elq2MUx14rRhccqy3AQ6/5hF4Bdd/lSz+xHUa/vNAF3PhccRT4vHDji5n58I1qd26j4bar3oKoBin3/flz6yRVzHc5e7w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tTMgvaMZOlBbtXShT68Jvx6u/uZndTf+3oG4pKPXP2I=; b=n1gx46HSx4JlU/TSnc1e/d9s2yZnxw/bWWPkIxBQismcW08EM9SzYEJVSu9V2aNgDUteYN/NdNPEqVihvLr3UR2n3jzahOxKjT2A7uCTvSIs1LpgjzOKtktinaj7taKVtZV9zvS2A0mv+TYgxSMpGOVdy3zlhEZnaBFiWvOTPWgp1ypGKhIbQ/lxTnErk2wWwOWrWyasHZJ5MR1EJV4V8MIv4ivG1Rfq0hSGX5CRUAHYNF+CiyhArFPCeyFLB2m6CFxoYlEnz8drvKAdXbrjI5AMNB+W8+uEZMD014lNF2Ej2GtTUPZtz4nXnsSKqhv0xzBocKeVeBN61Ea/sjLQRw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=endjin.com; dmarc=pass action=none header.from=endjin.com; dkim=pass header.d=endjin.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=endjin.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tTMgvaMZOlBbtXShT68Jvx6u/uZndTf+3oG4pKPXP2I=; b=ubScttlfuKBDEo0GJTLw+qM7egv+MBydOLTc1dA755o+9AOg/HPps7JJENuncJ2rB6hPu2wSVM/H0JOj4vF1HeJKdUd392NH3sIb3Cb2xOHIWUFgVJwAq8Txbl8LA7G56664hqEV7Ks7G9Jr1TYSy7UDeTfNAPruWrXZTnxiSqU= Received: from DBAPR05MB7255.eurprd05.prod.outlook.com (2603:10a6:10:1ad::24) by DB6PR05MB4584.eurprd05.prod.outlook.com (2603:10a6:6:52::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.19; Wed, 28 Oct 2020 11:31:42 +0000 Received: from DBAPR05MB7255.eurprd05.prod.outlook.com ([fe80::30a4:e30b:2815:bb60]) by DBAPR05MB7255.eurprd05.prod.outlook.com ([fe80::30a4:e30b:2815:bb60%3]) with mapi id 15.20.3477.029; Wed, 28 Oct 2020 11:31:42 +0000 From: Ian Griffiths To: "httpapi@ietf.org" Thread-Topic: draft-wilde-linkset-07 null anchor Thread-Index: AdatHBZERqTEgvWJTtWVtMxDF9rtpg== Date: Wed, 28 Oct 2020 11:31:42 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=endjin.com; x-originating-ip: [82.23.133.170] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6d238a24-8ee1-44ca-c68c-08d87b350b55 x-ms-traffictypediagnostic: DB6PR05MB4584: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qqFvPszO57o8hCHJtIdZrrtKStUOV52Md6UwAUWTT/PTSiSNIF8FHUpA4ipaC9dWn/XLGn+b9MKGNQ+FDef9xWatIk0s2EAWc3M9F2PMmlFZGCIgomvMDKgzvGHnbjEe09K5sl/UotDLwLJFEFv3igz4JWp5c87F9FFwj9tkF4FUdsIX3461dsRHTlCSvioePuzEOe9jMPodpgpynr3dX/pSwAaKDUS7ZpYyxnYJulvhKxHZ6a+gqPutpLiApIntQcwIFvylYaLHt2jryCwIKDoTsFR5CHzdGCN2L3NmELPzTrEFBtoi8C42R10hOaO9BeyrngRJf39cliMC1rUx3g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBAPR05MB7255.eurprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(346002)(396003)(39830400003)(376002)(136003)(5660300002)(52536014)(6916009)(26005)(66946007)(76116006)(64756008)(66476007)(66446008)(66556008)(33656002)(186003)(316002)(2906002)(71200400001)(7696005)(478600001)(6506007)(55016002)(86362001)(9686003)(8936002)(8676002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: WywWCYwgnDUdcHoj8S7cDGz/idcZLvi5n5US0iAM/po5ntSX0MMNIdTDLSmrUd52MxSwE5v+1KhIalKDV4O7OSgvpuIn0m9ya5XnNCqvXAr2cttLvQPFdb0VJ6I37m/gqLKxTp1b6Z7uNXsuhF4gmcFw29szZI8tfDmiUzoBTfqp7riPPUaMIIk/DB9ruY0F4nyGLPYxUtDoK+thYCgQlhQavL4yzwCdfE4qimYKXaeibJ3fFI0HxpghhVLEjks3ts09KMYKS3WQut++DxuPFtxRUe5zThVyCasN45KLnnBHXY2eKtXR4V5q3jVGqztCFUtk4ei5rOv1DIoOnp2WheGgsgqtXl5pEjWX/Dt/yraDsZSUjyLIQu9EiaPV7RkHz4xTJLm5X5ub/rw+MiGSQAtKcjfN5SnCUsdMAvqJecdo/MRS7KvgQv1DY0bI5vQFxYVxylGmHWff5OGZlZVAFSBsTRf1TycUHsAGLS8F6d7WB57MbCtv7cLdGW7N7i3zasbmOVkHgIVJBXlDI3PJtqqGMGur9Tx5BG/D07TKx/BGGAdvqpJxKTHSNIX67xvKlDqsTrP1nyJ3gc6oBDBppX3C05qGckaJGi/mM0cNYLh7DvFFOhar8C3irNGZDHaHtQ1x1tOSVOxk1uIrUcggdQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DBAPR05MB725591D1DD1DB15230A99E5D85170DBAPR05MB7255eurp_" MIME-Version: 1.0 X-OriginatorOrg: endjin.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DBAPR05MB7255.eurprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6d238a24-8ee1-44ca-c68c-08d87b350b55 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Oct 2020 11:31:42.5274 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0f621c67-98a0-4ed5-b5bd-31a35be41e29 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: n1jZ2NLtR4YKdOjueXtRhbnQQKFsmtWSCsR0aep8hZQfFk29dOfO5yoJSV0j81Bk5DHUAqIXiee1DgLQvlOuXZZPcwqGewbBfztkpQel0Ms= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR05MB4584 Archived-At: Subject: [httpapi] draft-wilde-linkset-07 null anchor 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: Wed, 28 Oct 2020 11:31:49 -0000 --_000_DBAPR05MB725591D1DD1DB15230A99E5D85170DBAPR05MB7255eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think I might have found an inconsistency in "Section 4.2.2. Link Contex= t Object" of draft-wilde-linkset-07. This states that in cases where "no va= lue is to be provided for the "anchor" member", a link context object MUST = provide an: > "anchor" member with null value ("anchor": ""). The example in parentheses appears to contradict the text that it purports = to illustrate: it shows an empty string, which is not the same thing as a n= ull value in JSON. (This is inside "Section 4.2 JSON Document" so JSON type= s and values are relevant here. Moreover, since draft-wilde-linkset-07 does= n't define what it means by null, the obvious interpretation of "null" in t= his context is the definition given by the JSON spec.) If a null value is required (as the text states), then the example should b= e "anchor": null, shouldn't it? Alternatively, if the example is correct as it stands, then shouldn't the p= receding text say "an empty string value" instead of "null value"? Also, "4.2.3. Link Target Object" does the same thing regarding href, offe= ring ("href": "") as an example of what it calls a "null value". If the intention is that "null value" is just the language being used to de= scribe an empty string intended to signify an absent value, it would be hel= pful to clarify that, since JSON defines null as a type and also as a disti= nct value. -- Ian Griffiths endjin.com --_000_DBAPR05MB725591D1DD1DB15230A99E5D85170DBAPR05MB7255eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think I might have found an inconsistency in ̶= 0;Section 4.2.2.  Link Context Object” of draft-wilde-linkset-07= . This states that in cases where “no value is to be provided for the= "anchor" member”, a link context object MUST provide an:

 

> "anchor" member with null value (&quo= t;anchor": "").

 

The example in parentheses appears to contradict the= text that it purports to illustrate: it shows an empty string, which is no= t the same thing as a null value in JSON. (This is inside “Section 4.= 2 JSON Document” so JSON types and values are relevant here. Moreover, since draft-wilde-linkset-07 doesn’t de= fine what it means by null, the obvious interpretation of “null”= ; in this context is the definition given by the JSON spec.)

 

If a null value is required (as the text states), th= en the example should be "anchor": null, shouldn’t it?=

 

Alternatively, if the example is correct as it stand= s, then shouldn’t the preceding text say “an empty string value= ” instead of “null value”?

 

 

Also, “4.2.3.  Link Target Object” = does the same thing regarding href, offering ("href": ""= ;) as an example of what it calls a “null value”.

 

If the intention is that “null value” is= just the language being used to describe an empty string intended to signi= fy an absent value, it would be helpful to clarify that, since JSON defines= null as a type and also as a distinct value.

 

--

Ian Griffiths

endjin.com

--_000_DBAPR05MB725591D1DD1DB15230A99E5D85170DBAPR05MB7255eurp_-- From nobody Wed Oct 28 04:39:43 2020 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 709113A0D71 for ; Wed, 28 Oct 2020 04:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=endjin.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 uOuYSMYhZ3Ce for ; Wed, 28 Oct 2020 04:39:40 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2096.outbound.protection.outlook.com [40.107.20.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E10A73A05A6 for ; Wed, 28 Oct 2020 04:39:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UB0UJL1O42z8r6T5AMwMURTqf+rWUDaApym2P7lgkWomYC+ux3bgsSJbX0+aeeWdyIldGLvIohczVgbVlpzvJz3jVsreF7Bmr1IHV1XE6y6Q8o23L3uYkIS8uSWkcfH6HF/X4PhM2FZ4Bifu7+G2MW0sB5522FCWDOCS6NhMx7CFEWOVZjen/y16BOy8uwzzWU+3xX8lB2eEhuXo7hxY0AG779mwaLONOAN/egi+WXMUW0SsnjZlyew5lHBODaQKRaFOkQI8aYO3vDwSb3Axsnx+XvVuMaXrIXZT+B7s6Wgz3IMg/XYE6lUbuWdyUTI3a3hbLRPW9oO3j6KACRHBpw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+sSQJq3EI3e9t4+O8kd/b/3k75gpSKymBBOumjNfYjs=; b=g6wnWWXs+CDrd/rjFw1mtuFvzvIG/sPTuUTPG36MIoo6otjkkhjA8IySKOJd+isQfS7eqapBlGbjFRVXCbDXn3OUdDMx6CWt8ingLZ/aU52geqHTkoX1GQlB5H/vgBno5dkQjOkaq4DO4lHxgxxNL2JYLW/MMjUxtwBPeN5bw17usCGd2UpycrdJsxpNgtDR2PF/1hOcsW6TjS126OaJAzhAWZPGZof6PaKGznuyTnoth3DF6QvN8aWJQpMY4H5lr44Z9dkpsbaTBZxTs6zjhme6T63usafcT1i9QuTowHfVeFuAXPvb3ahLC8l0qat6pcDmMzE3wUtWJz4OzxPiMw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=endjin.com; dmarc=pass action=none header.from=endjin.com; dkim=pass header.d=endjin.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=endjin.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+sSQJq3EI3e9t4+O8kd/b/3k75gpSKymBBOumjNfYjs=; b=GsEQURfj07+hhqu/X2H2edq8Qybd542k/HpBAoUUKcFQV01dSTabXDvmWfVtMJY3H8pOH//RDD2FfgNUbDAJQnqkh4Wsiz9MSjHN+wbWkrbf3QO3kSNyZ8pyZZIjK7COuw9oAnPB/FiBEMlESLGA5V/SPjI5B92+QseY5ssOY/0= Received: from DBAPR05MB7255.eurprd05.prod.outlook.com (2603:10a6:10:1ad::24) by DB9PR05MB7689.eurprd05.prod.outlook.com (2603:10a6:10:219::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.21; Wed, 28 Oct 2020 11:39:36 +0000 Received: from DBAPR05MB7255.eurprd05.prod.outlook.com ([fe80::30a4:e30b:2815:bb60]) by DBAPR05MB7255.eurprd05.prod.outlook.com ([fe80::30a4:e30b:2815:bb60%3]) with mapi id 15.20.3477.029; Wed, 28 Oct 2020 11:39:36 +0000 From: Ian Griffiths To: "httpapi@ietf.org" Thread-Topic: draft-wilde-linkset-07 JSON attribute ordering in internationalized target attributes Thread-Index: AdatHkuJav87CB/3QcusE4u5yNbREQ== Date: Wed, 28 Oct 2020 11:39:36 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=endjin.com; x-originating-ip: [82.23.133.170] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d0a27180-417a-4ad3-7ee3-08d87b362602 x-ms-traffictypediagnostic: DB9PR05MB7689: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: GyIckJH8Ngbz+lkp+J5DOZW4x93gRWbRJvvIFbLtnftM+uHlCad7oRtVJG2m0Sj3BQrLKTM+bmWvWN6VA9wC7dNku31TZCtolPR734/N0v3EPZE3/SqwIG4PGl8cH9dr1O0hrqCM+djQh7Nm/EQbySjk0XBAmKwTSiqH88e9jIsgwUJYyGtYTEQdHJHhwN7i1MDqNXZBCLg2pQT10Tr0xHLEMwWM50XgoMHndgNY1/HSEfkCwO/vjAas3/dVf19bAAxexyh7YPNf2Ks1P2Q5qM0aHENEVORLc6yQF+6mw4bN1OnXoSgbUJ2htsrEudQ+kEPj1YflfUFpNFtAQULBkg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBAPR05MB7255.eurprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(39830400003)(376002)(396003)(136003)(366004)(346002)(66946007)(8936002)(64756008)(6916009)(9686003)(76116006)(66476007)(316002)(83380400001)(66446008)(66556008)(33656002)(6506007)(26005)(478600001)(8676002)(86362001)(5660300002)(2906002)(7696005)(71200400001)(52536014)(55016002)(186003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: W0Th5xYUT6J6QZPHVajtSpiPuF4nr2IUPfk/Ir24fYuC/DjPkhAzuu56fZ/X7vOmOFYR2zTQ2uwA9vZ1soZgk7wo4nJoxkgfJtPepqVgWxBoUkUn2gosriZoAsp1x8g5s5Rv8FY+vws7GHQypVJxff4fE2C77BD8sbuatzGNG/w4xL2wus2XJ7G6b8BIH9eI/ySV2LJjEBU5TcWIk3QfiiCTAoFe0JBpgh2ctiJag2rmyFyU2R6opsPeFiaEdc/bUof6QTBdm0tiKlVp+42xwUENwdZr+CptO01bFTa7VaPnbf2ENQUy3mtxjr4zccOUt2qhMV6ws+WGfGh1s4eBnRk/5m5Mw1rClhJutRNX+cKvGB9IyKmJVXZJUXYuvPipy4aH9N+EzQiWOHVEVmKRFTXRCKWr69xmf3PBOSteb7riQO66u4jTSUE5LFaiXpQ8Y4boz2u0Mf256NCbAurLC48QpC0GMj/3OcJVNhr+1Z7KRNnNdIeKbIvpWzt9Xn3DC3gyw50zFuQq0r6wUpLVv/jeul3tMnR7l9/JHDBmxtRIRAX0Jff3WWZPsHOrOAX9gjhlB6jAy8SQjWxhTGign6MYMoaqcJ/lPo7l6e+FBdzWchTpRFvWI1tHcQyekkE8O9PHc4rqVmIkAXS62VwcLg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: endjin.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DBAPR05MB7255.eurprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d0a27180-417a-4ad3-7ee3-08d87b362602 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Oct 2020 11:39:36.8197 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0f621c67-98a0-4ed5-b5bd-31a35be41e29 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pkxbA/j6Uj9JE6y10cLICiV/nLT4E0nj8B5fr+WUDgA0ECq738ffOJRq/IYSoZRe0qFtQycIpGjkfrwX65jZ1i4uQB7tjhFwkh4MvMdnOBY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR05MB7689 Archived-At: Subject: [httpapi] draft-wilde-linkset-07 JSON attribute ordering in internationalized target attributes 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: Wed, 28 Oct 2020 11:39:41 -0000 In draft-wilde-linkset-07 , "Section 4.2.4.2. Internationalized Target Att= ributes" seems to indicate that the order of attributes of JSON objects rep= resenting the value of an internationalized target attribute is significant: > The name of the first member of such JSON object is "value" [...]. The n= ame of the > optional second member of such JSON object is "language" " The use of "first" and "second" here seems to imply that a value of this fo= rm does not conform to the specification: { "language": "de", "value": "nachstes Kapitel" } because the attributes are in the wrong order. Is it the intention that this be considered wrong? That might be problemati= c because some popular JSON handling mechanisms make it difficult or imposs= ible for developers to control the order in which attributes are emitted. I= f the use of "first" and "second" here isn't meant to impose an ordering re= quirement, it might be worth considering rewording this. But if there is an= ordering requirement, it might be good to make that clearer. --=20 Ian Griffiths endjin.com From nobody Fri Oct 30 13:17:16 2020 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 019463A1200 for ; Fri, 30 Oct 2020 13:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, LH_URI_DOM_IN_PATH=1.533, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 iNpqkOhwdlet for ; Fri, 30 Oct 2020 13:17:12 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640102.outbound.protection.outlook.com [40.107.64.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F2CD3A11FF for ; Fri, 30 Oct 2020 13:17:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n25bBIrIEz8OudTHNQ+xB0n1rk3Qre6Qe4uajVY+gEQaL0KxOKXucsnBrAyjv7jnDWdg304oKAF1Jz80OE1rvfdloj1KERTAtlS15Ek8ipPWG3Eyh2oBzmWekJEdWQVdWOb+q/yiS44XBtYB48aYmnIaK0bmbb9pxboxmgdd9RZbIiQjPhDnIMhOfysxbL8RePLj6up9pPDhfMGpVgJp2MhSufX4YI1WdB05CvTuc3LdY/wHvwaZyJWg5oEVj/sNqM6a1CIuFA2kqctLq1k/dq+qpbE30ZOBhBuAR5jNKUc5OOlbtkwbs35LSQRe7bemko3t3JwnurfZDEc1aOd+qw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/ILbRHmsYfxZmyF3TbznCZSnZF0ZWbXPInobd7eQwXI=; b=blDOWoMqTpMjFB3lvVd0lkhhLnu3gIWZLe/3ca+wcEVZQNE8uCr1TQjQyWfDLQ2SM0wz4rME9UeVL6v9//3j3dbFfv4qqU1OdCr2NSi26YqlU3k/9/YTJuF4m0cnS4vUDhe2AOy5kJUgNrr4Y7qv9ar3tZvhJyUE13AuBkYlIqNjYxX7bdub3VpZOK7fgQ2m6XJQZF1GbAY/NNvDyWOgmsx/sb79OcH6L2qAI85noEoGq+1nwhhXJmCZE217bQi4MHtH3LfvDvBgKWH1J9F8vyOf37YMq8+hsgUKcuLb2DMaAldMHsI9wiGK+Sp5MxJxMBeEU2y7z9105XY1Y78PcQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/ILbRHmsYfxZmyF3TbznCZSnZF0ZWbXPInobd7eQwXI=; b=YwdQ3c1DBZmAfCzTEZSBDVMexhMo76H74A8v9gZ/BSmAjBYhxFguSWgYXp93RukmsRL1fSvf9+qv40fxataZK2qfni6ih/iCxcMWHT6R9ypwj5UbkHug+uxWr+VTSQSn9YcGEoW3gD/sgbPvkPviRtovoqaeZNzNG39LbPfKp68= Received: from (2603:10b6:a03:1d7::24) by BYAPR00MB0567.namprd00.prod.outlook.com (2603:10b6:a03:102::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3561.0; Fri, 30 Oct 2020 20:17:10 +0000 Received: from BY5PR00MB0840.namprd00.prod.outlook.com ([fe80::680e:d328:6e71:6be8]) by BY5PR00MB0840.namprd00.prod.outlook.com ([fe80::680e:d328:6e71:6be8%9]) with mapi id 15.20.3563.000; Fri, 30 Oct 2020 20:17:10 +0000 From: Darrel Miller To: "httpapi@ietf.org" Thread-Topic: Proposed agenda for IETF 109 httpapi meeting Thread-Index: AQHWrvU21YaBbARrN0yZn/e9s8AnpQ== Date: Fri, 30 Oct 2020 20:17:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-10-30T20:17:09.873Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [74.15.147.35] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 6c08f46a-0aee-4e61-9d9f-08d87d10c808 x-ms-traffictypediagnostic: BYAPR00MB0567: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1728; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 73/j+qZQJOgTgW13l/DuB1tkUbJJGq6tbGAgqcu/DQWRitj0s7yoOXn0dDWAO2wJ/hGBKSSwzUi6woybQ3EDVCDU/dt6gtBijiUMUYotUysvNqcaH1i6jEzPsaxEPp0U9IKgU+5ZYPIGwdZ+ILI/LFEZT6sfKJkl9vXcquuus5HRPz9F6d9pE4LJvrfZNK9LnTJMbX4BdH3IRviyFJu1ZOwVYDB3+a13mm4kMmxdH4VVp/s8zlpZR/lbPhqUE1pMQpxSuqGN+BU/RYhFdyQOdwTykvzIAUYSt+arP496EdLHnYrpu+uIw2YrMLHFpUQ6oTpiEBBX8xTP0NO3hTi7oyhtRTZCdxHTm0jl+J+N5tCVjaBjo/R6fQSYf8Fn4Ujh1eeYa3yslXrvjA0yZIJzyA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR00MB0840.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(136003)(376002)(366004)(346002)(396003)(6506007)(966005)(19627405001)(26005)(6916009)(186003)(83380400001)(71200400001)(82950400001)(33656002)(2906002)(86362001)(52536014)(82960400001)(8676002)(8990500004)(5660300002)(8936002)(316002)(7696005)(4744005)(91956017)(9686003)(76116006)(64756008)(166002)(55016002)(66476007)(66556008)(4743002)(10290500003)(478600001)(66946007)(66446008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 6dwvyx0oFgkVSusT7a+90dFa3NSqNNq4ole+fqmUhgyzpAPa+BzTMcjJQE+/rfwO19Be3AywXKYVmHghvPyG53HauU95rVxhQ3vhRsHLhcyAf7XdvWw/H0xTNNzN7QPRO68P89dZvfmWJLktFsM5v1hEqiDH0Uzk1vWi73sxwL6IOwHRMTsX34wE8s0vf4uNj7ev8/Zy/2YWrC46mFF5BiZBriiDzDA84szjDCutBkTPqrVoLuoZN57TYrUnBPNp/hj4PEWE0z50ocMcWoT3qvLcIEeU0CnfriBlLJ6bb/88qx4ZYm6d+x4eBcppbUayvqf9EsKos/+sxwThM6QYFYbuRrqHmdwh1kQ1t2yrF4iMm6Ig1whb6YqpsLrsUVuY8GzV+iLXYfuiaq9sUL+P7baJLbdDYZ5G7emwBdzxcn+l4TIvuszgX80V5EgMG60vnujoNouM8WQiKfRxl26kBjN/jdIck61kzGd+WFfVZ3O1fk6BFmPpuje/V/F7LhaavJcZGhDSF1L7xQ3buMgVc1K6XTZqBBgQTgIcqPCmBqm4538jmR1uSiPNrf8QJALGdU1OjkmMyZZWAPMBX0FudjXXyAOB9B4gZueaQdJnbZ8UQrbDanfaqsqHftHGfexHzZxgndNd0qSFY3M5+KPKJA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BY5PR00MB08402B14CBF81AB2B528C888F0151BY5PR00MB0840namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR00MB0840.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6c08f46a-0aee-4e61-9d9f-08d87d10c808 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2020 20:17:10.0776 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: AMvrEXlF3k/hDkAy/B/v0ysNPIbN6ipaFaAH4QvJkNyltK0z7oG1pUiALdMGmn5yoQidw9KYK78X62vthB//qg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR00MB0567 Archived-At: Subject: [httpapi] Proposed agenda for IETF 109 httpapi meeting 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: Fri, 30 Oct 2020 20:17:14 -0000 --_000_BY5PR00MB08402B14CBF81AB2B528C888F0151BY5PR00MB0840namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Meeting time: Friday November 20th, 7:30am UTC Agenda Items: 1) Rate Limit Headers - Roberto Polli https://ioggstream.github.io/draft-polli-ratelimit-headers/draft-polli-rate= limit-headers.html 2) Deprecation Header - Erik Wilde https://tools.ietf.org/html/draft-dalal-deprecation-header-03 3) Linkset media types and link relation - Erik Wilde https://www.ietf.org/archive/id/draft-wilde-linkset-07.txt 4) Content-Warning Header - Erik Wilde https://tools.ietf.org/html/draft-cedik-http-warning-02#section-1 Darrel --_000_BY5PR00MB08402B14CBF81AB2B528C888F0151BY5PR00MB0840namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Meeting time: Friday November 20th, 7:30am UTC


Agenda Items:

 

1) Rate Limit Headers -&n= bsp;Roberto Polli 


3) Linkset media types an= d link relation - Erik Wilde

 


Darrel
--_000_BY5PR00MB08402B14CBF81AB2B528C888F0151BY5PR00MB0840namp_-- From nobody Fri Oct 30 13:42:45 2020 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 0D4FF3A122C for ; Fri, 30 Oct 2020 13:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evertpot.com header.b=YkcQDMHK; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=UpJB2HyA 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 A1eTO7TPjtQ0 for ; Fri, 30 Oct 2020 13:42:42 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DB313A122A for ; Fri, 30 Oct 2020 13:42:42 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 6AAB35C01CC for ; Fri, 30 Oct 2020 16:42:41 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Fri, 30 Oct 2020 16:42:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evertpot.com; h= to:from:subject:message-id:date:mime-version:content-type; s= mesmtp; bh=hQWKIt+6tQOy/G+uK/qYYur/2OQbBWW/y4fKSygmSFw=; b=YkcQD MHKbTIO6BE8JjQWMHRLyY2/fVyxO+b15ecn91SOuWWNazttKxepNSqVLn/OzZrya mPCbrgJCiLvXkAe2n82K9TTbe9rGUjYCBeNv5g5BXpQLXEEtXjDQx41pOBi0A4HU dg9Or9u0Xedad9jvleM90sUGi7+Ek+/90tOKcg= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=hQWKIt+6tQOy/G+uK/qYYur/2OQbB WW/y4fKSygmSFw=; b=UpJB2HyA1y8ueWkl93cO7jKf6TTXNDdbPkuXRTWMGJlZx xwvDjDgeVJnqpxawiy1/PxVPjfxl47zCmnsYggY52FE4SpMfIMEE2VVAOshfHRp/ JGFLTcuYefNmOJH6S/Wkk7ErxnVVcQnUoyaVDtfh/ADobYkoyyxTLTFEWFcM91y5 4ijXTSwptSrFGm5iEw5aWzTAcH6EkjY3rTzDol23wI8I/n8+U04pPOecuQUGJ0hZ l1JUHum9Fe5XvKr8RyZHgKVpWVijxbdDI3E4NK5kmKIC4VqL19Q6j/KCoAQ2lJuD TlXmuUFvFILk0Drjb03tpEml5CYdMXs7Dp30QsWVA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrleehgddufeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefvhffukffffgggtgesrgdtreertd efjeenucfhrhhomhepgfhvvghrthcurfhothcuoehmvgesvghvvghrthhpohhtrdgtohhm qeenucggtffrrghtthgvrhhnpeethfektedttdeggfdvtdeihfehhedvtdefueeikedvud dtjeekfffhveeuhefhieenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppeejtddr vdeirdehrdefudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehmvgesvghvvghrthhpohhtrdgtohhm X-ME-Proxy: Received: from [192.168.2.61] (bras-base-toroon0560w-grc-30-70-26-5-31.dsl.bell.ca [70.26.5.31]) by mail.messagingengine.com (Postfix) with ESMTPA id F18A3306467D for ; Fri, 30 Oct 2020 16:42:40 -0400 (EDT) To: httpapi@ietf.org From: Evert Pot Message-ID: <5a806987-70c7-e7fe-e773-11625d9c51dc@evertpot.com> Date: Fri, 30 Oct 2020 16:42:40 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------110A9B2247C69B2DAC5008FC" Content-Language: en-US Archived-At: Subject: [httpapi] JSON serialization for Web Linking 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: Fri, 30 Oct 2020 20:42:44 -0000 This is a multi-part message in MIME format. --------------110A9B2247C69B2DAC5008FC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi all, I would like to bring contribute this draft to the group: https://tools.ietf.org/html/draft-pot-json-link I realize it has overlap with a draft submitted earlier here: https://tools.ietf.org/html/draft-wilde-linkset-07 However, I feel draft-pot-json-link serves a more general use-case and has a more specific scope. If accepted, I think draft-wilde-linkset could potentially refer to this serialization. I think it could be helpful to have a single RFC to point to as /the/ way to serialize a link,. Linkset also attempts this, but I worry the other features (prescribing a media-type, linksets, the non-JSON serialization) might detract people from adopting the draft for their own format due to a potentially perceived larger psychological buy-in. The next JSON:API format will adopt draft-pot-json-link as their link serialization, which means a large number of clients and servers will eventually use this specific format. Evert --------------110A9B2247C69B2DAC5008FC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi all,

I would like to bring contribute this draft to the group:

https://tools.ietf.org/html/draft-pot-json-link

I realize it has overlap with a draft submitted earlier here:

https://tools.ietf.org/html/draft-wilde-linkset-07

However, I feel draft-pot-json-link serves a more general use-case and has a more specific scope. If accepted, I think draft-wilde-linkset could potentially refer to this serialization.

I think it could be helpful to have a single RFC to point to as the way to serialize a link,. Linkset also attempts this, but I worry the other features (prescribing a media-type, linksets, the non-JSON serialization) might detract people from adopting the draft for their own format due to a potentially perceived larger psychological buy-in.

The next JSON:API format will adopt draft-pot-json-link as their link serialization, which means a large number of clients and servers will eventually use this specific format.

Evert

--------------110A9B2247C69B2DAC5008FC-- From nobody Fri Oct 30 13:48:14 2020 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 BF8463A122A for ; Fri, 30 Oct 2020 13:48:12 -0700 (PDT) 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evertpot.com header.b=erIc4wMe; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=rDla5Upr 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 MMeZPX8XsxkZ for ; Fri, 30 Oct 2020 13:48:11 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 382CF3A09AD for ; Fri, 30 Oct 2020 13:48:11 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 60BA45C01FC for ; Fri, 30 Oct 2020 16:48:10 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Fri, 30 Oct 2020 16:48:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evertpot.com; h= to:from:subject:message-id:date:mime-version:content-type :content-transfer-encoding; s=mesmtp; bh=UpaEGlLbjxb+zY/Mw9GXYeV O1FHVf7J8e10G7iHilOs=; b=erIc4wMey1BQRnIycfBNRWFwjb7eF65KFnuvSgK IADE5rCrcRHq6dg2oDSWozH8WSZmRLo1Z8GGdy+n29U0r1WUWf58f2bcKDDzFNRs ZxIYIktAHDAubuMIVLGVtzeO7Ka0+LJ9Z7C/etSst2bKQDX3KwlHsBZoNynGXd7y PU4A= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=UpaEGl Lbjxb+zY/Mw9GXYeVO1FHVf7J8e10G7iHilOs=; b=rDla5Upr9Ciq/bJvdkMGWL ly3lmdeCdJG/JJI/+lxvfvT1c+OQTFnbOOOEHjapl/V+UqjL1NFAdljioBLQwy7r 2Lt/TkoRC4bixFgNX8o2SA6Rb/sSS+k5SH95exFVbdnmUR2jvu1URY3rvY5omtCX CjfOZkznAwYu6e7GA/LqE+rflgTxNlo21kwFykHwbt4vQym+zaIW76OECPM6BD3m tk/Uv7DXqpzV7vEN0odgbwAu3ReLndD6NvhXlQlnvE0bcQY38h6ab+JpcvaSuqUX NcBvo0os6ILFHZANQtEFoF3R2U2m+cV79wcb+x22nUaBPyaYvTaVyt1MvyWuzPjQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrleehgddufeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefvhffukffffgggtgfgsehtkeertd dtfeejnecuhfhrohhmpefgvhgvrhhtucfrohhtuceomhgvsegvvhgvrhhtphhothdrtgho mheqnecuggftrfgrthhtvghrnhepveefudejhedutdfffffghfekleehfeevvdfhheelke euleduieefueduveekkedunecuffhomhgrihhnpehirghnrgdrohhrghdpihgvthhfrdho rhhgnecukfhppeejtddrvdeirdehrdefudenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpehmvgesvghvvghrthhpohhtrdgtohhm X-ME-Proxy: Received: from [192.168.2.61] (bras-base-toroon0560w-grc-30-70-26-5-31.dsl.bell.ca [70.26.5.31]) by mail.messagingengine.com (Postfix) with ESMTPA id E85063064674 for ; Fri, 30 Oct 2020 16:48:09 -0400 (EDT) To: httpapi@ietf.org From: Evert Pot Message-ID: <3564d56b-55ca-63e7-7557-b9c11e9c7c2c@evertpot.com> Date: Fri, 30 Oct 2020 16:48:09 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [httpapi] Link relationship types for authentication 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: Fri, 30 Oct 2020 20:48:13 -0000 Hi group! If this is appropriate, I would like to propose a standard for a link relationship for authentication-related operations. Specifically the  "authenticate", "authenticated-as", "logout", "register-user"  relationships. The goal ultimately is to update this registry: https://www.iana.org/assignments/link-relations/link-relations.xhtml Draft: https://tools.ietf.org/html/draft-pot-authentication-link The first version of this was written some time ago, and I've gotten several reports of people finding this useful and adopting these in their systems. I don't know if this is an appropriate draft for this group. I tried at a few different groups, but if not I will turn this into an individual submission. Cheers, Evert From nobody Sat Oct 31 01:34:57 2020 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 B40653A0846 for ; Sat, 31 Oct 2020 01:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.247, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 4jzjwuhD8It1 for ; Sat, 31 Oct 2020 01:34:54 -0700 (PDT) Received: from postoffice.gristmillmedia.com (dret.net [209.188.86.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 001213A0844 for ; Sat, 31 Oct 2020 01:34:53 -0700 (PDT) Received: from 7.58.0.85.dynamic.wline.res.cust.swisscom.ch ([85.0.58.7]:62819 helo=dretpro.home) by postoffice.gristmillmedia.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1kYmLb-0004Kz-UZ; Sat, 31 Oct 2020 04:34:52 -0400 To: Evert Pot , httpapi@ietf.org References: <5a806987-70c7-e7fe-e773-11625d9c51dc@evertpot.com> From: Erik Wilde Message-ID: Date: Sat, 31 Oct 2020 09:34:50 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <5a806987-70c7-e7fe-e773-11625d9c51dc@evertpot.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - postoffice.gristmillmedia.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dret.net X-Get-Message-Sender-Via: postoffice.gristmillmedia.com: authenticated_id: birdhouse@dret.net X-Authenticated-Sender: postoffice.gristmillmedia.com: birdhouse@dret.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [httpapi] JSON serialization for Web Linking 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: Sat, 31 Oct 2020 08:34:56 -0000 hello evert. On 2020-10-30 21:42, Evert Pot wrote: > I would like to bring contribute this draft to the group: > > https://tools.ietf.org/html/draft-pot-json-link > > I realize it has overlap with a draft submitted earlier here: > > https://tools.ietf.org/html/draft-wilde-linkset-07 > > However, I feel draft-pot-json-link serves a more general use-case and > has a more specific scope. If accepted, I think draft-wilde-linkset > could potentially refer to this serialization. adding some context: the linkset work started in 2016, starting with the explicit goal of creating media types for RFC 8288 web links: https://datatracker.ietf.org/doc/draft-wilde-linkset/ since then, we've had 11 draft versions (across two I-D names) and quite a bit of community participation and discussion: https://github.com/dret/I-D/issues?q=label%3Alinkset > I think it could be helpful to have a single RFC to point to as /the/ > way to serialize a link,. Linkset also attempts this, but I worry the > other features (prescribing a media-type, linksets, the non-JSON > serialization) might detract people from adopting the draft for their > own format due to a potentially perceived larger psychological buy-in. i am not quite sure why that would happen. we do define a JSON serialization that people can use while ignoring everything else (but there isn't actually that much else). we spent considerable effort to raise awareness, to make the serialization JSON-LD friendly, and as a result we have implementations in the field. > The next JSON:API format will adopt draft-pot-json-link as their link > serialization, which means a large number of clients and servers will > eventually use this specific format. i'd like to propose a different route: if the goal is to unify JSON web links (which i agree is a good goal to have), then let's look at what doesn't work in the existing linkset serialization that JSON:API does need. we're still open for suggestions and feedback (even though it would be unfortunate to make any breaking changes at this point). cheers, dret. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Sat Oct 31 15:06:46 2020 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 69D983A07F5 for ; Sat, 31 Oct 2020 15:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evertpot.com header.b=k8aZwzpZ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=D7Cybdeo 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 iGX4wi26sQbc for ; Sat, 31 Oct 2020 15:06:43 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBBEF3A07C4 for ; Sat, 31 Oct 2020 15:06:42 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 396155C0074; Sat, 31 Oct 2020 18:06:41 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Sat, 31 Oct 2020 18:06:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evertpot.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type; s=mesmtp; bh=G8unra1ecupWLj8plRCmVZvO tUPvP0f/x/cAPkPJiGw=; b=k8aZwzpZM06Ed0Lgjp0PSt+ahFRrdLGfHhXpYLK5 wWy7WhrmtxFgj1be80LFLMkHzgXELtGhkHI1gQk9dPEYfKjIEw7echyuOQirc3xo rr/1ivj4L2XXkeu9SbeJWjsAx1YaX71BF4NCUb00+LlzKhchOXF1CHboGIYLP12f zoE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=G8unra 1ecupWLj8plRCmVZvOtUPvP0f/x/cAPkPJiGw=; b=D7Cybdeoqrom9KvfPYrjtm e0X7HQ6qb5gBRZdAB8+W+ShvFrSMgFjPTSVrmogo2GOB/NrTzuNw+7PHb40jOxTt AD01o2aooOKRrtQagDxOyiR2pWSXrlIriA1G1YuQ99Cn4KyeajWlLLGam6mkA9ex rkE/DjqbhGqLRZ8yzgIH2MrM56ipdNmHPAqdYlhyVZyXgw0mg3yeTwbrpYwnlpPx WNW05jV33xkIl415kzj8mhKNxNI1bLDltVRjyDh5AuZXWVNRo1Uh1vbzZsxw/S6r cHiftX50ItFZz4vN01tuKrZPweG20INFUPGy2KgSmwAf9m7EoU2lruzh+yZKf1ug == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrleejgdduheekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhkffffgggjggtsegrtderredtfeejnecuhfhrohhmpefgvhgvrhht ucfrohhtuceomhgvsegvvhgvrhhtphhothdrtghomheqnecuggftrfgrthhtvghrnhepte fhkeefledvjeduueegueeggfetieehiedvvddttdehledvtdegudfhleehiedtnecukfhp peejtddrvdeirdehrdefudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpehmvgesvghvvghrthhpohhtrdgtohhm X-ME-Proxy: Received: from [192.168.2.61] (bras-base-toroon0560w-grc-30-70-26-5-31.dsl.bell.ca [70.26.5.31]) by mail.messagingengine.com (Postfix) with ESMTPA id 6B2693280060; Sat, 31 Oct 2020 18:06:40 -0400 (EDT) To: Erik Wilde , httpapi@ietf.org References: <5a806987-70c7-e7fe-e773-11625d9c51dc@evertpot.com> From: Evert Pot Message-ID: Date: Sat, 31 Oct 2020 18:06:40 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E47BE88073CBE5D614826D37" Content-Language: en-US Archived-At: Subject: Re: [httpapi] JSON serialization for Web Linking 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: Sat, 31 Oct 2020 22:06:44 -0000 This is a multi-part message in MIME format. --------------E47BE88073CBE5D614826D37 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Erik, > i am not quite sure why that would happen. we do define a JSON > serialization that people can use while ignoring everything else (but > there isn't actually that much else). we spent considerable effort to > raise awareness, to make the serialization JSON-LD friendly, and as a > result we have implementations in the field. > >> The next JSON:API format will adopt draft-pot-json-link as their link >> serialization, which means a large number of clients and servers will >> eventually use this specific format. > > i'd like to propose a different route: if the goal is to unify JSON > web links (which i agree is a good goal to have), then let's look at > what doesn't work in the existing linkset serialization that JSON:API > does need. we're still open for suggestions and feedback (even though > it would be unfortunate to make any breaking changes at this point). This is what doesn't really work for me in linkset, as it is written today: 1. The focus is in linkset is on the linkset use-case and media-type. I think useful to splice out specifically a JSON serialization for weblinks. Even if linkset does define /a/ serialization of Web links, I think its helpful to have something that's more focused specifically on solving this problem. Messaging matters, and the linkset document does not really talk about this. The fact that it does define a Web Linking serialization seems more like a side-effect that a core goal. 2. linkset only describes document-wide links, which makes this incompatible with situations where you'd want to describe links that are not on the top-level of the document. Links, like in HTML, could appear deeper inside JSON documents and if we're proposing a standard way to serialize a link in JSON, it's nice to be able to support this case as well. 3. In linkset, links must always appear in a nested object, because there is no 'rel' property on a specific link, which makes this at least more clumsy to use in contexts where you just need to embed a singular link. If linkset is out in the wild, and you don't see a strong enough reason to make changes, I would still hope this group considers adopting json-link as well, as I think it's a useful building block for future standards. There's no reason different serializations can co-exist, and our goals I think are different. Of course I would love to convince you to adopt the general serialization, but I don't think it's strictly required for the success of each proposal. Evert --------------E47BE88073CBE5D614826D37 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi Erik,

i am not quite sure why that would happen. we do define a JSON serialization that people can use while ignoring everything else (but there isn't actually that much else). we spent considerable effort to raise awareness, to make the serialization JSON-LD friendly, and as a result we have implementations in the field.

The next JSON:API format will adopt draft-pot-json-link as their link serialization, which means a large number of clients and servers will eventually use this specific format.

i'd like to propose a different route: if the goal is to unify JSON web links (which i agree is a good goal to have), then let's look at what doesn't work in the existing linkset serialization that JSON:API does need. we're still open for suggestions and feedback (even though it would be unfortunate to make any breaking changes at this point).

This is what doesn't really work for me in linkset, as it is written today:

  1. The focus is in linkset is on the linkset use-case and media-type. I think useful to splice out specifically a JSON serialization for weblinks. Even if linkset does define a serialization of Web links, I think its helpful to have something that's more focused specifically on solving this problem. Messaging matters, and the linkset document does not really talk about this. The fact that it does define a Web Linking serialization seems more like a side-effect that a core goal.
  2. linkset only describes document-wide links, which makes this incompatible with situations where you'd want to describe links that are not on the top-level of the document. Links, like in HTML, could appear deeper inside JSON documents and if we're proposing a standard way to serialize a link in JSON, it's nice to be able to support this case as well.
  3. In linkset, links must always appear in a nested object, because there is no 'rel' property on a specific link, which makes this at least more clumsy to use in contexts where you just need to embed a singular link.

If linkset is out in the wild, and you don't see a strong enough reason to make changes, I would still hope this group considers adopting json-link as well, as I think it's a useful building block for future standards. There's no reason different serializations can co-exist, and our goals I think are different.

Of course I would love to convince you to adopt the general serialization, but I don't think it's strictly required for the success of each proposal.

Evert

--------------E47BE88073CBE5D614826D37--