From nobody Fri Jul 3 23:59:17 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AAC13A0CA3 for ; Fri, 3 Jul 2020 23:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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 nPz5og1TEUxn for ; Fri, 3 Jul 2020 23:59:15 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (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 73C143A0CA2 for ; Fri, 3 Jul 2020 23:59:15 -0700 (PDT) Received: from oxuslxaltgw10.schlund.de ([10.72.76.66]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MGCMz-1k6jDW2SO7-00FD7s; Sat, 04 Jul 2020 08:59:09 +0200 Date: Sat, 4 Jul 2020 02:59:08 -0400 (EDT) From: Timothy Mcsweeney Reply-To: Timothy Mcsweeney To: dispatch@ietf.org, superuser@gmail.com, barryleiba@computer.org, Ted Hardie Message-ID: <1425839401.61842.1593845948843@email.ionos.com> MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.1-Rev31 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:496lvEmVW12wooPCfggqvl8iSopqBnHFARf/bSZ/Do3DfRcuI3k KVMhsRKQxK3EtTJM3GnMSHUjBsjcF5kHo9h/59mz8uKSrjVIFW56yeLYeYcI+VAd1mXxkWi 58V9rjKipJOZWwfpW6fcyDnbnxivPnULG/iRLDBFecxMaCMtSgDN5aco8vkCHlzZECpfuv5 vR7ajDXGTiPesCpRmYdOQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:yALBNVhjduY=:jP52+euVjCd5gkBAkCJXow 7dSN8vcoFLYZOs0KTFbnxYbrTR0935HneNphpURxibGp9Vp6ZJNj+rhdTVIygfjms8jCdVqhH BHkUdSUqrWrxQGNb9485Uuh+Hv68K4+LpHb94+qOIg+FvVmmvcxwqm79kgBN2DcqgXg9Uvl8b 6dHzyzfXscxj9TviGnEKZaGrtoJiGRonH5Z4BCeC6jS+rB6esHjP+9Uxj84Z3aPOP9Uzlp3An pvOd93ciIDMbLYUBMitJuJJH6EMsCm+wuIq7FecvPm2wQgcssUJ4hRfAYXLqeJ2zAur98rhHF 62eDrI+3SoSNJxjCJvR1iu6D/4NNphzKpr1gCj4gaIFOm/aOFINmHgGk+BojJ5g3s0pgVvFeD XR3u3BF2hjZGTEgzElWaAd6wQB5ypajHdiyBT/9iHB/4JICfSmZ5aXWjk3SdzvaKkXCB9Z1G4 6k+oedL1O4uFGI3e3R5Gs6gTINdiu38ygDc+d7Tptnwl1f3NNTd7Qiith9ddCCXJdw90/3xOn cMWCmX4hEeUojaVq302YhfkCvzQZ27BaqLW9wqVim+k6e9tBf0tet5g94yiJ7FcWWXR2vD/D7 UQJRj3AQRhxNs8JZ/O8KMZJLLsEC6QJAsPUhnGtcJ+j6tTD4cH7+HdPpqWhdyF35f3tdck0ni zlafSq9DbpfZ3siVMU5N1akEr6WMdd772reibBvGiBNGRXmt5E3eYjbvwRikmhQKtr0jJQMsL h1tedUPP+IOD1Xnj/vH9Ia7+/InBvYOkbKRU+hjwCEInQrB4Uv5neUq88ECAdzgLFsmJ9QIQr u8+nmETb2mZVaCy8PBlkBBD/ZOsSZHhY2IBf9Un3IoJkp1g+jv7v4NaOyM9duwdz1VgJBOe Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2020 06:59:17 -0000
> I'm hoping for a quick dispatch of this, but happy to discuss.


What's the hurry Ted?

I know you know your stuff but this draft seems somewhat "corrupted"
In your introduction you're talking about registering scheme "NAMES"
and then state "..there is no way in the current process set out in BCP 35 [RFC7595] to meet the requirement." ??
Section 5 of RFC3405 has nothing to do with that.
Maybe it's BCP 35 [RFC7595] that needs the update. But hey, at least we
both agree that uri.arpa registrations don't currently require permanent
status.
From nobody Sat Jul 4 02:28:00 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC673A07FC for ; Sat, 4 Jul 2020 02:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, SPF_NONE=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 mHc4ccxpDbaP for ; Sat, 4 Jul 2020 02:27:57 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (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 417203A07FB for ; Sat, 4 Jul 2020 02:27:57 -0700 (PDT) Received: from oxuslxaltgw02.schlund.de ([10.72.76.58]) by mrelay.perfora.net (mreueus002 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MVwAo-1kOceH0sRM-00X5ZK; Sat, 04 Jul 2020 11:21:37 +0200 Date: Sat, 4 Jul 2020 05:21:28 -0400 (EDT) From: Timothy Mcsweeney Reply-To: Timothy Mcsweeney To: DISPATCH WG , superuser@gmail.com, barryleiba@computer.org Message-ID: <1007260719.140376.1593854488478@email.ionos.com> MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.1-Rev31 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:+ILLu90aboP0jvOz4T8AVsgX03fDlZOS7gY6Hd649lzTKT9Y6J+ KxkMoQD4ZjY3IR7aCWXLN3Q6KZj6hNKJGyqnI55nwlmfhIRibGLkB8YXHlMBqTAZkPANXcL CJgzkKXcc6prlCX8qM8djbPfZHbBefeh+MnXMJ/22/w4RC2zt/oYNXyyFRXJ36vJF8osF3l go01HAfwwAbvmWcgfw3aA== X-UI-Out-Filterresults: notjunk:1;V03:K0:IEXEgqxqIL0=:QPn4P+xwTpVe20K8hTSW8s yXpZAMGCPyQkzKDf/xtFuU24uIFJkUZ2Hk5WnRruLkixOP4L0HsCGhokBpeWE8vgkXBHlhW+e jEUUiInsxiiYB4EK6DGa5jRIXuI/sOVy1KMXyHZsBMg/FFMXlR3+JAxlnqB7ppmWZWaZcB1pU wmmxZRRA+xGVdIarao70mMfpUPJYopUeGoPyOIw0zgPfRiRyRrvDk8qJwVLeYk3JuqNXSOxOw xVMMX6gYcHXNxt2vUzFIRXkl65DJumeoCkDCO1tW2Tph8hEJqtZqoSTiKuRG1jxgcYKucKg1h 7IrsH6EG50n5Lvro/x0v7W6Tk14AYTgS695C6RdfhUeyUGNFpi6ioBkvWRaEBAzAX9U9IArwY gPqmNuTcV92gIewU7f258WTe6wIHqVpdeqVjGNQQKb1ti6JnpUVhRXGJBEGyCEoTTZTxC4PJ/ 7fQe2arlpR0K8tj+d4ROLrbzZMFRykIHPDOKMz+IjJN3bDo6AVQL+gThCas8Uuu+ThxPH4i1N Y/sVUO8fNEYPN08j9nJ3IEzUnJBPHuMQ30xkrKeJVSa0ZoesXp94K2uf4WaOksDr8MCJm2rNu /STjVe1MkwFAczKdTRUpTumKy1fHgh6TazpCOstc7WzYC5WcHYETSEDz5Jbg+9em3EBNjpExM wQJ/UqP9jg1nq5Jb5wj5V6XBuXGCz5+IeHPkYg/96XMT2qENXlGTLcHRNOY9TnLdMrOT1Q3OZ JMTgYIamBcSvLmG/QYqFAdhZlqYWqXYCF91DvK0cU3yt3iJTvR2+txz8m967KjSLHxigBI8yP u2FnolFrN5mn2BpwjSJ1LvRbgjz9WclvNcMl/9JQAFQBpVioPNMmCnLbXVUcmSpTIGP8kOX Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2020 09:27:58 -0000
Ted, 
In your opening email to the 400 highly respectable people on this list you say:
"As it happens, there are very few registrations in URI.ARPA, so we did not catch it and fix it before now."  

How did you "catch it"? 
Was there a pending registration? 
Is there still a pending registration? 
It would really be bad to try to change the rules while something was pending.

I can't speak for the others but some of them might want to know why after almost 20 years of there being zero problems with RFC3405 it suddenly needs to get "fixed".
From nobody Mon Jul 6 09:10:59 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A1B3A1629 for ; Mon, 6 Jul 2020 09:10:57 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 hxjeVno6b258 for ; Mon, 6 Jul 2020 09:10:56 -0700 (PDT) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 A6AC43A1304 for ; Mon, 6 Jul 2020 09:10:56 -0700 (PDT) Received: by mail-ot1-x333.google.com with SMTP id 72so32071511otc.3 for ; Mon, 06 Jul 2020 09:10:56 -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=VNtBZptxXG+zDVwaVlRxLSuK0LY19qRxf5+qD90ZSy0=; b=kc0jnd89BcZJHveV2kLC25j5Xlmg5QFYR7t3J8+tT13wPTL08RIVyLo73weWQMtR2i dLTsXl+M9i39p051RVEl9ThjPGBuHGRo5obVQjZMs8+yUXr/CvqhAUU9bEjVPRmALPNt hI9k8PRv1asVwuf5UGwn7QiPIsRwtj+Fro9ZgKyGLK+LnANqIi1f94U+h5bebQ63Nxat LrQNbVTeK2dmutzSmvRTjxpEWbjk4E/YJLPbvXTKMjDMk3qwI32Qi8uM24Fqg7mLTakC yesnZHgo+exGdaUjwVp4aiiU7JyYvgT+K7PAP6RRQ35be87o0EdQsDy97rNmdGL5On4l fR4A== 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=VNtBZptxXG+zDVwaVlRxLSuK0LY19qRxf5+qD90ZSy0=; b=liPEr+VoO8LQ5YLYLVn0ZgpgDgu/j7Jr5bUjx0ySEC3P2NrFUCYPW0njejx4NHMMDZ F6MVDwwvdNpHy1uIVS8rxGcye0upiu+UGS+6FF0rSceWLUrLIfCZ+uwXEJd3BCBKkb8p mLbai1AqLyvsbCirvYCcfRRBVLsfwYQLPYFJc4kndhBTJBA4Ak43W3yTshftd+XIyIMr 5FLyxy+t4qkrGYi3q88/n1hk1pGXh6jzrC8StMl2sn1o179ajGT1kggV+X3a24l0os4V 5C7jkkoHIJFIWv48IICPZhyl1XA8ySvQk6djpSDlDrVLcXcMMMFIL3wRW0ebcnLZW8O6 ggRg== X-Gm-Message-State: AOAM532u//ltT9v8BJu2ARYN2AHGMpAKdJprPfy3tDrS9fDXH/aHjuJ4 nq+/3TnhHAnexzMxgKDwr/9nYcFTXJWg+zkoQik= X-Google-Smtp-Source: ABdhPJwRKrk/aB0Kz5qubWlGLttEMA2ilzSD76tORoug/LQEQhnmHQPOvVPSec4FXiDxn1FK5rCxg7uMJG5Qbjhvwbk= X-Received: by 2002:a9d:3f66:: with SMTP id m93mr21988957otc.49.1594051855837; Mon, 06 Jul 2020 09:10:55 -0700 (PDT) MIME-Version: 1.0 References: <1425839401.61842.1593845948843@email.ionos.com> In-Reply-To: <1425839401.61842.1593845948843@email.ionos.com> From: Ted Hardie Date: Mon, 6 Jul 2020 09:10:29 -0700 Message-ID: To: Timothy Mcsweeney Cc: Dispatch WG , "Murray S. Kucherawy" , Barry Leiba Content-Type: multipart/alternative; boundary="0000000000009eeef405a9c81e81" Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 16:10:58 -0000 --0000000000009eeef405a9c81e81 Content-Type: text/plain; charset="UTF-8" On Fri, Jul 3, 2020 at 11:59 PM Timothy Mcsweeney wrote: > > I'm hoping for a quick dispatch of this, but happy to discuss. > > > What's the hurry Ted? > > Sorry if this is not clear, but DISPATCH just works out what the process is for discussion of the draft; a "quick dispatch" doesn't mean to end the discuss prematurely, it just means a quick decision on *where* to talk about it. regards, Ted > I know you know your stuff but this draft seems somewhat "corrupted" > In your introduction you're talking about registering scheme "NAMES" > and then state "..there is no way in the current process set out in BCP 35 > [RFC7595] to meet the requirement." ?? > Section 5 of RFC3405 has nothing to do with that. > Maybe it's BCP 35 [RFC7595] that needs the update. But hey, at least we > both agree that uri.arpa registrations don't currently require permanent > status. > --0000000000009eeef405a9c81e81 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jul 3, 2020 at 11:59 PM Timothy M= csweeney <tim@dropnumber.com&g= t; wrote:
=20 =20 =20
> I'm hoping for a quick dispatch of this, but happy to discuss.


What's the hurry Ted?


Sorry if thi= s is not clear, but DISPATCH just works out what the process is for discuss= ion of the draft; a "quick dispatch" doesn't mean to end the = discuss prematurely, it just means a quick decision on *where* to talk abou= t it.

regards,

Ted
=C2=A0
=
I know you know your stuff but this draft seems somewhat "corrupte= d"
In your introduction you're talking about registering scheme &q= uot;NAMES"
and then state "..there is no way in the current process set o= ut in BCP 35 [RFC7595] to meet the requirement." ??
Section 5 of RFC3405 has nothing to do with that.
Maybe it's BCP 35 [RFC7595] that needs the update. But hey, at = least we
both agree that uri.arpa registrations don't currently require = permanent
status.
=20
--0000000000009eeef405a9c81e81-- From nobody Mon Jul 6 09:16:27 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90CF53A16E4 for ; Mon, 6 Jul 2020 09:16:25 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 vtbX0hlHAKWw for ; Mon, 6 Jul 2020 09:16:24 -0700 (PDT) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (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 1A7EC3A1701 for ; Mon, 6 Jul 2020 09:15:59 -0700 (PDT) Received: by mail-oi1-x233.google.com with SMTP id k6so28553870oij.11 for ; Mon, 06 Jul 2020 09:15:59 -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=ulUJPWLHgVV/LfMhHoW0J/H/r4paXeFweO5ahDg4u20=; b=UDWeWnMDh4gryMNrn6MV6HXrF4kqCRAjwA78Fez461nbjMPZhDL+fy+7ZYaIUYGZVf cwCBXOcOrlrJj24QHcs2+v6vDkMgqztsl8XnoAfO2cw6s9cClJTufjReoyWbvl2GZyp3 nAzZmNa9CqZz5Y+9ulEmHoWunP6DwN5l0ksHsDV24zZi6CBSbYZzBygKk6cA2rC/2a9n BvJrD34QbRh6SyDfIqAmGDlCm33oMpcGCjqS2Ji9jWhmNWg1y9BS+cbOSW5MfTI4NtR4 TRHQbRuu8UC6XGkMBpheT611Ev4fJmrIk9wUTIPoC6AUK341lyY3zAWjhYlNwJCdPGES QHDw== 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=ulUJPWLHgVV/LfMhHoW0J/H/r4paXeFweO5ahDg4u20=; b=Odvt3TvTkZXquKu62Q8739NCkogWrid1zzUf8w07gGW6fF8irJtRxhv5oEsesfomQj 1dxHC6O3hRmZ8oW1Y3UFyQo8CYC9bcBS4U6AY6cxadkfs2jevpuYZlAh0z57o9yy++oQ H/w+Fqu0mkxqPgweqGFFaLAHNAEq2OLVEbeQYMbSL5W8ZjRbi4N2anjysS45O2tTfrUs EWl30rwUabiXJXrflEtr6t+SPtLadOglxLJIAQ8Gz1lEFkn5TwavPS1bE9OXcbTZn9wZ HFxngAFjXkJ8sLoO+dpkrSIb86vrdr082up3ic/UyivkbmSuhY6/h+dfw1jQ1mh9dgBi BZlg== X-Gm-Message-State: AOAM533u0UklSl8qQ/s5cU3YYTUDLg4GouUZKu5qWV3Y51FHwi6/fBuH jR9yDMDqWmiPaM9AzvFX3+ihjDtxyGmmOAi2Z94= X-Google-Smtp-Source: ABdhPJwz5xZfM9e6DIs9dzOikwzSIwV6dHa1gs8UEjAIiC4xCs0X1gdOshYUw23+iKnvPWT4E0UJPk1PlUeXW2V6yOU= X-Received: by 2002:a05:6808:9aa:: with SMTP id e10mr23813oig.74.1594052158415; Mon, 06 Jul 2020 09:15:58 -0700 (PDT) MIME-Version: 1.0 References: <1007260719.140376.1593854488478@email.ionos.com> In-Reply-To: <1007260719.140376.1593854488478@email.ionos.com> From: Ted Hardie Date: Mon, 6 Jul 2020 09:15:32 -0700 Message-ID: To: Timothy Mcsweeney Cc: DISPATCH WG , "Murray S. Kucherawy" , Barry Leiba Content-Type: multipart/alternative; boundary="000000000000a7e87605a9c8300f" Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 16:16:26 -0000 --000000000000a7e87605a9c8300f Content-Type: text/plain; charset="UTF-8" Howdy, On Sat, Jul 4, 2020 at 2:28 AM Timothy Mcsweeney wrote: > Ted, > In your opening email to the 400 highly respectable people on this list > you say: > "As it happens, there are very few registrations in URI.ARPA, so we did > not catch it and fix it before now." > > How did you "catch it"? > Was there a pending registration? > Is there still a pending registration? > Yes, this came up because of a proposed registration. Since it was yours, perhaps you would like to provide the link to the group? It would really be bad to try to change the rules while something was > pending. > > The current rules cannot work because they reference a category that no longer exists. To put this differently, if they don't change, there can be no more registrations in URI.arpa. Once DISPATCH decides where this ought to be discussed, we can discuss that outcome or the update to BCP 35 to restore the category as alternatives. regards, Ted Hardie > I can't speak for the others but some of them might want to know why after > almost 20 years of there being zero problems with RFC3405 it suddenly needs > to get "fixed". > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --000000000000a7e87605a9c8300f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy,

On Sat, Jul 4, 2020 at 2:28 AM Timothy Mcsw= eeney <tim@dropnumber.com> = wrote:
=20 =20 =20
Ted,=C2=A0
In your opening email to the 400 highly respectable people on this list = you say:
"As it happens, there are very few registrations in URI.ARPA, so we= did not catch it and fix it before now."=C2=A0=C2=A0

How did you "catch it"?=C2=A0=20
Was there a pending registration?=C2=A0=20
Is there still a pending registration?=C2=A0=20

Yes, this came up because of= a proposed registration.=C2=A0 Since it was yours, perhaps you would like = to provide the link to the group?

It would really be bad to try to change the rules while=C2=A0something w= as pending.


The current rules canno= t work because they reference a category that no longer exists. To put this= differently, if they don't change, there can be no more registrations = in URI.arpa.=C2=A0

Once DISPATCH decides wher= e this ought to be discussed, we can discuss that outcome or the update to = BCP 35 to restore the category as alternatives.

re= gards,

Ted Hardie

=C2= =A0
I can't speak for the others but some of them might want to know why= after almost 20 years of there being zero problems with RFC3405 it suddenl= y needs to get "fixed".
=20
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--000000000000a7e87605a9c8300f-- From nobody Mon Jul 6 11:26:41 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C82033A07AC for ; Mon, 6 Jul 2020 11:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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 nshe2jkKJrHx for ; Mon, 6 Jul 2020 11:26:38 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (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 6F7283A07AB for ; Mon, 6 Jul 2020 11:26:38 -0700 (PDT) Received: from oxuslxaltgw02.schlund.de ([10.72.76.58]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MIcHO-1juhgA3x96-002D9a; Mon, 06 Jul 2020 20:26:34 +0200 Date: Mon, 6 Jul 2020 14:26:34 -0400 (EDT) From: Timothy Mcsweeney Reply-To: Timothy Mcsweeney To: Ted Hardie Cc: DISPATCH WG , "Murray S. Kucherawy" , Barry Leiba Message-ID: <22863747.195824.1594059994823@email.ionos.com> In-Reply-To: References: <1007260719.140376.1593854488478@email.ionos.com> MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.1-Rev31 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:P1Wk1uCutaCr47zLkMfh6Q663274uxCaVGO7AAQQw3a5kVrwM8u H3Vp19smwH9t7rXebvwUnDHvbpKeg+ovNUQyUGHZTSu7UHp1tnlr92IYIiD7UyROwPkBLIx Oe1MYqkr1weOKIHaRdNXib75HWospW/amjvRJWJKXtpGCXPdyyh9gVfjCNQ2sdSbhT4Vffs fMfxmNr7XrRy6P5ZmT+lQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:Ss+7mnD+oQQ=:XTm7NbD46Kopwf6RcC0mvD osi06B+8AF2jor3xCz/iGw+uSdYbQVAh0Ar9tiWObgct+MNBxbHyQdgaP3mzDCoTq/Y2yB6fn 7UVb6N3vuifNYo4BdG9TkymqqQyFtiG6E9KOXnrliYV/mfDetxhFDsxplCkL4h2QaywPPGvmB BtbCZNc6IyGocgjNx6eOXI6UgbIjSAJgneE6UlXErfq8CkaQdqlUOo5HY95DAadHpYK7o9GaH LQQOPh059lbsr5STMQyNwAOmOATTAVHWIbpR44aYIlEOwr1LClqMs3DWvkPXhtez7/LQb5z2H 9jevfJfdxkiFRWppM6sbgRnRHO3qKHpD3LBQL3kve3W3mpxp1/slLdm+7E+B4WdrFqjbCG6ao YSm5xFOQvGnL1eAj1HjHh54EWIJEQVZFj9gOdEtPTEGU4gYmbWRSJVaycH6MYs5ylUz3y4ma1 YnzKWYuib0ctpcqUD/95KI/lj4q2r3vIc1NKSOVN8rRWhXq5DTUXD6FjuXQyOd/IiavEbjtZB PYDjABT1xo4mnQ5AaLZuVNi+jQrHY380C6bMDID4HGkcirdJA3M6kA3207s1h5e+DaR+h69MF KoHtUc5UoJbDzD86qelcvha+bpqfQOzZrG7QPICSi6oOaGEhiT9o1q7DymmAI9BefK+XQcUFX xRBQlHxjeXX0FMSZnXu39LDrTs+awYyM9FRU8wu0NfSPHTwLYFnYgIcokZDckDCioUMOeU5ET g5Kg8gmDKkLSNMZThK2TPPJpgaChdkbSjWybnM7Uz1i+WXuYLOjbHwZVaKlPTZmb0KI/9L99p KvJDKq5AXoZUgnGutYDMAuuQ3KOiKKVk9A7i1jQNGDjCumK81TVWX0IF1Fnqwzmq4m0SFdQ Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 18:26:40 -0000
Ted, 
>
>Yes, this came up because of a proposed registration. Since it was yours,
>perhaps you would like to provide the link to the group?

There is already a mailing list for that.


>Once DISPATCH decides where this ought to be discussed, we can discuss that
>outcome or the update to BCP 35 to restore the category as alternatives.


There should not be a discussion at all. 
1.  Section 5 of RFC3405 isn't broken.  Maybe you were confusing it with
     Section 5 or RFC4395? 
2. Regardless, any discussions should really wait until after upcoming
registrations or appeals of those registrations, or appeals of those appeals are
completed.


>The current rules cannot work because they reference a category that no
>longer exists. To put this differently, if they don't change, there can be
>no more registrations in URI.arpa.


The current rules are working just fine. 
HTTP, among others, are still in the uri.arpa zone proving that the RFC3405
Section 3.1.1 reference [10] lives on through the obsoleted RFCs to the current
spec and can be seen in totality in IANA's list of URIs.




On July 6, 2020 at 12:15 PM Ted Hardie <ted.ietf@gmail.com> wrote:

Howdy,

On Sat, Jul 4, 2020 at 2:28 AM Timothy Mcsweeney < tim@dropnumber.com> wrote:
Ted, 
In your opening email to the 400 highly respectable people on this list you say:
"As it happens, there are very few registrations in URI.ARPA, so we did not catch it and fix it before now."  

How did you "catch it"? 
Was there a pending registration? 
Is there still a pending registration? 

Yes, this came up because of a proposed registration.  Since it was yours, perhaps you would like to provide the link to the group?

It would really be bad to try to change the rules while something was pending.


The current rules cannot work because they reference a category that no longer exists. To put this differently, if they don't change, there can be no more registrations in URI.arpa. 

Once DISPATCH decides where this ought to be discussed, we can discuss that outcome or the update to BCP 35 to restore the category as alternatives.

regards,

Ted Hardie



I can't speak for the others but some of them might want to know why after almost 20 years of there being zero problems with RFC3405 it suddenly needs to get "fixed".
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

 
From nobody Mon Jul 6 11:51:54 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB9F3A08E3 for ; Mon, 6 Jul 2020 11:51:52 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 c6RO3xVQF5vt for ; Mon, 6 Jul 2020 11:51:50 -0700 (PDT) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 CAF8B3A0923 for ; Mon, 6 Jul 2020 11:51:40 -0700 (PDT) Received: by mail-ot1-x333.google.com with SMTP id c25so14829340otf.7 for ; Mon, 06 Jul 2020 11:51:40 -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=3VQL/vZ3PZKF79Gr2Eoiya1GWPK2SwhBKOryec48XGs=; b=e/8e72oOvKdwO6h85F/ZjTlw/cSdDF9tnsO5dTunk0dsDFP/HxeW771QCdjgypBnZc xQyamMy1KO+MK+EOkI2GqraqpAY3nRb/nsI4sxcggbrKHeNdm2X2iNNFAkQevQQnqEa2 un9gSlKElmExi20tGgOCJYpzM9nn5Qzv+QMKnjwR4ZN4LZEi7Fm43Olq33WYMv6jiju0 dEVnfSN1n6RJubd1cbwb9gTCsXH6dCdib0v5QtByWIwJV+1shxubrVhW5uRD8OzLngKp ciepEoVMhIpRfc+BGD/I/07OoMeY4TpOTwm9SfOU21/qlmYsw+S/Oz5VmnHqQhfM5iA/ QAtA== 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=3VQL/vZ3PZKF79Gr2Eoiya1GWPK2SwhBKOryec48XGs=; b=R2y7OTQUX+eTQ73RS49jxJHmkfrD9hGkW8CJsnRG3WOhToz1FrjHjePfdnS8LOPDje 8czrfr7hFQrWxWDoW6LJds1oT3LPe3mFonIMQ5TSGl/34khTJqTbHLZoN1a9I0u7k7GA HlOESHDl+LdZVydsK+DmRQSR6oWdKjCgyqkJAqdw0/+RlKIJvNHjGfpRV5tbleGFOvG5 OUZnubahRJ346Kv8kc0bILIlVosw2DpXpj5BgXwizSdDlpg5aCd5EwBG3XonONd1phQO PzH7x4RVR051rL8NKKNPvd3g6+ifH2g6pX9cnNfGdirT/hLxF6Ax15rn3MskSocR2/Py 2xNg== X-Gm-Message-State: AOAM53094fSrLEFU5DWW+586zr+2G+miiuu8NQc78WvjDGrcy1gI9CjL YAEGnO6yocAH5mhK+aG+I/2xTr09JR76TSIl/xE= X-Google-Smtp-Source: ABdhPJxOPKqCCZB8F19t5gMZze1CHphaD6xzJTYq5nA88NWXiGzn+wdZhkJiQih0m8lTWTh1vCs7N5xAXuPb98AhAcI= X-Received: by 2002:a9d:3f66:: with SMTP id m93mr22611424otc.49.1594061500009; Mon, 06 Jul 2020 11:51:40 -0700 (PDT) MIME-Version: 1.0 References: <1007260719.140376.1593854488478@email.ionos.com> <22863747.195824.1594059994823@email.ionos.com> In-Reply-To: <22863747.195824.1594059994823@email.ionos.com> From: Ted Hardie Date: Mon, 6 Jul 2020 11:51:13 -0700 Message-ID: To: Timothy Mcsweeney Cc: DISPATCH WG , "Murray S. Kucherawy" , Barry Leiba Content-Type: multipart/alternative; boundary="00000000000075504d05a9ca5dad" Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 18:51:53 -0000 --00000000000075504d05a9ca5dad Content-Type: text/plain; charset="UTF-8" Howdy, On Mon, Jul 6, 2020 at 11:26 AM Timothy Mcsweeney wrote: > Ted, > > > >Yes, this came up because of a proposed registration. Since it was yours, > >perhaps you would like to provide the link to the group? > > There is already a mailing list for that. > > > >Once DISPATCH decides where this ought to be discussed, we can discuss > that > >outcome or the update to BCP 35 to restore the category as alternatives. > > > There should not be a discussion at all. > 1. Section 5 of RFC3405 isn't broken. Maybe you were confusing it with > Section 5 or RFC4395? > As I note in the extremely short document: The document requires that registrations be in the "IETF tree" of URI registrations. The use of URI scheme name trees was defined in RFC 2717 [RFC2717] but discontinued by RFC 4395 [RFC4395]. Since the use of trees was discontinued, there is no way in the current process set out in BCP 35 [RFC7595] to meet the requirement. If we leave things as they are, no registrations can be made, because the category is gone. We can change it to require permanent registrations instead (as this document suggests) or you could propose something different (e.g. updating BCP 35 to recreate the IETF tree for these registrations). > 2. Regardless, any discussions should really wait until after upcoming > registrations or appeals of those registrations, or appeals of those > appeals are > completed. > > > >The current rules cannot work because they reference a category that no > >longer exists. To put this differently, if they don't change, there can > be > >no more registrations in URI.arpa. > > > The current rules are working just fine. > HTTP, among others, are still in the uri.arpa zone proving that the > RFC3405 > Section 3.1.1 reference [10] lives on through the obsoleted RFCs to the > current > spec and can be seen in totality in IANA's list of URIs. > > > If I understand you correctly, you are arguing that because URI.arpa was not depopulated when the IETF tree was dropped, registrations can still be made according to the old rules as if there still were an IETF tree. That's not how the IETF process treats obsoleting BCPs; see the IESG statement at https://www.ietf.org/about/groups/iesg/statements/designating-rfcs-historic-2014-07-20/ . This situation has pointed out that there was a bug introduced by RFC 4395 that was carried forward into RFC 7595, because they did not address the dependency on the removed IETF tree in BCP 65. This document is one way to address that bug. If you wish to suggest others, that's fine, but we still need DISPATCH to identify where the discussion should happen. regards, Ted > > On July 6, 2020 at 12:15 PM Ted Hardie wrote: > > Howdy, > > On Sat, Jul 4, 2020 at 2:28 AM Timothy Mcsweeney < tim@dropnumber.com> > wrote: > > Ted, > In your opening email to the 400 highly respectable people on this list > you say: > "As it happens, there are very few registrations in URI.ARPA, so we did > not catch it and fix it before now." > > How did you "catch it"? > Was there a pending registration? > Is there still a pending registration? > > > Yes, this came up because of a proposed registration. Since it was yours, > perhaps you would like to provide the link to the group? > > It would really be bad to try to change the rules while something was > pending. > > > The current rules cannot work because they reference a category that no > longer exists. To put this differently, if they don't change, there can be > no more registrations in URI.arpa. > > Once DISPATCH decides where this ought to be discussed, we can discuss > that outcome or the update to BCP 35 to restore the category as > alternatives. > > regards, > > Ted Hardie > > > > I can't speak for the others but some of them might want to know why after > almost 20 years of there being zero problems with RFC3405 it suddenly needs > to get "fixed". > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > --00000000000075504d05a9ca5dad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy,

On Mon, Jul 6, 2020 at 11:26 AM= Timothy Mcsweeney <tim@dropnumber= .com> wrote:
=20 =20 =20
Ted,=C2=A0
>
>Yes, this came up because of a proposed registration. Since it= was yours,
>perhaps you would like to provide the link to the group?

There is already a mailing list for that.


>Once DISPATCH decides where this ought to be discussed, we can= discuss that
>outcome or the update to BCP 35 to restore the category as alt= ernatives.


There should not be a discussion at all.=C2=A0
1.=C2=A0 Section 5 of RFC3405 isn't broken.=C2=A0 Maybe you we= re confusing it with
=C2=A0 =C2=A0 =C2=A0Section 5 or RFC4395?=C2=A0

As I note= in the extremely short document:

   The docu=
ment requires that registrations be in the "IETF
   tree" of URI registrations.  The use of URI scheme name trees was
   defined in RFC 2717 [RFC2717] but discontinued by RFC 4395 [RFC4395].
   Since the use of trees was discontinued, there is no way in the
   current process set out in BCP 35 [RFC7595] to meet the requirement.

If we leave things as they are, no registration= s can be made, because the category is gone.=C2=A0 We can change it to requ= ire permanent registrations instead (as this document suggests) or you coul= d propose something different (e.g. updating BCP 35 to recreate the IETF tr= ee for these registrations).
=C2=A0
2. Regardless, any discussion= s should really wait until after upcoming
registrations or appeals of those registrations, or appeals of tho= se appeals are
completed.


>The current rules cannot work because they reference a categor= y that no
>longer exists. To put this differently, if they don't chan= ge, there can be
>no more registrations in URI.arpa.


The current rules are working just fine.=C2=A0
HTTP, among others, are still in the uri.arpa zone proving that th= e RFC3405
Section 3.1.1 reference [10] lives on through the obsoleted RFCs t= o the current
spec and can be=C2=A0seen in totality in IANA's list of URIs.


If I understand you correctly, = you are arguing that because URI.arpa was not depopulated when the IETF tre= e was dropped, registrations can still be made according to the old rules a= s if there still were an IETF tree.=C2=A0

Tha= t's not how the IETF process treats obsoleting BCPs; see the IESG state= ment at https://www.ietf.org/about/groups/iesg/sta= tements/designating-rfcs-historic-2014-07-20/.

This situation has point= ed out that there was a bug introduced by RFC 4395 that was carried forward= into RFC 7595, because they did not address the dependency on the removed = IETF tree in BCP 65.=C2=A0 This document is one way to address that bug.=C2= =A0 If you wish to suggest others, that's fine, but we still need DISPA= TCH to identify where the discussion should happen.=C2=A0

regards,

Ted



On July 6, 2020 at 12:15 PM Ted Hardie <ted.ietf@gmail.com> wrote:=20

Howdy,=20

On Sat, Jul 4, 2020 at 2:28 AM Timothy Mcsweeney <=20 tim@dropnumbe= r.com> wrote:=20
Ted,=C2=A0
In your opening email to the 400 highly respectable people on this = list you say:
"As it happens, there are very few registrations in URI.ARPA, = so we did not catch it and fix it before now."=C2=A0=C2=A0

How did you "catch it"?=C2=A0
Was there a pending registration?=C2=A0
Is there still a pending registration?=C2=A0

Yes, this came up because of a proposed registration.=C2=A0 Since it = was yours, perhaps you would like to provide the link to the group?

It would really be bad to try to change the rules while=C2=A0someth= ing was pending.


The current rules cannot work because they reference a category that = no longer exists. To put this differently, if they don't change, there = can be no more registrations in URI.arpa.=C2=A0=20

Once DISPATCH decides where this ought to be discussed, we can discus= s that outcome or the update to BCP 35 to restore the category as alternati= ves.

regards,

Ted Hardie=20



I can't speak for the others but some of them might want to kno= w why after almost 20 years of there being zero problems with RFC3405 it su= ddenly needs to get "fixed".
_______________________________________________=20
dispatch mailing list=20
dispatch@ietf.org=20
https://www.ietf.org/mailman/listinfo/dispatch= =20

=C2=A0
=20
--00000000000075504d05a9ca5dad-- From nobody Mon Jul 6 12:09:32 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 499D73A09C6 for ; Mon, 6 Jul 2020 12:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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 e-fYFCHI-5dH for ; Mon, 6 Jul 2020 12:09:29 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (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 911C63A0925 for ; Mon, 6 Jul 2020 12:09:29 -0700 (PDT) Received: from oxuslxaltgw02.schlund.de ([10.72.76.58]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1MEmlb-1k73Lo1AGx-00GEQt; Mon, 06 Jul 2020 21:09:27 +0200 Date: Mon, 6 Jul 2020 15:09:27 -0400 (EDT) From: Timothy Mcsweeney Reply-To: Timothy Mcsweeney To: Ted Hardie Cc: DISPATCH WG , "Murray S. Kucherawy" , Barry Leiba Message-ID: <1557624035.199224.1594062567206@email.ionos.com> In-Reply-To: References: <1007260719.140376.1593854488478@email.ionos.com> <22863747.195824.1594059994823@email.ionos.com> MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.1-Rev31 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:7baRCVs7jR4q4kprb5ngwPzmnvQpYMaLY4X0HNmjLYU8Z6/fG8n AqyRU/HUyjLZfwmM97hLRw1pZYa/e0srkFfdgUoaLNzeq713M3bCiD9wlBiMkOVSHS3nSLi fx8ojhVACv2FjZBketBuCUHWhgUEcHJi2GyyOsA2cCCUtcTFVVNNynONhtEJwqvn/XJpwln xy53BBscgyCYv9vJDhdzg== X-UI-Out-Filterresults: notjunk:1;V03:K0:4hg3+bbBtHw=:g95joYaKmE8kPA0ok+8JgZ 6pNUZKpvlyLM8k0T5IfbQdCr2xQ73drneKgRfz2ejeNLuwEVobRF3FIT3L6BNQI7mfBMn3vq9 MDf+1noYhayK7a8uvjdUFYaT+VakG594bmPYPRlg0mXuIefRxgckU82LOmb3Il5K+xHGWEEtq WDTbthxCNoxMWZCb3oyzUyb/UEoJJ5qkasUAmuiwgHSlrXnBH13BPgx/755RXjQy4mWlMwQmB 6hqGOlnS/i9mWDZxHSdFptbMJmlT2QlMzCFPlt2MyRpexW+uI0uHWKfduBxTGiCd62CTYnBj/ jCB32se9sYhsd5fyx9hq8NiWCUpjX8iDU37CK0MuE92yu3/ZoH+MzWHydQF6mNn7IoHY7W0Xt grJC68JkFfR5HcPcUmesKf3p0YxO1gqEPwFbfikPIEy73eSQchR7Qt9RRGueCIKZ2dviIhwGf +tSVkrsJfPjoSvoExILlHMcDsAviUfxOwkcEGwL6gFYFgvTWjofy9E3rzP/Q/qBHJ548hu89i JrbVGBm6UY62Dutcyxx+Jpz/++H2A9rIbBvV8FsDWxetuY5IN1sjCvRwvIChDLoFMeWtDUO0C W3+G+6fPD+9L9BEQqJqWKz3wMLDTsU+G6Mejc7/Do3A+HB+6XGhWmk739R5EeY2RXIFnS9Jia IdJVibeHq1AHB8STcY+Y1oSYNlL7B99ZWFUFD4s9piGQX5t8gw6PTC98Yblj9Zn3m6yQrmYS1 A6RlVZOnH5iw7gFLVKSBb3z6sYtivRnFQGr4rX5p6K+graUSyFwQR77kCEYSVuygEE/sUbPZ3 ZJl0+iOVNuKxdHsPme6kIML4k1zW0WcE2QhptkEA0CV/URm43Og3iZbYhDUmYPab5zgSVvW Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 19:09:31 -0000
Hi,
>If I understand you correctly, you are arguing that because URI.arpa was not >depopulated when the IETF tree was dropped, registrations can still be made >according to the old rules as if there still were an IETF tree.


I'm arguing that, as it sits right now, in order to insert a record into uri.arpa, 
you have to have a scheme name registered.  




On July 6, 2020 at 2:51 PM Ted Hardie <ted.ietf@gmail.com> wrote:

Howdy,

On Mon, Jul 6, 2020 at 11:26 AM Timothy Mcsweeney < tim@dropnumber.com> wrote:
Ted, 
>
>Yes, this came up because of a proposed registration. Since it was yours,
>perhaps you would like to provide the link to the group?

There is already a mailing list for that.


>Once DISPATCH decides where this ought to be discussed, we can discuss that
>outcome or the update to BCP 35 to restore the category as alternatives.


There should not be a discussion at all. 
1.  Section 5 of RFC3405 isn't broken.  Maybe you were confusing it with
     Section 5 or RFC4395? 

As I note in the extremely short document:

   The document requires that registrations be in the "IETF
   tree" of URI registrations.  The use of URI scheme name trees was
   defined in RFC 2717 [RFC2717] but discontinued by RFC 4395 [RFC4395].
   Since the use of trees was discontinued, there is no way in the
   current process set out in BCP 35 [RFC7595] to meet the requirement.

If we leave things as they are, no registrations can be made, because the category is gone.  We can change it to require permanent registrations instead (as this document suggests) or you could propose something different (e.g. updating BCP 35 to recreate the IETF tree for these registrations).

2. Regardless, any discussions should really wait until after upcoming
registrations or appeals of those registrations, or appeals of those appeals are
completed.



>The current rules cannot work because they reference a category that no
>longer exists. To put this differently, if they don't change, there can be
>no more registrations in URI.arpa.


The current rules are working just fine. 
HTTP, among others, are still in the uri.arpa zone proving that the RFC3405
Section 3.1.1 reference [10] lives on through the obsoleted RFCs to the current
spec and can be seen in totality in IANA's list of URIs.


If I understand you correctly, you are arguing that because URI.arpa was not depopulated when the IETF tree was dropped, registrations can still be made according to the old rules as if there still were an IETF tree. 

That's not how the IETF process treats obsoleting BCPs; see the IESG statement at https://www.ietf.org/about/groups/iesg/statements/designating-rfcs-historic-2014-07-20/.

This situation has pointed out that there was a bug introduced by RFC 4395 that was carried forward into RFC 7595, because they did not address the dependency on the removed IETF tree in BCP 65.  This document is one way to address that bug.  If you wish to suggest others, that's fine, but we still need DISPATCH to identify where the discussion should happen. 

regards,

Ted




On July 6, 2020 at 12:15 PM Ted Hardie < ted.ietf@gmail.com> wrote:

Howdy,

On Sat, Jul 4, 2020 at 2:28 AM Timothy Mcsweeney < tim@dropnumber.com> wrote:
Ted, 
In your opening email to the 400 highly respectable people on this list you say:
"As it happens, there are very few registrations in URI.ARPA, so we did not catch it and fix it before now."  

How did you "catch it"? 
Was there a pending registration? 
Is there still a pending registration? 

Yes, this came up because of a proposed registration.  Since it was yours, perhaps you would like to provide the link to the group?

It would really be bad to try to change the rules while something was pending.


The current rules cannot work because they reference a category that no longer exists. To put this differently, if they don't change, there can be no more registrations in URI.arpa. 

Once DISPATCH decides where this ought to be discussed, we can discuss that outcome or the update to BCP 35 to restore the category as alternatives.

regards,

Ted Hardie



I can't speak for the others but some of them might want to know why after almost 20 years of there being zero problems with RFC3405 it suddenly needs to get "fixed".
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

 

 
From nobody Mon Jul 6 13:19:48 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCEF33A0A4F for ; Mon, 6 Jul 2020 13:19:46 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 zzFTvbkp_5t4 for ; Mon, 6 Jul 2020 13:19:44 -0700 (PDT) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 487F13A0A4E for ; Mon, 6 Jul 2020 13:19:44 -0700 (PDT) Received: by mail-ot1-x336.google.com with SMTP id n24so30414050otr.13 for ; Mon, 06 Jul 2020 13:19:44 -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=NNtaCfn5qvcyzsj5qE91ozEo2XNdY6IQJRnImop+UJ0=; b=qVcI8M843PIt8vFYj8vpx5xLpGM6Kc2VSXG3MUawUC9snUS1LevIwaqGY+qFWDwlC+ cROxB+G2LMIDRvlXPuBmHPAdLaHu20Ewk8zUG/8WUZM5MmKS285eR92wGotP045wPcCq 8c8jKqRnIwTOTA4+oheqy0BCvKWO9R95LmvwkbIwvX+a3Hx3SFNHFo0R6Cx2ls8BrMno AjztUs12IweRmYfrIqNJwlg1h12/7ADqY2g7EcJDKGeTxzBGpV5G1+isf4aTMSE2DnQW cZpkGrIjZ+uBnY84ECGCH2Ye0PxkLpXDng3zgQbhat0IJSD0HZW6KPTKx9p/wio9F8G4 gVag== 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=NNtaCfn5qvcyzsj5qE91ozEo2XNdY6IQJRnImop+UJ0=; b=aXf772+m6yOHbCh/et+x3DG8/Ao81z+HsQgExbrwxdMtDJgbeL83K7F7tt/ibbzLV5 PQIeG0y/qYWkoH6b7cVBcOrbzix2oLfxhCREIqihf4lg9k58T/FCNq8Zxdll38UPcdCw 8D0Gs9c4F66/5j5WLBNbIt8qBcsfFJjI/A0phETlYabgCLbs3iAQaF/9RV4vf2Sg6SwV yigj6dbCP4ErnpBk58EM1KQH96O/CAups2h4el02hd57eJzSz3yTk78luhi3HJitD52T Vlm4bhTLGbA3CqhD+vjNWHMP61eaHLL07/2rf4PZFvNnPaRn8V7FjGjLhloOK7pTkhE3 fGlg== X-Gm-Message-State: AOAM531llZojsp8tboaQ3IVDoaO/tZgYf9aydf8KnZNWs4V33gPXydmY ls0JKfZUBtJ2QL0A6+8+R2drmdTfD3dxGZPSeLI= X-Google-Smtp-Source: ABdhPJw319g7DDxpMG560D7UAa19RKQ46xkxWiZjxXkYzuQRCYp3JO/Levn8fpxsfrBiToSEQUv3uChxVUJUHrGFiiM= X-Received: by 2002:a9d:3f66:: with SMTP id m93mr22918682otc.49.1594066783455; Mon, 06 Jul 2020 13:19:43 -0700 (PDT) MIME-Version: 1.0 References: <1007260719.140376.1593854488478@email.ionos.com> <22863747.195824.1594059994823@email.ionos.com> <1557624035.199224.1594062567206@email.ionos.com> In-Reply-To: <1557624035.199224.1594062567206@email.ionos.com> From: Ted Hardie Date: Mon, 6 Jul 2020 13:19:16 -0700 Message-ID: To: Timothy Mcsweeney Cc: DISPATCH WG , "Murray S. Kucherawy" , Barry Leiba Content-Type: multipart/alternative; boundary="000000000000604c8f05a9cb9837" Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 20:19:47 -0000 --000000000000604c8f05a9cb9837 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 6, 2020 at 12:09 PM Timothy Mcsweeney wrote: > Hi, > >If I understand you correctly, you are arguing that because URI.arpa was > not >depopulated when the IETF tree was dropped, registrations can still be > made >according to the old rules as if there still were an IETF tree. > > > I'm arguing that, as it sits right now, in order to insert a record into > uri.arpa, > you have to have a scheme name registered. > > RFC 3405 is pretty restrictive in its language: 3.1 URI.ARPA Registration > > 3.1.1 Only Schemes in the IETF Tree Allowed > > In order to be inserted into the URI.ARPA zone, the subsequent URI > scheme MUST be registered under the IETF URI tree. The requirements > for this tree are specified in [10]. > > Given the "Only" and the RFC 2119 "MUST", I don't think a plain reading of the text supports the view that any URI registration is sufficient. Section 3.1.2 also reinforces that the registration must be prior and then the record insertion must pass IESG review; that section does not given the IESG the right to waive the requirements: 3.1.2 Scheme Registration Takes Precedence The registration of a NAPTR record for a URI scheme MUST NOT precede proper registration of that scheme and publication of a stable specification in accordance with [10]. The IESG or its designated expert will review the request for 1. correctness and technical soundness 2. consistency with the published URI specification, and 3. to ensure that the NAPTR record for a DNS-based URI does not delegate resolution of the URI to a party other than the holder of the DNS name. This last rule is to insure that a given URI's resolution hint doesn't hijack (inadvertently or otherwise) network traffic for a given domain. regards, Ted Hardie > > > > On July 6, 2020 at 2:51 PM Ted Hardie wrote: > > Howdy, > > On Mon, Jul 6, 2020 at 11:26 AM Timothy Mcsweeney < tim@dropnumber.com> > wrote: > > Ted, > > > >Yes, this came up because of a proposed registration. Since it was yours, > >perhaps you would like to provide the link to the group? > > There is already a mailing list for that. > > > >Once DISPATCH decides where this ought to be discussed, we can discuss > that > >outcome or the update to BCP 35 to restore the category as alternatives. > > > There should not be a discussion at all. > 1. Section 5 of RFC3405 isn't broken. Maybe you were confusing it with > Section 5 or RFC4395? > > > As I note in the extremely short document: > > The document requires that registrations be in the "IETF > tree" of URI registrations. The use of URI scheme name trees was > defined in RFC 2717 [RFC2717] but discontinued by RFC 4395 [RFC4395]. > Since the use of trees was discontinued, there is no way in the > current process set out in BCP 35 [RFC7595] to meet the requirement. > > > If we leave things as they are, no registrations can be made, because the > category is gone. We can change it to require permanent registrations > instead (as this document suggests) or you could propose something > different (e.g. updating BCP 35 to recreate the IETF tree for these > registrations). > > 2. Regardless, any discussions should really wait until after upcoming > registrations or appeals of those registrations, or appeals of those > appeals are > completed. > > > > >The current rules cannot work because they reference a category that no > >longer exists. To put this differently, if they don't change, there can > be > >no more registrations in URI.arpa. > > > The current rules are working just fine. > HTTP, among others, are still in the uri.arpa zone proving that the > RFC3405 > Section 3.1.1 reference [10] lives on through the obsoleted RFCs to the > current > spec and can be seen in totality in IANA's list of URIs. > > > If I understand you correctly, you are arguing that because URI.arpa was > not depopulated when the IETF tree was dropped, registrations can still be > made according to the old rules as if there still were an IETF tree. > > That's not how the IETF process treats obsoleting BCPs; see the IESG > statement at > https://www.ietf.org/about/groups/iesg/statements/designating-rfcs-historic-2014-07-20/. > > > This situation has pointed out that there was a bug introduced by RFC 4395 > that was carried forward into RFC 7595, because they did not address the > dependency on the removed IETF tree in BCP 65. This document is one way to > address that bug. If you wish to suggest others, that's fine, but we still > need DISPATCH to identify where the discussion should happen. > > regards, > > Ted > > > > > On July 6, 2020 at 12:15 PM Ted Hardie < ted.ietf@gmail.com> wrote: > > Howdy, > > On Sat, Jul 4, 2020 at 2:28 AM Timothy Mcsweeney < tim@dropnumber.com> > wrote: > > Ted, > In your opening email to the 400 highly respectable people on this list > you say: > "As it happens, there are very few registrations in URI.ARPA, so we did > not catch it and fix it before now." > > How did you "catch it"? > Was there a pending registration? > Is there still a pending registration? > > > Yes, this came up because of a proposed registration. Since it was yours, > perhaps you would like to provide the link to the group? > > It would really be bad to try to change the rules while something was > pending. > > > The current rules cannot work because they reference a category that no > longer exists. To put this differently, if they don't change, there can be > no more registrations in URI.arpa. > > Once DISPATCH decides where this ought to be discussed, we can discuss > that outcome or the update to BCP 35 to restore the category as > alternatives. > > regards, > > Ted Hardie > > > > I can't speak for the others but some of them might want to know why after > almost 20 years of there being zero problems with RFC3405 it suddenly needs > to get "fixed". > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > > > > --000000000000604c8f05a9cb9837 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jul 6, 2020 at 12:09 PM Timothy M= csweeney <tim@dropnumber.com&g= t; wrote:
=20 =20 =20
Hi,
>If I understand you correctly, you are arguing that because URI.arpa= was not >depopulated when the IETF tree was dropped, registrations can = still be made >according to the old rules as if there still were an IETF= tree.


I'm arguing that, as it sits right now, in order to insert a record = into uri.arpa,=C2=A0
you have to have a scheme name registered.=C2=A0=C2=A0


RFC 3405 is pretty rest= rictive in its language:

3.1 URI.ARPA Registration

3.1.1 Only Schemes in the IETF Tree Allowed

   In order to be inserted into the URI.ARPA zone, the subsequent URI
   scheme MUST be registered under the IETF URI tree.  The requirements
   for this tree are specified in [10].
Given the "Only" and the RFC 2119 "= MUST", I don't think a plain reading of the text supports the view= that any URI registration is sufficient.=C2=A0=C2=A0 Section 3.1.2 also re= inforces that the registration must be prior and then the record insertion = must pass IESG review; that section does not given the IESG the right to wa= ive the requirements:

3.1.2 Scheme Registration Takes Precedence

   The registration of a NAPTR record for a URI scheme MUST NOT precede
   proper registration of that scheme and publication of a stable
   specification in accordance with [10].  The IESG or its designated
   expert will review the request for

      1.  correctness and technical soundness

      2.  consistency with the published URI specification, and

      3.  to ensure that the NAPTR record for a DNS-based URI does not
          delegate resolution of the URI to a party other than the
          holder of the DNS name.  This last rule is to insure that a
          given URI's resolution hint doesn't hijack (inadvertently=
 or
          otherwise) network traffic for a given domain.
regards,

Ted Hardie
=C2= =A0



On July 6, 2020 at 2:51 PM Ted Hardie <ted.ietf@gmail.com> wrote:=20

Howdy,=20

On Mon, Jul 6, 2020 at 11:26 AM Timothy Mcsweeney <=20 tim@dropnumbe= r.com> wrote:=20
Ted,=C2=A0
>=20
>Yes, this came up because of a proposed registration. Sin= ce it was yours,=20
>perhaps you would like to provide the link to the group?

There is already a mailing list for that.


>Once DISPATCH decides where this ought to be discussed, w= e can discuss that=20
>outcome or the update to BCP 35 to restore the category a= s alternatives.


There should not be a discussion at all.=C2=A0=20
1.=C2=A0 Section 5 of RFC3405 isn't broken.=C2=A0 Maybe y= ou were confusing it with=20
=C2=A0 =C2=A0 =C2=A0Section 5 or RFC4395?=C2=A0=20

As I note in the extremely short document:

   The document requires that registrations be in the "IETF
   tree" of URI registrations.  The use of URI scheme name trees was
   defined in RFC 2717 [RFC2717] but discontinued by RFC 4395 [RFC4395].
   Since the use of trees was discontinued, there is no way in the
   current process set out in BCP 35 [RFC7595] to meet the requirement.
     

If we leave things as they are, no registrations can be made, because= the category is gone.=C2=A0 We can change it to require permanent registra= tions instead (as this document suggests) or you could propose something di= fferent (e.g. updating BCP 35 to recreate the IETF tree for these registrat= ions).

2. Regardless, any discussions should really wait until after upc= oming=20
registrations or appeals of those registrations, or appeals o= f those appeals are=20
completed.



>The current rules cannot work because they reference a ca= tegory that no=20
>longer exists. To put this differently, if they don't= change, there can be=20
>no more registrations in URI.arpa.


The current rules are working just fine.=C2=A0=20
HTTP, among others, are still in the uri.arpa zone proving th= at the RFC3405=20
Section 3.1.1 reference [10] lives on through the obsoleted R= FCs to the current=20
spec and can be=C2=A0seen in totality in IANA's list of U= RIs.=20


If I understand you correctly, you are arguing that because URI.arpa = was not depopulated when the IETF tree was dropped, registrations can still= be made according to the old rules as if there still were an IETF tree.=C2= =A0=20

That's not how the IETF process treats obsoleting BCPs; see the I= ESG statement at=20 https://www.ietf.org/about= /groups/iesg/statements/designating-rfcs-historic-2014-07-20/.

This situation has pointed out that there was a bug introduced by RFC = 4395 that was carried forward into RFC 7595, because they did not address t= he dependency on the removed IETF tree in BCP 65.=C2=A0 This document is on= e way to address that bug.=C2=A0 If you wish to suggest others, that's = fine, but we still need DISPATCH to identify where the discussion should ha= ppen.=C2=A0=20

regards,

Ted=20




On July 6, 2020 at 12:15 PM Ted Hardie <=20 ted.ietf@gmail.com> wrote:=20

Howdy,=20

On Sat, Jul 4, 2020 at 2:28 AM Timothy Mcsweeney <=20 tim@dropnumber.com> wrote:=20
Ted,=C2=A0
In your opening email to the 400 highly respectable people on = this list you say:
"As it happens, there are very few registrations in URI.A= RPA, so we did not catch it and fix it before now."=C2=A0=C2=A0

How did you "catch it"?=C2=A0
Was there a pending registration?=C2=A0
Is there still a pending registration?=C2=A0

Yes, this came up because of a proposed registration.=C2=A0 Sinc= e it was yours, perhaps you would like to provide the link to the group?

It would really be bad to try to change the rules while=C2=A0s= omething was pending.


The current rules cannot work because they reference a category = that no longer exists. To put this differently, if they don't change, t= here can be no more registrations in URI.arpa.=C2=A0=20

Once DISPATCH decides where this ought to be discussed, we can d= iscuss that outcome or the update to BCP 35 to restore the category as alte= rnatives.

regards,

Ted Hardie=20



I can't speak for the others but some of them might want t= o know why after almost 20 years of there being zero problems with RFC3405 = it suddenly needs to get "fixed".
_______________________________________________=20
dispatch mailing list=20
dispatch@ietf.org=20
https://www.ietf.org/mailman/listinfo/dispa= tch=20

=C2=A0

=C2=A0
=20
--000000000000604c8f05a9cb9837-- From nobody Mon Jul 6 13:27:29 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5F93A0A66 for ; Mon, 6 Jul 2020 13:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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 bJbF-20U99Vc for ; Mon, 6 Jul 2020 13:27:27 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (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 BB3F53A0A65 for ; Mon, 6 Jul 2020 13:27:26 -0700 (PDT) Received: from oxuslxaltgw01.schlund.de ([10.72.76.57]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MVNsG-1kQD0m3Fp0-00YmCf; Mon, 06 Jul 2020 22:27:22 +0200 Date: Mon, 6 Jul 2020 16:27:22 -0400 (EDT) From: Timothy Mcsweeney Reply-To: Timothy Mcsweeney To: Ted Hardie Cc: DISPATCH WG , "Murray S. Kucherawy" , Barry Leiba Message-ID: <1990424976.229638.1594067242698@email.ionos.com> In-Reply-To: References: <1007260719.140376.1593854488478@email.ionos.com> <22863747.195824.1594059994823@email.ionos.com> <1557624035.199224.1594062567206@email.ionos.com> MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.1-Rev31 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:5qlarKpKc96i4sDk0719xCfE2oNV0Mi3cGLcJVD3RcFNfwzb/PF USuqo+aTb2lyE2MAEX3c7bjE+BDZGjE+ah5/eCG1ApnbUtCNFrgfo1we+g8S9Kusd35FEtJ 2Y2l97YgIBqekrkI4Hplxnfn38tyZzwx7pR12HHUj5QIbaOKwJRsi8kC299xRnuQpkxWpAk nii7Qu0IYDk11UDxKAXGw== X-UI-Out-Filterresults: notjunk:1;V03:K0:OwKsFb/LTXM=:/yvniz8BgLWgOa4ZQHD0We /AyetsiwlCfgXIe3NnMP/O9AW5x3CrC71SdMzBbtBCqK0AqRmcHVHFre56RAqHEWvrrO49ZX8 DnaT5eqIOxaqRmVwsKw/oum6Tlq3JD3zx65LWnKerFR9qw4dwMrVvqh8NQfx+aun7xtOTrUBu cnfy9y3hVJZUYNvJbppG0d7C2QYgKD6HysVt3ZU1OgoCmb2gzDm/af5EUy50TAF+25vFmKQ8h v1DDPyMSr8Q920GPk+QsU3LTPSsKcvTdU8WHxYF4+odUYO4jAptlmT1C+R9T5PZoToeujYI5j EjZG6LabudZghfIWFx9WRWXNV8MsSbesLLHBLmdmM0fP5dfogrytNqICDImHdSMIgfIcn1DsM 6HAIzyKtYYBhbaV0goLgEVj8cjDlHq2bjp8mc7e0GvAtocylkRheL1sE1DjaIxJKdRu0K0cN+ ZPngdMvu57a11W6yH+/4WrDHvw75KXwfTo5TD5qy5vJe3kmL+KpQGJRDnSeecv6xl7qL9GUle AP4CBG5tmy85uUiRSoK080ZzRYzCtjOk1/v6mG23SRJDkHoLe/5GYAsa6xA/JHEgB0kjjyxIN E7nXP1Gga3qzk1ODjT2KHjYW2bPvrSSEPfbB51Pzqem1VU0gd/KXbArq4doGkEiX/avXVcsKu YXmY/7AlpWP0N/yF+x+b5y8Sdm3OEEc4k3ePfrCR1ZoDejKoTmQJUoOKd6LiMthpTCrKv1pGH 2/JhZo4nf0fLTk6SnidfMVmUoTaQTFbiWlaY9lPMwC/n4OZp+LmPEwWLep7TKcj2JaCNfZSxs u24ztpsOewv7y51SQcP2UEzZL2tI//vrNir8dm1J/0VaqIFWAsABjWDVgF9l+fBA17LosXa Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 20:27:28 -0000
Ted,
Do you not want my scheme in the arpa zone?


On July 6, 2020 at 4:19 PM Ted Hardie <ted.ietf@gmail.com> wrote:

On Mon, Jul 6, 2020 at 12:09 PM Timothy Mcsweeney < tim@dropnumber.com> wrote:
Hi,
>If I understand you correctly, you are arguing that because URI.arpa was not >depopulated when the IETF tree was dropped, registrations can still be made >according to the old rules as if there still were an IETF tree.


I'm arguing that, as it sits right now, in order to insert a record into uri.arpa, 
you have to have a scheme name registered.  


RFC 3405 is pretty restrictive in its language:

3.1 URI.ARPA Registration

3.1.1 Only Schemes in the IETF Tree Allowed

   In order to be inserted into the URI.ARPA zone, the subsequent URI
   scheme MUST be registered under the IETF URI tree.  The requirements
   for this tree are specified in [10].
Given the "Only" and the RFC 2119 "MUST", I don't think a plain reading of the text supports the view that any URI registration is sufficient.   Section 3.1.2 also reinforces that the registration must be prior and then the record insertion must pass IESG review; that section does not given the IESG the right to waive the requirements:

3.1.2 Scheme Registration Takes Precedence

   The registration of a NAPTR record for a URI scheme MUST NOT precede
   proper registration of that scheme and publication of a stable
   specification in accordance with [10].  The IESG or its designated
   expert will review the request for

      1.  correctness and technical soundness

      2.  consistency with the published URI specification, and

      3.  to ensure that the NAPTR record for a DNS-based URI does not
          delegate resolution of the URI to a party other than the
          holder of the DNS name.  This last rule is to insure that a
          given URI's resolution hint doesn't hijack (inadvertently or
          otherwise) network traffic for a given domain.
regards,

Ted Hardie





On July 6, 2020 at 2:51 PM Ted Hardie < ted.ietf@gmail.com> wrote:

Howdy,

On Mon, Jul 6, 2020 at 11:26 AM Timothy Mcsweeney < tim@dropnumber.com> wrote:
Ted, 
>
>Yes, this came up because of a proposed registration. Since it was yours,
>perhaps you would like to provide the link to the group?

There is already a mailing list for that.


>Once DISPATCH decides where this ought to be discussed, we can discuss that
>outcome or the update to BCP 35 to restore the category as alternatives.


There should not be a discussion at all. 
1.  Section 5 of RFC3405 isn't broken.  Maybe you were confusing it with
     Section 5 or RFC4395? 

As I note in the extremely short document:

   The document requires that registrations be in the "IETF
   tree" of URI registrations.  The use of URI scheme name trees was
   defined in RFC 2717 [RFC2717] but discontinued by RFC 4395 [RFC4395].
   Since the use of trees was discontinued, there is no way in the
   current process set out in BCP 35 [RFC7595] to meet the requirement.

If we leave things as they are, no registrations can be made, because the category is gone.  We can change it to require permanent registrations instead (as this document suggests) or you could propose something different (e.g. updating BCP 35 to recreate the IETF tree for these registrations).

2. Regardless, any discussions should really wait until after upcoming
registrations or appeals of those registrations, or appeals of those appeals are
completed.



>The current rules cannot work because they reference a category that no
>longer exists. To put this differently, if they don't change, there can be
>no more registrations in URI.arpa.


The current rules are working just fine. 
HTTP, among others, are still in the uri.arpa zone proving that the RFC3405
Section 3.1.1 reference [10] lives on through the obsoleted RFCs to the current
spec and can be seen in totality in IANA's list of URIs.


If I understand you correctly, you are arguing that because URI.arpa was not depopulated when the IETF tree was dropped, registrations can still be made according to the old rules as if there still were an IETF tree. 

That's not how the IETF process treats obsoleting BCPs; see the IESG statement at https://www.ietf.org/about/groups/iesg/statements/designating-rfcs-historic-2014-07-20/.

This situation has pointed out that there was a bug introduced by RFC 4395 that was carried forward into RFC 7595, because they did not address the dependency on the removed IETF tree in BCP 65.  This document is one way to address that bug.  If you wish to suggest others, that's fine, but we still need DISPATCH to identify where the discussion should happen. 

regards,

Ted




On July 6, 2020 at 12:15 PM Ted Hardie < ted.ietf@gmail.com> wrote:

Howdy,

On Sat, Jul 4, 2020 at 2:28 AM Timothy Mcsweeney < tim@dropnumber.com> wrote:
Ted, 
In your opening email to the 400 highly respectable people on this list you say:
"As it happens, there are very few registrations in URI.ARPA, so we did not catch it and fix it before now."  

How did you "catch it"? 
Was there a pending registration? 
Is there still a pending registration? 

Yes, this came up because of a proposed registration.  Since it was yours, perhaps you would like to provide the link to the group?

It would really be bad to try to change the rules while something was pending.


The current rules cannot work because they reference a category that no longer exists. To put this differently, if they don't change, there can be no more registrations in URI.arpa. 

Once DISPATCH decides where this ought to be discussed, we can discuss that outcome or the update to BCP 35 to restore the category as alternatives.

regards,

Ted Hardie



I can't speak for the others but some of them might want to know why after almost 20 years of there being zero problems with RFC3405 it suddenly needs to get "fixed".
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

 

 

 
From nobody Mon Jul 6 15:14:22 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E3C3A0B5F for ; Mon, 6 Jul 2020 15:14:20 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 UJqfTEpVuFyY for ; Mon, 6 Jul 2020 15:14:18 -0700 (PDT) Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (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 EBEE03A0B80 for ; Mon, 6 Jul 2020 15:14:17 -0700 (PDT) Received: by mail-oi1-x231.google.com with SMTP id t198so20742591oie.7 for ; Mon, 06 Jul 2020 15:14:17 -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=AcGNgFf5v6hfdltiuiIAfLQ9Euh6hCeQJSeHlRh6Hoo=; b=IjTgh2h3jRpzo2rg0N1fTztbI2xkcDLqsYbF1+h3yEIS5w8nxS32ovJoyn7VkjUQP8 nfpTFkK5jeWNlUlaqnuyFYZBzi3qxYUJrW5aS3ZEhTeVffph8q/GJBaGvLFxsku6A3ZF LFRh8JnyxU8/yUBYD8G2ID3bXPuPMAje9NU3YXNBkF2VsV705iywLzt7Yraaahqv7HjR pmG9tyVfns+iGTn5DYNxX7frCp14aBFJHnWXtUKgewNymThzRbJM2+JR9JeoUIkSZAPt +UHEI+lQfIJB9RqgfH4oKqVhiliV32d5dZJW7rz0UQXvMniWjYzO1xsoKMsIA8Ab3lbk Yr7w== 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=AcGNgFf5v6hfdltiuiIAfLQ9Euh6hCeQJSeHlRh6Hoo=; b=dkCYimTgTfw7ghkN2nKmjoX7UBCHHD/l5MXU9Tac9OXiuIbwaEICfnyBYMs/MAS5ky 0Mt1NVBcmt90hN4OHmcy8MY8xgjdEvqxpLGe0JuNM7RepyUTbsQ9J6CpLbQyMkpWRbOK qoDR4QwbYtvZF8ZFN9uw/v4RQB34jcbBs/ItdHkev5/CthS4tUxsEe4mJ9oQYzgq8w7r vDDFeij/wYm6l6Tq23wT+RADIlN6stexb7EdkcKxiDbsJ7K+OV5lWn+YvUpHFl1KiBy4 5UG0CCjt9PRqD6BSGL1Xn0/9P3Vzrq7EsAOfl8DUt5tBA7sPLok0klVqR6ZkOaOyO7Wl 1S8g== X-Gm-Message-State: AOAM531xP/eJnJJAtp6KIzgo78zqIRp48vOhNNIanNZ18YOkzSkqV9z8 X2BM8HfA2p1d3wzGW99UcylWLfvTrvO5OzACD04= X-Google-Smtp-Source: ABdhPJwixOTf/NV+aYYUwMllw3Okr2enoPey122DVX5QkVrCMlQe20vbmABOiofuIU12ZnF96FuTg2xQuZccTeSpRso= X-Received: by 2002:aca:445:: with SMTP id 66mr1114658oie.35.1594073656914; Mon, 06 Jul 2020 15:14:16 -0700 (PDT) MIME-Version: 1.0 References: <1007260719.140376.1593854488478@email.ionos.com> <22863747.195824.1594059994823@email.ionos.com> <1557624035.199224.1594062567206@email.ionos.com> <1990424976.229638.1594067242698@email.ionos.com> In-Reply-To: <1990424976.229638.1594067242698@email.ionos.com> From: Ted Hardie Date: Mon, 6 Jul 2020 15:13:50 -0700 Message-ID: To: Timothy Mcsweeney Cc: DISPATCH WG , "Murray S. Kucherawy" , Barry Leiba Content-Type: multipart/alternative; boundary="0000000000001119de05a9cd320e" Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 22:14:20 -0000 --0000000000001119de05a9cd320e Content-Type: text/plain; charset="UTF-8" Howdy, On Mon, Jul 6, 2020 at 1:27 PM Timothy Mcsweeney wrote: > Ted, > Do you not want my scheme in the arpa zone? > > I'm just trying to avoid a silly state, where we say do X but don't let anyone do X. If this is published, then we'll have a clear rule that matches the current system. But if the consensus turns out to be that the IETF tree should return for the sole purpose of registering schemes going into .arpa, I would go along with that as well. I don't support allowing provisionals in the zone because they are first-come-first-served as of RFC 7595 and some of the registrations are very vendor specific (for example, many of the ms- uri schemes in the provisional category at https://www.iana.org/assignments/uri-schemes/uri-schemes.xml are Microsoft-only). That's not in-line with the purpose of .arpa as an infrastructure domain. If you disagree, please write up your proposal. I trust DISPATCH will ensure that it gets discussed in the same place as this proposal. regards, Ted > On July 6, 2020 at 4:19 PM Ted Hardie wrote: > > On Mon, Jul 6, 2020 at 12:09 PM Timothy Mcsweeney < tim@dropnumber.com> > wrote: > > Hi, > >If I understand you correctly, you are arguing that because URI.arpa was > not >depopulated when the IETF tree was dropped, registrations can still be > made >according to the old rules as if there still were an IETF tree. > > > I'm arguing that, as it sits right now, in order to insert a record into > uri.arpa, > you have to have a scheme name registered. > > > RFC 3405 is pretty restrictive in its language: > > 3.1 URI.ARPA Registration > > 3.1.1 Only Schemes in the IETF Tree Allowed > > In order to be inserted into the URI.ARPA zone, the subsequent URI > scheme MUST be registered under the IETF URI tree. The requirements > for this tree are specified in [10]. > > Given the "Only" and the RFC 2119 "MUST", I don't think a plain reading of > the text supports the view that any URI registration is sufficient. > Section 3.1.2 also reinforces that the registration must be prior and then > the record insertion must pass IESG review; that section does not given the > IESG the right to waive the requirements: > > 3.1.2 Scheme Registration Takes Precedence > > The registration of a NAPTR record for a URI scheme MUST NOT precede > proper registration of that scheme and publication of a stable > specification in accordance with [10]. The IESG or its designated > expert will review the request for > > 1. correctness and technical soundness > > 2. consistency with the published URI specification, and > > 3. to ensure that the NAPTR record for a DNS-based URI does not > delegate resolution of the URI to a party other than the > holder of the DNS name. This last rule is to insure that a > given URI's resolution hint doesn't hijack (inadvertently or > otherwise) network traffic for a given domain. > > regards, > > Ted Hardie > > > > > > On July 6, 2020 at 2:51 PM Ted Hardie < ted.ietf@gmail.com> wrote: > > Howdy, > > On Mon, Jul 6, 2020 at 11:26 AM Timothy Mcsweeney < tim@dropnumber.com> > wrote: > > Ted, > > > >Yes, this came up because of a proposed registration. Since it was yours, > >perhaps you would like to provide the link to the group? > > There is already a mailing list for that. > > > >Once DISPATCH decides where this ought to be discussed, we can discuss > that > >outcome or the update to BCP 35 to restore the category as alternatives. > > > There should not be a discussion at all. > 1. Section 5 of RFC3405 isn't broken. Maybe you were confusing it with > Section 5 or RFC4395? > > > As I note in the extremely short document: > > The document requires that registrations be in the "IETF > tree" of URI registrations. The use of URI scheme name trees was > defined in RFC 2717 [RFC2717] but discontinued by RFC 4395 [RFC4395]. > Since the use of trees was discontinued, there is no way in the > current process set out in BCP 35 [RFC7595] to meet the requirement. > > > If we leave things as they are, no registrations can be made, because the > category is gone. We can change it to require permanent registrations > instead (as this document suggests) or you could propose something > different (e.g. updating BCP 35 to recreate the IETF tree for these > registrations). > > 2. Regardless, any discussions should really wait until after upcoming > registrations or appeals of those registrations, or appeals of those > appeals are > completed. > > > > >The current rules cannot work because they reference a category that no > >longer exists. To put this differently, if they don't change, there can > be > >no more registrations in URI.arpa. > > > The current rules are working just fine. > HTTP, among others, are still in the uri.arpa zone proving that the > RFC3405 > Section 3.1.1 reference [10] lives on through the obsoleted RFCs to the > current > spec and can be seen in totality in IANA's list of URIs. > > > If I understand you correctly, you are arguing that because URI.arpa was > not depopulated when the IETF tree was dropped, registrations can still be > made according to the old rules as if there still were an IETF tree. > > That's not how the IETF process treats obsoleting BCPs; see the IESG > statement at > https://www.ietf.org/about/groups/iesg/statements/designating-rfcs-historic-2014-07-20/. > > > This situation has pointed out that there was a bug introduced by RFC 4395 > that was carried forward into RFC 7595, because they did not address the > dependency on the removed IETF tree in BCP 65. This document is one way to > address that bug. If you wish to suggest others, that's fine, but we still > need DISPATCH to identify where the discussion should happen. > > regards, > > Ted > > > > > On July 6, 2020 at 12:15 PM Ted Hardie < ted.ietf@gmail.com> wrote: > > Howdy, > > On Sat, Jul 4, 2020 at 2:28 AM Timothy Mcsweeney < tim@dropnumber.com> > wrote: > > Ted, > In your opening email to the 400 highly respectable people on this list > you say: > "As it happens, there are very few registrations in URI.ARPA, so we did > not catch it and fix it before now." > > How did you "catch it"? > Was there a pending registration? > Is there still a pending registration? > > > Yes, this came up because of a proposed registration. Since it was yours, > perhaps you would like to provide the link to the group? > > It would really be bad to try to change the rules while something was > pending. > > > The current rules cannot work because they reference a category that no > longer exists. To put this differently, if they don't change, there can be > no more registrations in URI.arpa. > > Once DISPATCH decides where this ought to be discussed, we can discuss > that outcome or the update to BCP 35 to restore the category as > alternatives. > > regards, > > Ted Hardie > > > > I can't speak for the others but some of them might want to know why after > almost 20 years of there being zero problems with RFC3405 it suddenly needs > to get "fixed". > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > > > > > > > --0000000000001119de05a9cd320e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy,

On Mon, Jul 6, 2020 at 1:27 PM Timothy Mcsw= eeney <tim@dropnumber.com> = wrote:
=20 =20 =20
Ted,=20
Do you not want my scheme in the arpa zone?


I'm just trying to = avoid a silly state, where we say do X but don't let anyone do X.=C2=A0= If this is published, then we'll have a clear rule that matches the cu= rrent system.=C2=A0 But if the consensus turns out to be that the IETF tree= should return for the sole purpose of registering schemes going into .arpa= , I would go along with that as well.=C2=A0

I= don't support allowing provisionals in the zone because they are first= -come-first-served as of RFC 7595 and some of the registrations are very ve= ndor specific (for example, many of the ms- uri schemes in the provisional = category at https://www.iana.org/assignments/uri-schemes/uri-schemes.xml = are Microsoft-only).=C2=A0 That's not in-line with the purpose of .arpa= as an infrastructure domain.

If you disagree,= please write up your proposal.=C2=A0 I trust DISPATCH will ensure that it = gets discussed in the same place as this proposal.

=
regards,

Ted


On July 6, 2020 at 4:19 PM Ted Hardie <ted.ietf@gmail.com> wrote:=20

On Mon, Jul 6, 2020 at 12:09 PM Timothy Mcsweeney <=20 tim@dropnumber= .com> wrote:=20
Hi,
>If I understand you correctly, you are arguing that because URI= .arpa was not >depopulated when the IETF tree was dropped, registrations= can still be made >according to the old rules as if there still were an= IETF tree.


I'm arguing that, as it sits right now, in order to insert a re= cord into uri.arpa,=C2=A0
you have to have a scheme name registered.=C2=A0=C2=A0


RFC 3405 is pretty restrictive in its language:

3.1 URI.ARPA Registration

3.1.1 Only Schemes in the IETF Tree Allowed

   In order to be inserted into the URI.ARPA zone, the subsequent URI
   scheme MUST be registered under the IETF URI tree.  The requirements
   for this tree are specified in [10].
Given the "Only" and the RFC 2119 "MUST&qu= ot;, I don't think a plain reading of the text supports the view that a= ny URI registration is sufficient.=C2=A0=C2=A0 Section 3.1.2 also reinforce= s that the registration must be prior and then the record insertion must pa= ss IESG review; that section does not given the IESG the right to waive the= requirements:

3.1.2 Scheme Registration Takes Precedence

   The registration of a NAPTR record for a URI scheme MUST NOT precede
   proper registration of that scheme and publication of a stable
   specification in accordance with [10].  The IESG or its designated
   expert will review the request for

      1.  correctness and technical soundness

      2.  consistency with the published URI specification, and

      3.  to ensure that the NAPTR record for a DNS-based URI does not
          delegate resolution of the URI to a party other than the
          holder of the DNS name.  This last rule is to insure that a
          given URI's resolution hint doesn't hijack (inadvertently=
 or
          otherwise) network traffic for a given domain.
regards,

Ted Hardie=20





On July 6, 2020 at 2:51 PM Ted Hardie <=20 ted.ietf@gmail.com> wrote:=20

Howdy,=20

On Mon, Jul 6, 2020 at 11:26 AM Timothy Mcsweeney <=20 tim@dropnumber.com> wrote:=20
Ted,=C2=A0
>=20
>Yes, this came up because of a proposed registration= . Since it was yours,=20
>perhaps you would like to provide the link to the gr= oup?

There is already a mailing list for that.


>Once DISPATCH decides where this ought to be discuss= ed, we can discuss that=20
>outcome or the update to BCP 35 to restore the categ= ory as alternatives.


There should not be a discussion at all.=C2=A0=20
1.=C2=A0 Section 5 of RFC3405 isn't broken.=C2=A0 Ma= ybe you were confusing it with=20
=C2=A0 =C2=A0 =C2=A0Section 5 or RFC4395?=C2=A0=20

As I note in the extremely short document:

   The document requires that registrations be in the "=
;IETF
   tree" of URI registrations.  The use of URI scheme name trees was
   defined in RFC 2717 [RFC2717] but discontinued by RFC 4395 [RFC4395].
   Since the use of trees was discontinued, there is no way in the
   current process set out in BCP 35 [RFC7595] to meet the requirement.
          

If we leave things as they are, no registrations can be made, be= cause the category is gone.=C2=A0 We can change it to require permanent reg= istrations instead (as this document suggests) or you could propose somethi= ng different (e.g. updating BCP 35 to recreate the IETF tree for these regi= strations).

2. Regardless, any discussions should really wait until afte= r upcoming=20
registrations or appeals of those registrations, or appe= als of those appeals are=20
completed.



>The current rules cannot work because they reference= a category that no=20
>longer exists. To put this differently, if they don&= #39;t change, there can be=20
>no more registrations in URI.arpa.


The current rules are working just fine.=C2=A0=20
HTTP, among others, are still in the uri.arpa zone provi= ng that the RFC3405=20
Section 3.1.1 reference [10] lives on through the obsole= ted RFCs to the current=20
spec and can be=C2=A0seen in totality in IANA's list= of URIs.=20


If I understand you correctly, you are arguing that because URI.= arpa was not depopulated when the IETF tree was dropped, registrations can = still be made according to the old rules as if there still were an IETF tre= e.=C2=A0=20

That's not how the IETF process treats obsoleting BCPs; see = the IESG statement at=20 http= s://www.ietf.org/about/groups/iesg/statements/designating-rfcs-historic-201= 4-07-20/.

This situation has pointed out that there was a bug introduced by= RFC 4395 that was carried forward into RFC 7595, because they did not addr= ess the dependency on the removed IETF tree in BCP 65.=C2=A0 This document = is one way to address that bug.=C2=A0 If you wish to suggest others, that&#= 39;s fine, but we still need DISPATCH to identify where the discussion shou= ld happen.=C2=A0=20

regards,

Ted=20




On July 6, 2020 at 12:15 PM Ted Hardie <=20 ted.ietf@gmail.com> wrote:=20

Howdy,=20

On Sat, Jul 4, 2020 at 2:28 AM Timothy Mcsweeney <=20 tim@dropnumber.com> wrote:=20
Ted,=C2=A0
In your opening email to the 400 highly respectable peopl= e on this list you say:
"As it happens, there are very few registrations in = URI.ARPA, so we did not catch it and fix it before now."=C2=A0=C2=A0

How did you "catch it"?=C2=A0
Was there a pending registration?=C2=A0
Is there still a pending registration?=C2=A0

Yes, this came up because of a proposed registration.=C2=A0= Since it was yours, perhaps you would like to provide the link to the grou= p?

It would really be bad to try to change the rules while= =C2=A0something was pending.


The current rules cannot work because they reference a cate= gory that no longer exists. To put this differently, if they don't chan= ge, there can be no more registrations in URI.arpa.=C2=A0=20

Once DISPATCH decides where this ought to be discussed, we = can discuss that outcome or the update to BCP 35 to restore the category as= alternatives.

regards,

Ted Hardie=20



I can't speak for the others but some of them might w= ant to know why after almost 20 years of there being zero problems with RFC= 3405 it suddenly needs to get "fixed".
_______________________________________________=20
dispatch mailing list=20
dispatch@ietf.org=20
https://www.ietf.org/mailman/listinfo/di= spatch=20

=C2=A0

=C2=A0

=C2=A0
=20
--0000000000001119de05a9cd320e-- From nobody Mon Jul 6 15:25:55 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62FA3A0B93 for ; Mon, 6 Jul 2020 15:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, MAY_BE_FORGED=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 x5dEctoxM0Eh for ; Mon, 6 Jul 2020 15:25:51 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 3B0CF3A0B92 for ; Mon, 6 Jul 2020 15:25:51 -0700 (PDT) Received: from bens-macbook.lan (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 066MPfrY079737 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 6 Jul 2020 17:25:43 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1594074344; bh=2CwpWdy6nKYzCi5g5F4SmliTiBBSqwcXLzIYJ7W9wYI=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=mBqAOvkSDxcPygqT6dgHshYP+pWmBopeiyjv1NCEz746vsMDLHq1P3XURxZHG45tf TYxlMq4C7NLH7V2sm5bjyoa8JAKJQTCUA1/GSFq+5B7+YxmuyKygM45OqKkSY8G+HN cqvELrK3gzgrRhTzDqxrg1IE38JQZrzREujyHl2M= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be bens-macbook.lan From: Ben Campbell Message-Id: <23997780-BD02-4A2B-90FD-B21CEB6FFF38@nostrum.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7598D0D5-D585-48B7-9E4B-C98ED568AEB9" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 6 Jul 2020 17:25:36 -0500 In-Reply-To: Cc: DISPATCH WG , Barry Leiba , Patrick McManus To: Ted Hardie , Timothy Mcsweeney References: <1007260719.140376.1593854488478@email.ionos.com> <22863747.195824.1594059994823@email.ionos.com> <1557624035.199224.1594062567206@email.ionos.com> <1990424976.229638.1594067242698@email.ionos.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 22:25:54 -0000 --Apple-Mail=_7598D0D5-D585-48B7-9E4B-C98ED568AEB9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 (As Co-Chair) Hi All, For the moment at least, please focus DISPATCH discussion on determining = what the proper venue for discussion is. Our choices are: 1) Recommend AD Sponsored 2) Adopt in DISPATCH as an =E2=80=9Cadministrative document=E2=80=9D as = allowed by our charter 3) =E2=80=9CDispatch=E2=80=9D to an existing WG, or recommend one be = formed. 4) Recommend a BoF. Thanks! Ben. > On Jul 6, 2020, at 5:13 PM, Ted Hardie wrote: >=20 > Howdy, >=20 > On Mon, Jul 6, 2020 at 1:27 PM Timothy Mcsweeney > wrote: > Ted, > Do you not want my scheme in the arpa zone? >=20 >=20 > I'm just trying to avoid a silly state, where we say do X but don't = let anyone do X. If this is published, then we'll have a clear rule = that matches the current system. But if the consensus turns out to be = that the IETF tree should return for the sole purpose of registering = schemes going into .arpa, I would go along with that as well. =20 >=20 > I don't support allowing provisionals in the zone because they are = first-come-first-served as of RFC 7595 and some of the registrations are = very vendor specific (for example, many of the ms- uri schemes in the = provisional category at = https://www.iana.org/assignments/uri-schemes/uri-schemes.xml = are = Microsoft-only). That's not in-line with the purpose of .arpa as an = infrastructure domain. >=20 > If you disagree, please write up your proposal. I trust DISPATCH will = ensure that it gets discussed in the same place as this proposal. >=20 > regards, >=20 > Ted >=20 >=20 >=20 >> On July 6, 2020 at 4:19 PM Ted Hardie > wrote:=20 >>=20 >> On Mon, Jul 6, 2020 at 12:09 PM Timothy Mcsweeney < = tim@dropnumber..com > wrote:=20 >> Hi, >> >If I understand you correctly, you are arguing that because = URI..arpa was not >depopulated when the IETF tree was dropped, = registrations can still be made >according to the old rules as if there = still were an IETF tree. >>=20 >>=20 >> I'm arguing that, as it sits right now, in order to insert a record = into uri.arpa,=20 >> you have to have a scheme name registered. =20 >>=20 >>=20 >> RFC 3405 is pretty restrictive in its language: >>=20 >> 3.1 URI.ARPA Registration >>=20 >> 3.1.1 Only Schemes in the IETF Tree Allowed >>=20 >> In order to be inserted into the URI.ARPA zone, the subsequent URI >> scheme MUST be registered under the IETF URI tree. The = requirements >> for this tree are specified in [10]. >> Given the "Only" and the RFC 2119 "MUST", I don't think a plain = reading of the text supports the view that any URI registration is = sufficient. Section 3.1.2 also reinforces that the registration must = be prior and then the record insertion must pass IESG review; that = section does not given the IESG the right to waive the requirements: >>=20 >> 3.1.2 Scheme Registration Takes Precedence >>=20 >> The registration of a NAPTR record for a URI scheme MUST NOT = precede >> proper registration of that scheme and publication of a stable >> specification in accordance with [10]. The IESG or its designated >> expert will review the request for >>=20 >> 1. correctness and technical soundness >>=20 >> 2. consistency with the published URI specification, and >>=20 >> 3. to ensure that the NAPTR record for a DNS-based URI does = not >> delegate resolution of the URI to a party other than the >> holder of the DNS name. This last rule is to insure that a >> given URI's resolution hint doesn't hijack (inadvertently = or >> otherwise) network traffic for a given domain. >> regards, >>=20 >> Ted Hardie=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>> On July 6, 2020 at 2:51 PM Ted Hardie < ted.ietf@gmail.com = > wrote:=20 >>>=20 >>> Howdy,=20 >>>=20 >>> On Mon, Jul 6, 2020 at 11:26 AM Timothy Mcsweeney < = tim@dropnumber.com > wrote:=20 >>> Ted,=20 >>> >=20 >>> >Yes, this came up because of a proposed registration.. Since it was = yours,=20 >>> >perhaps you would like to provide the link to the group? >>>=20 >>> There is already a mailing list for that. >>>=20 >>>=20 >>> >Once DISPATCH decides where this ought to be discussed, we can = discuss that=20 >>> >outcome or the update to BCP 35 to restore the category as = alternatives. >>>=20 >>>=20 >>> There should not be a discussion at all. =20 >>> 1. Section 5 of RFC3405 isn't broken. Maybe you were confusing it = with=20 >>> Section 5 or RFC4395? =20 >>>=20 >>> As I note in the extremely short document: >>>=20 >>> The document requires that registrations be in the "IETF >>> tree" of URI registrations. The use of URI scheme name trees was >>> defined in RFC 2717 [RFC2717] but discontinued by RFC 4395 = [RFC4395]. >>> Since the use of trees was discontinued, there is no way in the >>> current process set out in BCP 35 [RFC7595] to meet the = requirement. >>>=20 >>> If we leave things as they are, no registrations can be made, = because the category is gone. We can change it to require permanent = registrations instead (as this document suggests) or you could propose = something different (e.g. updating BCP 35 to recreate the IETF tree for = these registrations). >>>=20 >>> 2. Regardless, any discussions should really wait until after = upcoming=20 >>> registrations or appeals of those registrations, or appeals of those = appeals are=20 >>> completed. >>>=20 >>>=20 >>>=20 >>> >The current rules cannot work because they reference a category = that no=20 >>> >longer exists. To put this differently, if they don't change, there = can be=20 >>> >no more registrations in URI.arpa. >>>=20 >>>=20 >>> The current rules are working just fine. =20 >>> HTTP, among others, are still in the uri.arpa zone proving that the = RFC3405=20 >>> Section 3.1.1 reference [10] lives on through the obsoleted RFCs to = the current=20 >>> spec and can be seen in totality in IANA's list of URIs.=20 >>>=20 >>>=20 >>> If I understand you correctly, you are arguing that because URI.arpa = was not depopulated when the IETF tree was dropped, registrations can = still be made according to the old rules as if there still were an IETF = tree. =20 >>>=20 >>> That's not how the IETF process treats obsoleting BCPs; see the IESG = statement = athttps://www.ietf.org/about/groups/iesg/statements/designating-rfcs-histo= ric-2014-07-20/ = . >>>=20 >>> This situation has pointed out that there was a bug introduced by = RFC 4395 that was carried forward into RFC 7595, because they did not = address the dependency on the removed IETF tree in BCP 65. This = document is one way to address that bug. If you wish to suggest others, = that's fine, but we still need DISPATCH to identify where the discussion = should happen. =20 >>>=20 >>> regards, >>>=20 >>> Ted=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> On July 6, 2020 at 12:15 PM Ted Hardie < ted.ietf@gmail.com = > wrote:=20 >>>>=20 >>>> Howdy,=20 >>>>=20 >>>> On Sat, Jul 4, 2020 at 2:28 AM Timothy Mcsweeney < = tim@dropnumber.com > wrote:=20 >>>> Ted,=20 >>>> In your opening email to the 400 highly respectable people on this = list you say: >>>> "As it happens, there are very few registrations in URI.ARPA, so we = did not catch it and fix it before now." =20 >>>>=20 >>>> How did you "catch it"?=20 >>>> Was there a pending registration?=20 >>>> Is there still a pending registration?=20 >>>>=20 >>>> Yes, this came up because of a proposed registration. Since it was = yours, perhaps you would like to provide the link to the group? >>>>=20 >>>> It would really be bad to try to change the rules while something = was pending. >>>>=20 >>>>=20 >>>> The current rules cannot work because they reference a category = that no longer exists. To put this differently, if they don't change, = there can be no more registrations in URI.arpa. =20 >>>>=20 >>>> Once DISPATCH decides where this ought to be discussed, we can = discuss that outcome or the update to BCP 35 to restore the category as = alternatives. >>>>=20 >>>> regards, >>>>=20 >>>> Ted Hardie=20 >>>>=20 >>>>=20 >>>>=20 >>>> I can't speak for the others but some of them might want to know = why after almost 20 years of there being zero problems with RFC3405 it = suddenly needs to get "fixed". >>>> _______________________________________________=20 >>>> dispatch mailing list=20 >>>> dispatch@ietf.org =20 >>>> https://www.ietf.org/mailman/listinfo/dispatch = =20 >>>=20 >>> =20 >>=20 >> =20 >=20 > =20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail=_7598D0D5-D585-48B7-9E4B-C98ED568AEB9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
(As Co-Chair)

Hi = All,

For the moment = at least, please focus DISPATCH discussion on determining what the = proper venue for discussion is.

Our choices are:
1) = Recommend AD Sponsored
2) Adopt in DISPATCH as an = =E2=80=9Cadministrative document=E2=80=9D as allowed by our = charter
3) =E2=80=9CDispatch=E2=80=9D to an = existing WG, or recommend one be formed.
4) = Recommend a BoF.

Thanks!

Ben.


On Jul 6, 2020, at 5:13 PM, Ted = Hardie <ted.ietf@gmail.com> wrote:

Howdy,

On Mon, Jul = 6, 2020 at 1:27 PM Timothy Mcsweeney <tim@dropnumber.com> = wrote:
=20 =20 =20
Ted,=20
Do you not want my scheme in the arpa zone?


I'm just trying to avoid a silly state, = where we say do X but don't let anyone do X.  If this is published, = then we'll have a clear rule that matches the current system.  But = if the consensus turns out to be that the IETF tree should return for = the sole purpose of registering schemes going into .arpa, I would go = along with that as well. 

I don't support allowing provisionals = in the zone because they are first-come-first-served as of RFC 7595 and = some of the registrations are very vendor specific (for example, many of = the ms- uri schemes in the provisional category at https://www.iana.org/assignments/uri-schemes/uri-schemes.xml are Microsoft-only).  That's not in-line with the purpose of = .arpa as an infrastructure domain.





On July 6, 2020 at 4:19 PM Ted Hardie <ted.ietf@gmail.com> wrote:=20

On Mon, Jul 6, 2020 at 12:09 PM Timothy Mcsweeney <=20 tim@dropnumber..com> wrote:=20
Hi,
>If I understand you correctly, you are arguing that because = URI..arpa was not >depopulated when the IETF tree was dropped, = registrations can still be made >according to the old rules as if = there still were an IETF tree.


I'm arguing that, as it sits right now, in order to insert a = record into uri.arpa, 
you have to have a scheme name registered.  


RFC 3405 is pretty restrictive in its language:

3.1 URI.ARPA Registration

3.1.1 Only Schemes in the IETF Tree Allowed

   In order to be inserted into the URI.ARPA zone, the subsequent URI
   scheme MUST be registered under the IETF URI tree.  The requirements
   for this tree are specified in [10].
Given the "Only" and the RFC 2119 "MUST", I don't = think a plain reading of the text supports the view that any URI = registration is sufficient.   Section 3.1.2 also reinforces = that the registration must be prior and then the record insertion must = pass IESG review; that section does not given the IESG the right to = waive the requirements:

3.1.2 Scheme Registration Takes Precedence

   The registration of a NAPTR record for a URI scheme MUST NOT precede
   proper registration of that scheme and publication of a stable
   specification in accordance with [10].  The IESG or its designated
   expert will review the request for

      1.  correctness and technical soundness

      2.  consistency with the published URI specification, and

      3.  to ensure that the NAPTR record for a DNS-based URI does not
          delegate resolution of the URI to a party other than the
          holder of the DNS name.  This last rule is to insure that a
          given URI's resolution hint doesn't hijack (inadvertently or
          otherwise) network traffic for a given domain.
regards,

Ted Hardie=20





On July 6, 2020 at 2:51 PM Ted Hardie <=20 ted.ietf@gmail.com> wrote:=20

Howdy,=20

On Mon, Jul 6, 2020 at 11:26 AM Timothy Mcsweeney <=20 tim@dropnumber.com> wrote:=20
Ted, 
>=20
>Yes, this came up because of a = proposed registration.. Since it was yours,=20
>perhaps you would like to provide the = link to the group?

There is already a mailing list for that.


>Once DISPATCH decides where this ought = to be discussed, we can discuss that=20
>outcome or the update to BCP 35 to = restore the category as alternatives.


There should not be a discussion at = all. =20
1.  Section 5 of RFC3405 isn't = broken.  Maybe you were confusing it with=20
     Section 5 or = RFC4395? =20

As I note in the extremely short document:

   The document requires that registrations =
be in the "IETF
   tree" of URI registrations.  The use of URI scheme name trees was
   defined in RFC 2717 [RFC2717] but discontinued by RFC 4395 [RFC4395].
   Since the use of trees was discontinued, there is no way in the
   current process set out in BCP 35 [RFC7595] to meet the =
requirement.

If we leave things as they are, no registrations can be made, = because the category is gone.  We can change it to require = permanent registrations instead (as this document suggests) or you could = propose something different (e.g. updating BCP 35 to recreate the IETF = tree for these registrations).

2. Regardless, any discussions should really wait until = after upcoming=20
registrations or appeals of those = registrations, or appeals of those appeals are=20
completed.



>The current rules cannot work because = they reference a category that no=20
>longer exists. To put this = differently, if they don't change, there can be=20
>no more registrations in URI.arpa.


The current rules are working just fine. =20
HTTP, among others, are still in the = uri.arpa zone proving that the RFC3405=20
Section 3.1.1 reference [10] lives on = through the obsoleted RFCs to the current=20
spec and can be seen in totality in = IANA's list of URIs.=20


If I understand you correctly, you are arguing that because = URI.arpa was not depopulated when the IETF tree was dropped, = registrations can still be made according to the old rules as if there = still were an IETF tree. =20

That's not how the IETF process treats obsoleting BCPs; see = the IESG statement at=20 https://www.ietf.org/about/groups/iesg/statements/designating-r= fcs-historic-2014-07-20/.

This situation has pointed out that there was a bug introduced = by RFC 4395 that was carried forward into RFC 7595, because they did not = address the dependency on the removed IETF tree in BCP 65.  This = document is one way to address that bug.  If you wish to suggest = others, that's fine, but we still need DISPATCH to identify where the = discussion should happen. =20

regards,

Ted=20




On July 6, 2020 at 12:15 PM Ted Hardie <=20 ted.ietf@gmail.com> wrote:=20

Howdy,=20

On Sat, Jul 4, 2020 at 2:28 AM Timothy Mcsweeney <=20 tim@dropnumber.com> wrote:=20
Ted, 
In your opening email to the 400 highly respectable = people on this list you say:
"As it happens, there are very few registrations in = URI.ARPA, so we did not catch it and fix it before now."  

How did you "catch it"? 
Was there a pending registration? 
Is there still a pending registration? 

Yes, this came up because of a proposed = registration.  Since it was yours, perhaps you would like to = provide the link to the group?

It would really be bad to try to change the rules = while something was pending.


The current rules cannot work because they reference a = category that no longer exists. To put this differently, if they don't = change, there can be no more registrations in URI.arpa. =20

Once DISPATCH decides where this ought to be discussed, = we can discuss that outcome or the update to BCP 35 to restore the = category as alternatives.

regards,

Ted Hardie=20



I can't speak for the others but some of them might = want to know why after almost 20 years of there being zero problems with = RFC3405 it suddenly needs to get "fixed".
_______________________________________________=20
dispatch mailing list=20
dispatch@ietf.org=20
https://www.ietf.org/mailman/listinfo/dispatch=20

 

 

 
=20
_______________________________________________
dispatch = mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

= --Apple-Mail=_7598D0D5-D585-48B7-9E4B-C98ED568AEB9-- From nobody Mon Jul 6 18:08:44 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9C13A08DB for ; Mon, 6 Jul 2020 18:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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 Jdxu7CZ91s4t for ; Mon, 6 Jul 2020 18:08:38 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (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 DEA2F3A0898 for ; Mon, 6 Jul 2020 18:08:33 -0700 (PDT) Received: from oxuslxaltgw15.schlund.de ([10.72.76.71]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1N2EcM-1kumXZ2owg-013gMI; Tue, 07 Jul 2020 03:08:31 +0200 Date: Mon, 6 Jul 2020 21:08:31 -0400 (EDT) From: Timothy Mcsweeney Reply-To: Timothy Mcsweeney To: Ted Hardie Cc: DISPATCH WG Message-ID: <1229438794.80445.1594084111594@email.ionos.com> In-Reply-To: References: <1007260719.140376.1593854488478@email.ionos.com> <22863747.195824.1594059994823@email.ionos.com> <1557624035.199224.1594062567206@email.ionos.com> <1990424976.229638.1594067242698@email.ionos.com> MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.1-Rev31 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:k4uNQjF3PB+xBytzv+Ekdo83Iv5gCYdRn/Q+nAZAjeJcMxqyD7W mzQoCXLathyRSDnJzPfQqgADI09Uw+S0ys9/lwH0lGjNDap1RMVydi6+dWXSBTMAomrLsvV 9b/8w17/+Ko9Ff29g3Ia1ltpGVDLDYSr5k32lxZ+NRo+F1OFyYcZ5vvskQ9qGcpiZQs5MUT jC5y8i+mjrvWhM3aFRWsw== X-UI-Out-Filterresults: notjunk:1;V03:K0:nihFaHbm7hk=:mZNdw0l3dfi7FKGTFsbWt0 w2yAgoktBVYVWNAhiVY3eyxLs7Y4W5a4bZz6TmC9z6l9KmmR7MLCGsOgyxMR7AwmQMIwPPCs3 sKR7rdR3YlyxgfNmhVFb20ubw3hTOT2nx4LqMKmo5/ysmVuSc4edeyObQA9C4o9vRBV17R2Sy SNtHkJIqZ7D7MEkwv3Vm0FALa5YSYbMevcsdpBUrj1HzECzLEvlqwJm5lwwpk/UfrY7vwURXf EMObamiYwpXh6EHai/0TN0mojPygM3eiDMn3hvjGmKHxXu+6G9dQSBmEyubo5Vejctb/wLBCT q7LAnB5k/zjCQ08/eongy+BoirqbqX98A0CQrVuGbypv7y6MKG/sDQGMTDJ+T/EwNcPI5U7cf nPvhghWAGN4f3d/BCSD9/JF4nJG6mZdxUD4g+9964TRyVoVlP4Eq1d+Q0voKHh+9uJSRn2bLh Gh85/Zc+zSx+sNEP54YWYkrLXlYSGGEJhgm5Yg/SfX/iMyeX+viBXwlXvbaRYwF8vfXbY+uRx 2E4L2KbX0hnnusum7zDH82HOpU4QtKFj/iwcUNEmLbNvYqjT9SmL5XDPkurN0jsLd+KInCj7J rHLuz5rpBCMwo6+tyB29YJIjJnClrNuqEDUlefhX1Wci3KsyNH1Afn0aUgqwZnkxwGZkUlTuM tIF2svsDNldok6bNNmtT/Y7ReuzcWzXPgfq7SNV9pZh5HIKXj/P508OjO5JPHBMhJ+Z+7V6qJ /GxAEYw7E0Tc04ngdLw0Vfpovy5i5OWTlFynn2iRg0szqsMsFF2yGMqzkl3qmejoy+3//coSY SWg602+Ww8U+zQZS9WryV7N3AAZU7e0skcchDxKCwEqHJ7Tvnj3GZoJWLBigWcEe2ve6NY9 Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 01:08:43 -0000
I'll take that as a yes.



On July 6, 2020 at 6:13 PM Ted Hardie <ted.ietf@gmail.com> wrote:

Howdy,

On Mon, Jul 6, 2020 at 1:27 PM Timothy Mcsweeney < tim@dropnumber.com> wrote:
Ted,
Do you not want my scheme in the arpa zone?


I'm just trying to avoid a silly state, where we say do X but don't let anyone do X.  If this is published, then we'll have a clear rule that matches the current system.  But if the consensus turns out to be that the IETF tree should return for the sole purpose of registering schemes going into .arpa, I would go along with that as well. 

I don't support allowing provisionals in the zone because they are first-come-first-served as of RFC 7595 and some of the registrations are very vendor specific (for example, many of the ms- uri schemes in the provisional category at https://www.iana.org/assignments/uri-schemes/uri-schemes.xml are Microsoft-only).  That's not in-line with the purpose of .arpa as an infrastructure domain.

If you disagree, please write up your proposal.  I trust DISPATCH will ensure that it gets discussed in the same place as this proposal.

regards,

Ted




On July 6, 2020 at 4:19 PM Ted Hardie < ted.ietf@gmail.com> wrote:

On Mon, Jul 6, 2020 at 12:09 PM Timothy Mcsweeney < tim@dropnumber.com> wrote:
Hi,
>If I understand you correctly, you are arguing that because URI.arpa was not >depopulated when the IETF tree was dropped, registrations can still be made >according to the old rules as if there still were an IETF tree.


I'm arguing that, as it sits right now, in order to insert a record into uri.arpa, 
you have to have a scheme name registered.  


RFC 3405 is pretty restrictive in its language:

3.1 URI.ARPA Registration

3.1.1 Only Schemes in the IETF Tree Allowed

   In order to be inserted into the URI.ARPA zone, the subsequent URI
   scheme MUST be registered under the IETF URI tree.  The requirements
   for this tree are specified in [10].
Given the "Only" and the RFC 2119 "MUST", I don't think a plain reading of the text supports the view that any URI registration is sufficient.   Section 3.1.2 also reinforces that the registration must be prior and then the record insertion must pass IESG review; that section does not given the IESG the right to waive the requirements:

3.1.2 Scheme Registration Takes Precedence

   The registration of a NAPTR record for a URI scheme MUST NOT precede
   proper registration of that scheme and publication of a stable
   specification in accordance with [10].  The IESG or its designated
   expert will review the request for

      1.  correctness and technical soundness

      2.  consistency with the published URI specification, and

      3.  to ensure that the NAPTR record for a DNS-based URI does not
          delegate resolution of the URI to a party other than the
          holder of the DNS name.  This last rule is to insure that a
          given URI's resolution hint doesn't hijack (inadvertently or
          otherwise) network traffic for a given domain.
regards,

Ted Hardie





On July 6, 2020 at 2:51 PM Ted Hardie < ted.ietf@gmail.com> wrote:

Howdy,

On Mon, Jul 6, 2020 at 11:26 AM Timothy Mcsweeney < tim@dropnumber.com> wrote:
Ted, 
>
>Yes, this came up because of a proposed registration. Since it was yours,
>perhaps you would like to provide the link to the group?

There is already a mailing list for that.


>Once DISPATCH decides where this ought to be discussed, we can discuss that
>outcome or the update to BCP 35 to restore the category as alternatives.


There should not be a discussion at all. 
1.  Section 5 of RFC3405 isn't broken.  Maybe you were confusing it with
     Section 5 or RFC4395? 

As I note in the extremely short document:

   The document requires that registrations be in the "IETF
   tree" of URI registrations.  The use of URI scheme name trees was
   defined in RFC 2717 [RFC2717] but discontinued by RFC 4395 [RFC4395].
   Since the use of trees was discontinued, there is no way in the
   current process set out in BCP 35 [RFC7595] to meet the requirement.

If we leave things as they are, no registrations can be made, because the category is gone.  We can change it to require permanent registrations instead (as this document suggests) or you could propose something different (e.g. updating BCP 35 to recreate the IETF tree for these registrations).

2. Regardless, any discussions should really wait until after upcoming
registrations or appeals of those registrations, or appeals of those appeals are
completed.



>The current rules cannot work because they reference a category that no
>longer exists. To put this differently, if they don't change, there can be
>no more registrations in URI.arpa.


The current rules are working just fine. 
HTTP, among others, are still in the uri.arpa zone proving that the RFC3405
Section 3.1.1 reference [10] lives on through the obsoleted RFCs to the current
spec and can be seen in totality in IANA's list of URIs.


If I understand you correctly, you are arguing that because URI.arpa was not depopulated when the IETF tree was dropped, registrations can still be made according to the old rules as if there still were an IETF tree. 

That's not how the IETF process treats obsoleting BCPs; see the IESG statement at https://www.ietf.org/about/groups/iesg/statements/designating-rfcs-historic-2014-07-20/.

This situation has pointed out that there was a bug introduced by RFC 4395 that was carried forward into RFC 7595, because they did not address the dependency on the removed IETF tree in BCP 65.  This document is one way to address that bug.  If you wish to suggest others, that's fine, but we still need DISPATCH to identify where the discussion should happen. 

regards,

Ted




On July 6, 2020 at 12:15 PM Ted Hardie < ted.ietf@gmail.com> wrote:

Howdy,

On Sat, Jul 4, 2020 at 2:28 AM Timothy Mcsweeney < tim@dropnumber.com> wrote:
Ted, 
In your opening email to the 400 highly respectable people on this list you say:
"As it happens, there are very few registrations in URI.ARPA, so we did not catch it and fix it before now."  

How did you "catch it"? 
Was there a pending registration? 
Is there still a pending registration? 

Yes, this came up because of a proposed registration.  Since it was yours, perhaps you would like to provide the link to the group?

It would really be bad to try to change the rules while something was pending.


The current rules cannot work because they reference a category that no longer exists. To put this differently, if they don't change, there can be no more registrations in URI.arpa. 

Once DISPATCH decides where this ought to be discussed, we can discuss that outcome or the update to BCP 35 to restore the category as alternatives.

regards,

Ted Hardie



I can't speak for the others but some of them might want to know why after almost 20 years of there being zero problems with RFC3405 it suddenly needs to get "fixed".
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

 

 

 

 
From nobody Mon Jul 6 18:09:00 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13C93A088F for ; Mon, 6 Jul 2020 18:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=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 JQmtXctLEYrb for ; Mon, 6 Jul 2020 18:08:55 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (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 88F933A0901 for ; Mon, 6 Jul 2020 18:08:44 -0700 (PDT) Received: from oxuslxaltgw15.schlund.de ([10.72.76.71]) by mrelay.perfora.net (mreueus002 [74.208.5.2]) with ESMTPSA (Nemesis) id 0Mgd8b-1kEpwU271D-00O1yE; Tue, 07 Jul 2020 03:08:33 +0200 Date: Mon, 6 Jul 2020 21:08:33 -0400 (EDT) From: Timothy Mcsweeney Reply-To: Timothy Mcsweeney To: Ben Campbell , Ted Hardie Cc: DISPATCH WG , Barry Leiba , Patrick McManus , superuser@gmail.com Message-ID: <540630596.80446.1594084113227@email.ionos.com> In-Reply-To: <23997780-BD02-4A2B-90FD-B21CEB6FFF38@nostrum.com> References: <1007260719.140376.1593854488478@email.ionos.com> <22863747.195824.1594059994823@email.ionos.com> <1557624035.199224.1594062567206@email.ionos.com> <1990424976.229638.1594067242698@email.ionos.com> <23997780-BD02-4A2B-90FD-B21CEB6FFF38@nostrum.com> MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.1-Rev31 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:0gf8TW3ssQkHWC18bhFPPNtVGZCF5RbsgqFf3ykhkMv5QcWTBal XE8FpxBT4znYFisCIyHFJLM8Pgwf/t0nDBjXU6UePmbJEbmKjqRmKh/QYU/HHwoP/3ckUfH YzzrRLzlei2i+NgnlyXyKmvjQTsrObRbWDdBfBkx0gUMd8UTmkkFMgMTPcXesKUz8SgOCxF D8n7q9L8FkaYOc63+bVkw== X-UI-Out-Filterresults: notjunk:1;V03:K0:1g1TKZR214c=:mOTXJOAAA6SiJrBU7d1nDf vVNBbA8oAMGj1gGIWWlmnjMpfmbW/pTPeT4cPLbvW5fMTuL7x5stClXPqwlXtn2/3q5WzScTQ NZJyAjbSPTtWm2xzQiizQNdbUZ//lbm1vVmh3CQbjfHp2Uerfa9XY+1W4w/BMKfsadcVrcUj2 xWRvEsAnGyO/vvREW7mce8wgzBw644ghAw0NYbghTDYZWhCw0bG4f8WLcbXQdAAHXwnWAOrap 5DaHVZF/NV+hS92l/pRSw7SXBy9GW/pKkHPy0jpccFV2uz90MI7iXLWkB6yYZNLeNRTF237uP FhnRvWxIA4qe8DQESoVoasZ3ya51g4fiOBWGOD1MyzQtXP88IfKM6aRST5BSy/wfyR2xLDBNn fp83LbCkw5lB1v6tB8WPRBnsTuJM32AVVaZ7jo3Ob3EzcIOhpnJQ627EucPLay3bFcukJDyky NnqaNEkCo0yJaonkh90bN4W8iXGM6hdHDiLs7zNUARXaBdprv4sXBpKfDcGsAFaW/xhq1xi7M 0mIfi8XCzcEYHjwuSfX/0cKMu71OokgePKpYipyQ0iJCkDF4Yi4jq/NyFIZZZPeWTvNK+l/Un oYnY2eS1hDpmRw1y2DMRtF75P/bmRyIU1npRs49OBt3haRdjQPMOeMZWoWIjJ+6sSRQ6OkMDY a7k8l+zMqbjcKu7aaIlWx16eWfjsks0xpqwV1K/aJ/e1w65ddBCAXkIUVrS1rPxzSL3KXYMAh gUDf/6z0GPnYpldr0+iKAZ+WzzO5AwIAwRKpyk4+t9XH/gnlEPMDV5kPgYnY/Xz3Nz9oc9Cth m1bGgG1OjxfgCA4Xzy2eOjQsLwCHlwBybT3qdSY0lv4waKbe8DQiKpnK5mFMb17geZB33Sd Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 01:08:59 -0000 =20 =20
Everyone,

In case I do not get a chance to re-iterate my opinion, I think discussi= on on this topic can wait for a while and the timing is suspect.  Ted'= s name is on RFC4395 as well as RFC7595 giving him more than 15 years to br= ing this up.

Tim



On July 6, 2020 at 6:25 PM Ben Campbell <ben@nostrum.com> wrote:= =20

(As Co-Chair)

Hi All,

For the moment at least, please focus DISPATCH discussion on determinin= g what the proper venue for discussion is.

Our choices are:
1) Recommend AD Sponsored
2) Adopt in DISPATCH as an =E2=80=9Cadministrative document=E2=80=9D as= allowed by our charter
3) =E2=80=9CDispatch=E2=80=9D to an existing WG, or recommend one be fo= rmed.
4) Recommend a BoF.

Thanks!

Ben.


On Jul 6, 2020, at 5:13 PM, Ted Hardie <=20 ted.ietf@gmail.com<= /a>> wrote:

Howdy,=20

Ted,
Do you not want my scheme in the arpa zone?


I'm just trying to avoid a silly state, where we say do X but don= 't let anyone do X.  If this is published, then we'll have a clear rul= e that matches the current system.  But if the consensus turns out to = be that the IETF tree should return for the sole purpose of registering sch= emes going into .arpa, I would go along with that as well. =20

I don't support allowing provisionals in the zone because they ar= e first-come-first-served as of RFC 7595 and some of the registrations are = very vendor specific (for example, many of the ms- uri schemes in the provi= sional category at=20 https://www.iana.org/assignments/uri-schemes/uri-schemes= .xml are Microsoft-only).  That's not in-line with the purpose of = .arpa as an infrastructure domain.=20

If you disagree, please write up your proposal.  I trust DIS= PATCH will ensure that it gets discussed in the same place as this proposal= .=20

regards,

Ted=20




On July 6, 2020 at 4:19 PM Ted Hardie <=20 ted.ietf@gmail.com> wrote:=20

On Mon, Jul 6, 2020 at 12:09 PM Timothy Mcsweeney <=20 tim@dropnumber..com> wrote:=20
Hi,
>If I understand you correctly, you are arguing that be= cause URI..arpa was not >depopulated when the IETF tree was dropped, reg= istrations can still be made >according to the old rules as if there sti= ll were an IETF tree.


I'm arguing that, as it sits right now, in order to insert= a record into uri.arpa, 
you have to have a scheme name registered.  


RFC 3405 is pretty restrictive in its language:

3.1 URI.ARPA Registration

3.1.1 Only Schemes in the IETF Tree Allowed

   In order to be inserted into the URI.ARPA zone, the subsequent URI
   scheme MUST be registered under the IETF URI tree.  The requirements
   for this tree are specified in [10].
Given the "Only" and the RFC 2119 "MUST", I don'= t think a plain reading of the text supports the view that any URI registra= tion is sufficient.   Section 3.1.2 also reinforces that the regi= stration must be prior and then the record insertion must pass IESG review;= that section does not given the IESG the right to waive the requirements:

3.1.2 Scheme Registration Takes Precedence

   The registration of a NAPTR record for a URI scheme MUST NOT precede
   proper registration of that scheme and publication of a stable
   specification in accordance with [10].  The IESG or its designated
   expert will review the request for

      1.  correctness and technical soundness

      2.  consistency with the published URI specification, and

      3.  to ensure that the NAPTR record for a DNS-based URI does not
          delegate resolution of the URI to a party other than the
          holder of the DNS name.  This last rule is to insure that a
          given URI's resolution hint doesn't hijack (inadvertently or
          otherwise) network traffic for a given domain.
regards,

Ted Hardie=20





On July 6, 2020 at 2:51 PM Ted Hardie <=20 ted.ietf@gmail.com> wrote:=20

Howdy,=20

On Mon, Jul 6, 2020 at 11:26 AM Timothy Mcsweeney <= =20 tim@dropnumber.com> wrote:=20
Ted, 
>=20
>Yes, this came up because of a p= roposed registration.. Since it was yours,=20
>perhaps you would like to provid= e the link to the group?

There is already a mailing list for = that.


>Once DISPATCH decides where this= ought to be discussed, we can discuss that=20
>outcome or the update to BCP 35 = to restore the category as alternatives.


There should not be a discussion at = all. =20
1.  Section 5 of RFC3405 isn't = broken.  Maybe you were confusing it with=20
     Section 5 or RFC= 4395? =20

As I note in the extremely short document:

   The document requires that registrat=
ions be in the "IETF
   tree" of URI registrations.  The use of URI scheme name trees was
   defined in RFC 2717 [RFC2717] but discontinued by RFC 4395 [RFC4395].
   Since the use of trees was discontinued, there is no way in the
   current process set out in BCP 35 [RFC7595] to meet the requirement.
                   

If we leave things as they are, no registrations can be= made, because the category is gone.  We can change it to require perm= anent registrations instead (as this document suggests) or you could propos= e something different (e.g. updating BCP 35 to recreate the IETF tree for t= hese registrations).

2. Regardless, any discussions should really wait u= ntil after upcoming=20
registrations or appeals of those re= gistrations, or appeals of those appeals are=20
completed.



>The current rules cannot work be= cause they reference a category that no=20
>longer exists. To put this diffe= rently, if they don't change, there can be=20
>no more registrations in URI.arp= a.


The current rules are working just fine. =20
HTTP, among others, are still in the= uri.arpa zone proving that the RFC3405=20
Section 3.1.1 reference [10] lives o= n through the obsoleted RFCs to the current=20
spec and can be seen in totalit= y in IANA's list of URIs.=20


If I understand you correctly, you are arguing that bec= ause URI.arpa was not depopulated when the IETF tree was dropped, registrat= ions can still be made according to the old rules as if there still were an= IETF tree. =20

That's not how the IETF process treats obsoleting BCPs;= see the IESG statement at=20 https://www.ietf.org/about/groups/iesg/statements/designati= ng-rfcs-historic-2014-07-20/.

This situation has pointed out that there was a bug intr= oduced by RFC 4395 that was carried forward into RFC 7595, because they did= not address the dependency on the removed IETF tree in BCP 65.  This = document is one way to address that bug.  If you wish to suggest other= s, that's fine, but we still need DISPATCH to identify where the discussion= should happen. =20

regards,

Ted=20




On July 6, 2020 at 12:15 PM Ted Hardie <=20 ted.ietf@gmail.com> wrote:=20

Howdy,=20

On Sat, Jul 4, 2020 at 2:28 AM Timothy Mcsweeney &= lt;=20 tim@dropnumber.com> wrote:=20
Ted, 
In your opening email to the 400 highly respecta= ble people on this list you say:
"As it happens, there are very few registrations= in URI.ARPA, so we did not catch it and fix it before now."  

How did you "catch it"? 
Was there a pending registration? 
Is there still a pending registration? 

Yes, this came up because of a proposed registrati= on.  Since it was yours, perhaps you would like to provide the link to= the group?

It would really be bad to try to change the rule= s while something was pending.


The current rules cannot work because they referen= ce a category that no longer exists. To put this differently, if they don't= change, there can be no more registrations in URI.arpa. =20

Once DISPATCH decides where this ought to be discu= ssed, we can discuss that outcome or the update to BCP 35 to restore the ca= tegory as alternatives.

regards,

Ted Hardie=20



I can't speak for the others but some of them mi= ght want to know why after almost 20 years of there being zero problems wit= h RFC3405 it suddenly needs to get "fixed".
____________________________________________= ___=20
dispatch mailing list=20
dispatch@ietf.org=20
https://www.ietf.org= /mailman/listinfo/dispatch=20

 

 

 
_______________________________________________=20
dispatch mailing list=20
dispatch@ietf.org=20
https://www.ietf.org/mailman/listinfo/dispatch=20


 
=20 From nobody Mon Jul 6 18:37:53 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 655393A0863 for ; Mon, 6 Jul 2020 18:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, MAY_BE_FORGED=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 K9_jIxym1pve for ; Mon, 6 Jul 2020 18:37:49 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 E82983A0861 for ; Mon, 6 Jul 2020 18:37:48 -0700 (PDT) Received: from bens-macbook.lan (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 0671bim6026400 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 6 Jul 2020 20:37:45 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1594085866; bh=Nr8bsEmLRSsWXlofTvJ5XmSxG3RbXVLObeuo9ha9v+4=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=JHeg+PVq4ihMrT/5bN4AMet19dVdPnHXkdGAgEeKDS7PMdjPPqnuJy+DMEFC4g3Uq +0QAoBXHosxkVtVEuYM4lrnHyIVZTVzS98/Ajse56kQbO1dw1ZHi+66kQoJwunVg/3 EO41CSsfbVFAszmIiCI8kCc7zoqlQkbWKpNSrdQk= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be bens-macbook.lan Content-Type: multipart/alternative; boundary="Apple-Mail=_AB7FDCF8-0035-4E58-9734-3F628D150D7C" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Ben Campbell X-Priority: 3 In-Reply-To: <1229438794.80445.1594084111594@email.ionos.com> Date: Mon, 6 Jul 2020 20:37:37 -0500 Cc: Ted Hardie , DISPATCH WG , Patrick McManus Message-Id: <151ECE60-B4DB-4D6F-A669-D895A00660CF@nostrum.com> References: <1007260719.140376.1593854488478@email.ionos.com> <22863747.195824.1594059994823@email.ionos.com> <1557624035.199224.1594062567206@email.ionos.com> <1990424976.229638.1594067242698@email.ionos.com> <1229438794.80445.1594084111594@email.ionos.com> To: Timothy Mcsweeney X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 01:37:51 -0000 --Apple-Mail=_AB7FDCF8-0035-4E58-9734-3F628D150D7C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Specific registration requests are off-topic. Please constrain = discussion to the draft in question. Thanks, Ben. > On Jul 6, 2020, at 8:08 PM, Timothy Mcsweeney = wrote: >=20 > I'll take that as a yes. >=20 >=20 >=20 >> On July 6, 2020 at 6:13 PM Ted Hardie wrote:=20 >>=20 >> Howdy,=20 >>=20 >> On Mon, Jul 6, 2020 at 1:27 PM Timothy Mcsweeney < tim@dropnumber.com = > wrote:=20 >> Ted, >> Do you not want my scheme in the arpa zone? >>=20 >>=20 >> I'm just trying to avoid a silly state, where we say do X but don't = let anyone do X. If this is published, then we'll have a clear rule = that matches the current system. But if the consensus turns out to be = that the IETF tree should return for the sole purpose of registering = schemes going into .arpa, I would go along with that as well. =20 >>=20 >> I don't support allowing provisionals in the zone because they are = first-come-first-served as of RFC 7595 and some of the registrations are = very vendor specific (for example, many of the ms- uri schemes in the = provisional category at = https://www.iana.org/assignments/uri-schemes/uri-schemes.xml = are = Microsoft-only). That's not in-line with the purpose of .arpa as an = infrastructure domain.=20 >>=20 >> If you disagree, please write up your proposal. I trust DISPATCH = will ensure that it gets discussed in the same place as this proposal.=20= >>=20 >> regards, >>=20 >> Ted=20 >>=20 >>=20 >>=20 >>=20 >>> On July 6, 2020 at 4:19 PM Ted Hardie < ted.ietf@gmail.com = > wrote:=20 >>>=20 >>> On Mon, Jul 6, 2020 at 12:09 PM Timothy Mcsweeney < = tim@dropnumber.com > wrote:=20 >>> Hi, >>> >If I understand you correctly, you are arguing that because = URI.arpa was not >depopulated when the IETF tree was dropped, = registrations can still be made >according to the old rules as if there = still were an IETF tree. >>>=20 >>>=20 >>> I'm arguing that, as it sits right now, in order to insert a record = into uri.arpa,=20 >>> you have to have a scheme name registered. =20 >>>=20 >>>=20 >>> RFC 3405 is pretty restrictive in its language: >>>=20 >>> 3.1 URI.ARPA Registration >>>=20 >>> 3.1.1 Only Schemes in the IETF Tree Allowed >>>=20 >>> In order to be inserted into the URI.ARPA zone, the subsequent = URI >>> scheme MUST be registered under the IETF URI tree. The = requirements >>> for this tree are specified in [10]. >>> Given the "Only" and the RFC 2119 "MUST", I don't think a plain = reading of the text supports the view that any URI registration is = sufficient. Section 3.1.2 also reinforces that the registration must = be prior and then the record insertion must pass IESG review; that = section does not given the IESG the right to waive the requirements: >>>=20 >>> 3.1.2 Scheme Registration Takes Precedence >>>=20 >>> The registration of a NAPTR record for a URI scheme MUST NOT = precede >>> proper registration of that scheme and publication of a stable >>> specification in accordance with [10]. The IESG or its = designated >>> expert will review the request for >>>=20 >>> 1. correctness and technical soundness >>>=20 >>> 2. consistency with the published URI specification, and >>>=20 >>> 3. to ensure that the NAPTR record for a DNS-based URI does = not >>> delegate resolution of the URI to a party other than the >>> holder of the DNS name. This last rule is to insure that = a >>> given URI's resolution hint doesn't hijack (inadvertently = or >>> otherwise) network traffic for a given domain. >>> regards, >>>=20 >>> Ted Hardie=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> On July 6, 2020 at 2:51 PM Ted Hardie < ted.ietf@gmail.com = > wrote:=20 >>>>=20 >>>> Howdy,=20 >>>>=20 >>>> On Mon, Jul 6, 2020 at 11:26 AM Timothy Mcsweeney < = tim@dropnumber.com > wrote:=20 >>>> Ted,=20 >>>> >=20 >>>> >Yes, this came up because of a proposed registration. Since it was = yours,=20 >>>> >perhaps you would like to provide the link to the group? >>>>=20 >>>> There is already a mailing list for that. >>>>=20 >>>>=20 >>>> >Once DISPATCH decides where this ought to be discussed, we can = discuss that=20 >>>> >outcome or the update to BCP 35 to restore the category as = alternatives. >>>>=20 >>>>=20 >>>> There should not be a discussion at all. =20 >>>> 1. Section 5 of RFC3405 isn't broken. Maybe you were confusing it = with=20 >>>> Section 5 or RFC4395? =20 >>>>=20 >>>> As I note in the extremely short document: >>>>=20 >>>> The document requires that registrations be in the "IETF >>>> tree" of URI registrations. The use of URI scheme name trees = was >>>> defined in RFC 2717 [RFC2717] but discontinued by RFC 4395 = [RFC4395]. >>>> Since the use of trees was discontinued, there is no way in the >>>> current process set out in BCP 35 [RFC7595] to meet the = requirement. >>>>=20 >>>> If we leave things as they are, no registrations can be made, = because the category is gone. We can change it to require permanent = registrations instead (as this document suggests) or you could propose = something different (e.g. updating BCP 35 to recreate the IETF tree for = these registrations). >>>>=20 >>>> 2. Regardless, any discussions should really wait until after = upcoming=20 >>>> registrations or appeals of those registrations, or appeals of = those appeals are=20 >>>> completed. >>>>=20 >>>>=20 >>>>=20 >>>> >The current rules cannot work because they reference a category = that no=20 >>>> >longer exists. To put this differently, if they don't change, = there can be=20 >>>> >no more registrations in URI.arpa. >>>>=20 >>>>=20 >>>> The current rules are working just fine. =20 >>>> HTTP, among others, are still in the uri.arpa zone proving that the = RFC3405=20 >>>> Section 3.1.1 reference [10] lives on through the obsoleted RFCs to = the current=20 >>>> spec and can be seen in totality in IANA's list of URIs.=20 >>>>=20 >>>>=20 >>>> If I understand you correctly, you are arguing that because = URI.arpa was not depopulated when the IETF tree was dropped, = registrations can still be made according to the old rules as if there = still were an IETF tree. =20 >>>>=20 >>>> That's not how the IETF process treats obsoleting BCPs; see the = IESG statement = athttps://www.ietf.org/about/groups/iesg/statements/designating-rfcs-histo= ric-2014-07-20/ = . >>>>=20 >>>> This situation has pointed out that there was a bug introduced by = RFC 4395 that was carried forward into RFC 7595, because they did not = address the dependency on the removed IETF tree in BCP 65. This = document is one way to address that bug. If you wish to suggest others, = that's fine, but we still need DISPATCH to identify where the discussion = should happen. =20 >>>>=20 >>>> regards, >>>>=20 >>>> Ted=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> On July 6, 2020 at 12:15 PM Ted Hardie < ted.ietf@gmail.com = > wrote:=20 >>>>>=20 >>>>> Howdy,=20 >>>>>=20 >>>>> On Sat, Jul 4, 2020 at 2:28 AM Timothy Mcsweeney < = tim@dropnumber.com > wrote:=20 >>>>> Ted,=20 >>>>> In your opening email to the 400 highly respectable people on this = list you say: >>>>> "As it happens, there are very few registrations in URI.ARPA, so = we did not catch it and fix it before now." =20 >>>>>=20 >>>>> How did you "catch it"?=20 >>>>> Was there a pending registration?=20 >>>>> Is there still a pending registration?=20 >>>>>=20 >>>>> Yes, this came up because of a proposed registration. Since it = was yours, perhaps you would like to provide the link to the group? >>>>>=20 >>>>> It would really be bad to try to change the rules while something = was pending. >>>>>=20 >>>>>=20 >>>>> The current rules cannot work because they reference a category = that no longer exists. To put this differently, if they don't change, = there can be no more registrations in URI.arpa. =20 >>>>>=20 >>>>> Once DISPATCH decides where this ought to be discussed, we can = discuss that outcome or the update to BCP 35 to restore the category as = alternatives. >>>>>=20 >>>>> regards, >>>>>=20 >>>>> Ted Hardie=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> I can't speak for the others but some of them might want to know = why after almost 20 years of there being zero problems with RFC3405 it = suddenly needs to get "fixed". >>>>> _______________________________________________=20 >>>>> dispatch mailing list=20 >>>>> dispatch@ietf.org =20 >>>>> https://www.ietf.org/mailman/listinfo/dispatch = =20 >>>>=20 >>>> =20 >>>=20 >>> =20 >>=20 >> =20 >=20 > =20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail=_AB7FDCF8-0035-4E58-9734-3F628D150D7C Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Specific registration requests are off-topic. Please constrain discussion to the draft in question.

Thanks,

Ben.


I'll take that as a yes.



On July 6, 2020 at 6:13 PM Ted Hardie <ted.ietf@gmail.com> wrote:

Howdy,

On Mon, Jul 6, 2020 at 1:27 PM Timothy Mcsweeney < tim@dropnumber.com> wrote:
Ted,
Do you not want my scheme in the arpa zone?


I'm just trying to avoid a silly state, where we say do X but don't let anyone do X.  If this is published, then we'll have a clear rule that matches the current system.  But if the consensus turns out to be that the IETF tree should return for the sole purpose of registering schemes going into .arpa, I would go along with that as well. 

I don't support allowing provisionals in the zone because they are first-come-first-served as of RFC 7595 and some of the registrations are very vendor specific (for example, many of the ms- uri schemes in the provisional category at https://www.iana.org/assignments/uri-schemes/uri-schemes.xml are Microsoft-only).  That's not in-line with the purpose of .arpa as an infrastructure domain.

If you disagree, please write up your proposal.  I trust DISPATCH will ensure that it gets discussed in the same place as this proposal.

regards,

Ted




On July 6, 2020 at 4:19 PM Ted Hardie < ted.ietf@gmail.com> wrote:

On Mon, Jul 6, 2020 at 12:09 PM Timothy Mcsweeney < tim@dropnumber.com> wrote:
Hi,
>If I understand you correctly, you are arguing that because URI.arpa was not >depopulated when the IETF tree was dropped, registrations can still be made >according to the old rules as if there still were an IETF tree.


I'm arguing that, as it sits right now, in order to insert a record into uri.arpa, 
you have to have a scheme name registered.  


RFC 3405 is pretty restrictive in its language:

3.1 URI.ARPA Registration

3.1.1 Only Schemes in the IETF Tree Allowed

   In order to be inserted into the URI.ARPA zone, the subsequent URI
   scheme MUST be registered under the IETF URI tree.  The requirements
   for this tree are specified in [10].
Given the "Only" and the RFC 2119 "MUST", I don't think a plain reading of the text supports the view that any URI registration is sufficient.   Section 3.1.2 also reinforces that the registration must be prior and then the record insertion must pass IESG review; that section does not given the IESG the right to waive the requirements:

3.1.2 Scheme Registration Takes Precedence

   The registration of a NAPTR record for a URI scheme MUST NOT precede
   proper registration of that scheme and publication of a stable
   specification in accordance with [10].  The IESG or its designated
   expert will review the request for

      1.  correctness and technical soundness

      2.  consistency with the published URI specification, and

      3.  to ensure that the NAPTR record for a DNS-based URI does not
          delegate resolution of the URI to a party other than the
          holder of the DNS name.  This last rule is to insure that a
          given URI's resolution hint doesn't hijack (inadvertently or
          otherwise) network traffic for a given domain.
regards,

Ted Hardie





On July 6, 2020 at 2:51 PM Ted Hardie < ted.ietf@gmail.com> wrote:

Howdy,

On Mon, Jul 6, 2020 at 11:26 AM Timothy Mcsweeney < tim@dropnumber.com> wrote:
Ted, 
>
>Yes, this came up because of a proposed registration. Since it was yours,
>perhaps you would like to provide the link to the group?

There is already a mailing list for that.


>Once DISPATCH decides where this ought to be discussed, we can discuss that
>outcome or the update to BCP 35 to restore the category as alternatives.


There should not be a discussion at all. 
1.  Section 5 of RFC3405 isn't broken.  Maybe you were confusing it with
     Section 5 or RFC4395? 

As I note in the extremely short document:

   The document requires that registrations be in the "IETF
   tree" of URI registrations.  The use of URI scheme name trees was
   defined in RFC 2717 [RFC2717] but discontinued by RFC 4395 [RFC4395].
   Since the use of trees was discontinued, there is no way in the
   current process set out in BCP 35 [RFC7595] to meet the requirement.

If we leave things as they are, no registrations can be made, because the category is gone.  We can change it to require permanent registrations instead (as this document suggests) or you could propose something different (e.g. updating BCP 35 to recreate the IETF tree for these registrations).

2. Regardless, any discussions should really wait until after upcoming
registrations or appeals of those registrations, or appeals of those appeals are
completed.



>The current rules cannot work because they reference a category that no
>longer exists. To put this differently, if they don't change, there can be
>no more registrations in URI.arpa.


The current rules are working just fine. 
HTTP, among others, are still in the uri.arpa zone proving that the RFC3405
Section 3.1.1 reference [10] lives on through the obsoleted RFCs to the current
spec and can be seen in totality in IANA's list of URIs.


If I understand you correctly, you are arguing that because URI.arpa was not depopulated when the IETF tree was dropped, registrations can still be made according to the old rules as if there still were an IETF tree. 

That's not how the IETF process treats obsoleting BCPs; see the IESG statement at https://www.ietf.org/about/groups/iesg/statements/designating-rfcs-historic-2014-07-20/.

This situation has pointed out that there was a bug introduced by RFC 4395 that was carried forward into RFC 7595, because they did not address the dependency on the removed IETF tree in BCP 65.  This document is one way to address that bug.  If you wish to suggest others, that's fine, but we still need DISPATCH to identify where the discussion should happen. 

regards,

Ted




On July 6, 2020 at 12:15 PM Ted Hardie < ted.ietf@gmail.com> wrote:

Howdy,

On Sat, Jul 4, 2020 at 2:28 AM Timothy Mcsweeney < tim@dropnumber.com> wrote:
Ted, 
In your opening email to the 400 highly respectable people on this list you say:
"As it happens, there are very few registrations in URI.ARPA, so we did not catch it and fix it before now."  

How did you "catch it"? 
Was there a pending registration? 
Is there still a pending registration? 

Yes, this came up because of a proposed registration.  Since it was yours, perhaps you would like to provide the link to the group?

It would really be bad to try to change the rules while something was pending.


The current rules cannot work because they reference a category that no longer exists. To put this differently, if they don't change, there can be no more registrations in URI.arpa. 

Once DISPATCH decides where this ought to be discussed, we can discuss that outcome or the update to BCP 35 to restore the category as alternatives.

regards,

Ted Hardie



I can't speak for the others but some of them might want to know why after almost 20 years of there being zero problems with RFC3405 it suddenly needs to get "fixed".
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

 

 

 

 
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--Apple-Mail=_AB7FDCF8-0035-4E58-9734-3F628D150D7C-- From nobody Tue Jul 7 00:34:45 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3450C3A081C for ; Tue, 7 Jul 2020 00:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=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=itaoyama.onmicrosoft.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 BHuFRYhuVmGM for ; Tue, 7 Jul 2020 00:34:42 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-eopbgr1400131.outbound.protection.outlook.com [40.107.140.131]) (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 3FA1B3A0815 for ; Tue, 7 Jul 2020 00:34:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mZkGble7mI9c1v7mCwRHlRnAxZLlu0AQ4OQIpYQH36DFZifyiBSBhGjx19RmxX/JOrBj7QUUlUZlC+oV5bGa8tvXlS38tMsqwN9ojP2KjYkvZ3+vbsdowVwN5F3FB+ZjZxeHMecjBX6pSEiCToug5hwgQOSvD3wywxFcRaR196qGbhhsOrNm6RtxTv+bX7syybwzE428Ve1hYQn0b+KhBRTU7G4fGpj/zg59pl8UKQirGy1K9uA4bi4ECEExZVDJVIkzhafYNIlbRzKDfo4WuDhzyql/HAHF8uZYNizRcFtVTqFINa2yp2EL+RF7WwJi/vwttrziDgKfwDMuFfz0Uw== 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=MHeTiacwcFKmqS7pH/LkH/72E0BlFVJsweW5uUWPmMY=; b=BtJT+YznnSea1cqWuTNrcSfAPAnRgoUF/3r0aUN9NdHFl58IXyA8Qf3Eo+fuTRo8YQqEWloCFBsGxnjKSwr4Ny2IwL9PcEuN20h9pA3hdDQ+b5iYLRQdAI66+ltsyHGjXUAK7FsI+iXdlN7g4DlJ1Ag9ToMXgIK0UB3WNF0mFWOw8sYpFZBAsB/7WxC9JWYOv9EqDQpz3ncc+Wkt8PxQ53Sa9wRuER2Gyiq//1t+63U5eL2WZyVuh5g8mIqGBh0swszGOwaozjjEKBO3AGsomJpwoHIduCtgh6Hqqur6tScgjz2BaVZe4Nmp/ftxI8AnkPqz7OFv5NAPHJKGswzl7g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MHeTiacwcFKmqS7pH/LkH/72E0BlFVJsweW5uUWPmMY=; b=IUhEgmjcg19INH3OrsO+jjjUk3oKyAbOG/QQiCIRT7WvTX8OvK8prxSLa72ofxNtBlIBPuOHDzGcS87s+4aKWmZtc+ZoywGxd44l8JsxpC7jAMjjGa9W1+AjfAELtXAqgFjuV1aCHy/HJHbBidyMM7eU9594tSfudYzqKhf658o= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from OSBPR01MB2566.jpnprd01.prod.outlook.com (2603:1096:604:1c::13) by OSBPR01MB5176.jpnprd01.prod.outlook.com (2603:1096:604:74::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.23; Tue, 7 Jul 2020 07:34:39 +0000 Received: from OSBPR01MB2566.jpnprd01.prod.outlook.com ([fe80::d1a0:ea71:e6f9:9778]) by OSBPR01MB2566.jpnprd01.prod.outlook.com ([fe80::d1a0:ea71:e6f9:9778%7]) with mapi id 15.20.3153.029; Tue, 7 Jul 2020 07:34:39 +0000 To: Ben Campbell , Dispatch WG References: <85664807-701C-4700-ABB7-D0434F14D6A0@nostrum.com> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: Date: Tue, 7 Jul 2020 16:34:36 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <85664807-701C-4700-ABB7-D0434F14D6A0@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: TYAPR01CA0093.jpnprd01.prod.outlook.com (2603:1096:404:2c::33) To OSBPR01MB2566.jpnprd01.prod.outlook.com (2603:1096:604:1c::13) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.6] (125.203.82.4) by TYAPR01CA0093.jpnprd01.prod.outlook.com (2603:1096:404:2c::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.29 via Frontend Transport; Tue, 7 Jul 2020 07:34:39 +0000 X-Originating-IP: [125.203.82.4] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f0b691f7-30cf-4853-ffdf-08d8224834fc X-MS-TrafficTypeDiagnostic: OSBPR01MB5176: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 0457F11EAF X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: q5XcfjQ9Jy1PRbI9Nd7T2JqBC8hKEO+Uhhv3lcmW6+XXDRIcgJ2oYEAwPHZ+LMadS9xdpVn6L3UHMrhTVfL9HpB9H6DzmirQBOZqVU4H/+TGCur9u8rLJHqLMq0T7/6ZbzjZ+JRmkLORx3RGDe4D92xeznUvGcyg634v6MdLADr9YWAdxub7vCsNhJ6AUyqqDeMYTyXCeomcjtkXpPVHQL4DZCGOsTSUb2ME+F9/fepPzu1moiAroS3Zt1xiC3Yj34Rp+y+B0uTSjVlv5Oc2SNvj0UtU2V5iem7ayfHatZA3+KtPmADldDJ2l8C1d7mZHhAL6fsMYCJirDbQv8MuaA4nR6014bNgthuETgJlf0gJe7ndUiND4gXnh/sFrwiByAsGjd4S8TeCYoC9H38Xq7gBC//24kk6p6DQDpJ5eOcolU0ebpikpZ4FcZ1NlIBQM7ewelINN+MRjAHoTxGWeg== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:OSBPR01MB2566.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(366004)(376002)(396003)(136003)(39840400004)(346002)(966005)(66574015)(52116002)(36916002)(6486002)(508600001)(66476007)(66556008)(53546011)(2616005)(86362001)(31686004)(66946007)(956004)(8676002)(16526019)(15650500001)(26005)(6666004)(186003)(83380400001)(16576012)(2906002)(31696002)(5660300002)(8936002)(316002)(110136005)(786003)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: 4hNxdy/M59rmRDgtiHfpPgyPcZjc8sQpefUJYpDc3g1v4AMfPF4FdGHhHcEvug/ZXS8e9ChamcsGdr5526HdCB+ctUACCTfCbdfTjksDxqY4d97+vRaKLlRrCjUH/hUlU1fWIIgRZuePjb9A9hMz/W1T5plD+FBoOLeI2TXr7HzEmS3j60xEIo4u2GUdwN0lL72vwwKRh+DmanDEqqe9s1lJRcNKGYCgjyljwXSxM8kUJCn07Icrubkl6SWzxhMiOj8z/sSdJJjuBNZJhu4OOhtotrcHrK1sEQgGRksoxtYfz/yfgK02R0c7lYBLg+Bnv0jslE5QBim2wptjoNJctOP+JMR6lOGp4WetLZmEBGz+09jJI74vz9tNafd9ahJXig/ibAbGzp3GQ8dihWS/gjnLz4oZbELKgYYlW72iwDxlBWn/a6W4hOIrHDA19udZVFfIB2sDLFPqDc3T7f09eGaJbX4Wq/x1o7ctaAUu30A= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: f0b691f7-30cf-4853-ffdf-08d8224834fc X-MS-Exchange-CrossTenant-AuthSource: OSBPR01MB2566.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jul 2020 07:34:39.8128 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: ULYlU2Y3QDxFSdX+wwO64RrC0nvp0VOwegFr/UWihdRzzfJwj+0DbbrXZ3fZzhJV/kU50WQGKovrNzE7lQoWMw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSBPR01MB5176 Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 07:34:44 -0000 On 23/06/2020 07:51, Ben Campbell wrote: > Hi Everyone, > > The ART ADs have reminded the chairs that our charter allows us to adopt “simple administrative” work such as IANA registration documents. This draft seems to fit squarely in that category. Does anyone see a reason we shouldn’t just adopt it, with the expectation of going immediately to WGLC? (The last-call timeline is the same either way, either 2 weeks WGLC and 2 weeks IETF LC for a working group draft, or 4 weeks IETF LC for an AD sponsored draft.) Triggered by the recent discussion, I had a look at Ted's draft and the mail up to today. To me, both AD sponsored and Dispatch WG look reasonable, with a slight preference for the former (if asked to express such a preference). With respect to "pending registrations", I do not think these are relevant, in particular because the thing in question isn't actually a scheme, as discussed on the relevant list. I have one comment: The abstract currently reads "This document removes references to the IETF tree of URI registrations for registrations in URI.ARPA.". I found this hard to read, and I guess it's because of the "registrations for registrations" piece. Unless one is very familiar with the matter at hand, it's easy to think that both occurrences of "registration" are referencing the same thing. While I'm at it, it would also be good if the abstract mentioned something positive. I think a less normative version of (the single sentence that is) Section 2 would serve well as the abstract. Regards, Martin. > Thanks! > > Ben (as co-chair) > >> On Jun 3, 2020, at 6:13 PM, Ted Hardie wrote: >> >> Howdy, >> >> This is one the shortest drafts I've ever written: https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ .. Basically, RFC 3405 used to require that registrations in URI.ARPA be from the "IETF Tree". That tree was deprecated after the document was published. As it happens, there are very few registrations in URI.ARPA, so we did not catch it and fix it before now. >> >> This draft updates RFC 3405 to require "permanent" scheme registrations. The salient bit is this: >> >> All registrations in URI.ARPA MUST be for schemes which are permanent >> registrations, as they are described in BCP 35. >> >> I'm hoping for a quick dispatch of this, but happy to discuss. >> >> regards, >> >> Ted Hardie >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > -- Prof. Dr.sc. Martin J. Dürst Department of Intelligent Information Technology College of Science and Engineering Aoyama Gakuin University Fuchinobe 5-1-10, Chuo-ku, Sagamihara 252-5258 Japan From nobody Tue Jul 7 07:03:06 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94EF93A0CE9 for ; Tue, 7 Jul 2020 07:03:04 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 YyTqHJBNnjE9 for ; Tue, 7 Jul 2020 07:03:02 -0700 (PDT) Received: from mail-oo1-xc2b.google.com (mail-oo1-xc2b.google.com [IPv6:2607:f8b0:4864:20::c2b]) (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 95A843A0CE8 for ; Tue, 7 Jul 2020 07:03:02 -0700 (PDT) Received: by mail-oo1-xc2b.google.com with SMTP id d125so4627825oob.0 for ; Tue, 07 Jul 2020 07:03:02 -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=r6Wu+mGWWOjKZpSQctt6VRJ4E3qqOQEP6mfFmlBb2To=; b=sAj5qh3MU0R956OIrrB/RH206qqCZ20x5oCVDjo5AG7V1S76xvX72+Hm1b7EkpqudP J6FzRK8VtcLhUaod8KyVmxirmMWI1Zpl3b6ySzppxxOY5zsLLe5RewIMQ1ZCm6zj4viq MONxO4FA6GAAqTNiKyKrNZ2iuULeqrwy2Ul11YbsBsBP+OUEiHsvfpsp4kjhZUAi+XXy eK4mpCM0tHZPTPMDOQhM8rWlxRn+ATnE7/RwO05JcR41LVm3WozGHrXxdpK2umyXT1Ir vI+4X7Z9yolX/QE1kI5yFVosidW5uwzzbnB8j6FFaq+PC84wUsrJn0iZcJt01taIBEpa HYbA== 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=r6Wu+mGWWOjKZpSQctt6VRJ4E3qqOQEP6mfFmlBb2To=; b=gpE+K+YxlSSKgtsKd/IhG7ilsO/aIKdHJbht+3OUbw9zsjfQsD1XDuXvstGacE4ob9 eFg11nyIE4cgk3dOjSZ0zEa6rf12KlOp3T5khe02Be1WklOQeQtnIYyHRppJWLOaG31K ChRYuYkp7Cg/vKMRPjr/qGbDWkLRcbDMAtBbE60uIbkK0IpR6UVRblnOUBzj+VQs9An7 FyLLrnHIRARhZCDDsIphJL/f18q6AWIGXNgZL/i8ujvSKlx/fqu5eD7dEFErfX5wg5xj u0dmOQR2ixdYcbW8aSEI0U15pi9CGXdcR/XKeTwTM0HddpqhnaRfeJg4x0COwWcb5cQM AObQ== X-Gm-Message-State: AOAM5324VQnDpZpIj4VI+uGoYZRcnCOP0ufG5AFjT1H/gbJiHUKrM37K XY2cvdzisOEB5DsVxmN5yyBovQrRVTTJD/g8wlk= X-Google-Smtp-Source: ABdhPJxXLpomNB1mAZYlAVR47ODXYmL5x46mY4f5GLQc9AJu0YXr4DeFI/+GOS7JjKdXyhdqmchvG/CWmC8J7wr7eO8= X-Received: by 2002:a4a:57c1:: with SMTP id u184mr1748161ooa.67.1594130581692; Tue, 07 Jul 2020 07:03:01 -0700 (PDT) MIME-Version: 1.0 References: <85664807-701C-4700-ABB7-D0434F14D6A0@nostrum.com> In-Reply-To: From: Ted Hardie Date: Tue, 7 Jul 2020 07:02:34 -0700 Message-ID: To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Cc: Ben Campbell , Dispatch WG Content-Type: multipart/alternative; boundary="0000000000000c26b105a9da73ec" Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 14:03:05 -0000 --0000000000000c26b105a9da73ec Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Martin, Suggested re-wording below. On Tue, Jul 7, 2020 at 12:34 AM Martin J. D=C3=BCrst wrote: > On 23/06/2020 07:51, Ben Campbell wrote: > > Hi Everyone, > > > > The ART ADs have reminded the chairs that our charter allows us to adop= t > =E2=80=9Csimple administrative=E2=80=9D work such as IANA registration do= cuments. This > draft seems to fit squarely in that category. Does anyone see a reason we > shouldn=E2=80=99t just adopt it, with the expectation of going immediatel= y to WGLC? > (The last-call timeline is the same either way, either 2 weeks WGLC and 2 > weeks IETF LC for a working group draft, or 4 weeks IETF LC for an AD > sponsored draft.) > > Triggered by the recent discussion, I had a look at Ted's draft and the > mail up to today. To me, both AD sponsored and Dispatch WG look > reasonable, with a slight preference for the former (if asked to express > such a preference). > > With respect to "pending registrations", I do not think these are > relevant, in particular because the thing in question isn't actually a > scheme, as discussed on the relevant list. > > I have one comment: The abstract currently reads > "This document removes references to the IETF tree of URI registrations > for registrations in URI.ARPA.". Would "This document removes references to the IETF tree of URI registrations from the procedures for requesting that a URI scheme be inserted into the uri.arpa zone." work for you? regards, Ted I found this hard to read, and I guess > it's because of the "registrations for registrations" piece. Unless one > is very familiar with the matter at hand, it's easy to think that both > occurrences of "registration" are referencing the same thing. While I'm > at it, it would also be good if the abstract mentioned something > positive. I think a less normative version of (the single sentence that > is) Section 2 would serve well as the abstract. > > Regards, Martin. > > > Thanks! > > > > Ben (as co-chair) > > > >> On Jun 3, 2020, at 6:13 PM, Ted Hardie wrote: > >> > >> Howdy, > >> > >> This is one the shortest drafts I've ever written: > https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ < > https://datatracker.ietf..org/doc/draft-hardie-dispatch-rfc3405-update/> > .. Basically, RFC 3405 used to require that registrations in URI.ARPA b= e > from the "IETF Tree". That tree was deprecated after the document was > published. As it happens, there are very few registrations in URI.ARPA, = so > we did not catch it and fix it before now. > >> > >> This draft updates RFC 3405 to require "permanent" scheme > registrations. The salient bit is this: > >> > >> All registrations in URI.ARPA MUST be for schemes which are permanent > >> registrations, as they are described in BCP 35. > >> > >> I'm hoping for a quick dispatch of this, but happy to discuss. > >> > >> regards, > >> > >> Ted Hardie > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > > > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > > -- > Prof. Dr.sc. Martin J. D=C3=BCrst > Department of Intelligent Information Technology > College of Science and Engineering > Aoyama Gakuin University > Fuchinobe 5-1-10, Chuo-ku, Sagamihara > 252-5258 Japan > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --0000000000000c26b105a9da73ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Martin,

= Suggested re-wording below.

<= div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jul 7, 2020 at 12:34 AM Martin= J. D=C3=BCrst <duerst@it.aoya= ma.ac.jp> wrote:
On 23/06/2020 07:51, Ben Campbell wrote:
> Hi Everyone,
>
> The ART ADs have reminded the chairs that our charter allows us to ado= pt =E2=80=9Csimple administrative=E2=80=9D work such as IANA registration d= ocuments. This draft seems to fit squarely in that category. Does anyone se= e a reason we shouldn=E2=80=99t just adopt it, with the expectation of goin= g immediately to WGLC? (The last-call timeline is the same either way, eith= er 2 weeks WGLC and 2 weeks IETF LC for a working group draft, or 4 weeks I= ETF LC for an AD sponsored draft.)

Triggered by the recent discussion, I had a look at Ted's draft and the=
mail up to today. To me, both AD sponsored and Dispatch WG look
reasonable, with a slight preference for the former (if asked to express such a preference).

With respect to "pending registrations", I do not think these are=
relevant, in particular because the thing in question isn't actually a =
scheme, as discussed on the relevant list.

I have one comment: The abstract currently reads
"This document removes references to the IETF tree of URI registration= s
for registrations in URI.ARPA.".

Woul= d "This document removes references to the IETF tree of URI registrati= ons from the procedures for requesting that a URI scheme be inserted into t= he uri.arpa zone." work for you?
=C2=A0
regard= s,

Ted

I found this hard to read, and I guess
it's because of the "registrations for registrations" piece. = Unless one
is very familiar with the matter at hand, it's easy to think that both =
occurrences of "registration" are referencing the same thing. Whi= le I'm
at it, it would also be good if the abstract mentioned something
positive. I think a less normative version of (the single sentence that is) Section 2 would serve well as the abstract.

Regards,=C2=A0 =C2=A0Martin.

> Thanks!
>
> Ben (as co-chair)
>
>> On Jun 3, 2020, at 6:13 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
>>
>> Howdy,
>>
>> This is one the shortest drafts I've ever written:=C2=A0 https://datatracker.ietf.org/doc/dr= aft-hardie-dispatch-rfc3405-update/ <https://datatracker.ietf..o= rg/doc/draft-hardie-dispatch-rfc3405-update/> ..=C2=A0 =C2=A0Basically, = RFC 3405 used to require that registrations in URI.ARPA be from the "I= ETF Tree".=C2=A0 That tree was deprecated after the document was publi= shed.=C2=A0 As it happens, there are very few registrations in URI.ARPA, so= we did not catch it and fix it before now.
>>
>> This draft updates RFC 3405 to require "permanent" schem= e registrations.=C2=A0 The salient bit is this:
>>
>> All registrations in URI.ARPA MUST be for schemes which are perman= ent
>>=C2=A0 =C2=A0 =C2=A0registrations, as they are described in BCP 35.=
>>
>> I'm hoping for a quick dispatch of this, but happy to discuss.=
>>
>> regards,
>>
>> Ted Hardie
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ie= tf.org
>> https://www.ietf.org/mailman/listinfo/dispatc= h
>
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/dispatch
>

--
Prof. Dr.sc. Martin J. D=C3=BCrst
Department of Intelligent Information Technology
College of Science and Engineering
Aoyama Gakuin University
Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--0000000000000c26b105a9da73ec-- From nobody Tue Jul 7 07:03:37 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D073A0CEB for ; Tue, 7 Jul 2020 07:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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 AygZBy8Lj417 for ; Tue, 7 Jul 2020 07:03:34 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (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 281E43A0CE9 for ; Tue, 7 Jul 2020 07:03:34 -0700 (PDT) Received: from oxuslxaltgw04.schlund.de ([10.72.76.60]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1MsqQu-1klkE93HyK-00tGdR; Tue, 07 Jul 2020 16:03:17 +0200 Date: Tue, 7 Jul 2020 10:03:17 -0400 (EDT) From: Timothy Mcsweeney Reply-To: Timothy Mcsweeney To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= , Ben Campbell , Dispatch WG , Patrick McManus Message-ID: <1580898449.190942.1594130597348@email.ionos.com> In-Reply-To: References: <85664807-701C-4700-ABB7-D0434F14D6A0@nostrum.com> MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.1-Rev31 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:FTSr+7BIKZJt+CEktOOii1FPksC1iftKPjJqArZepmmcZzE4QZr kw6UwRt4mIq2BUjRt0Efi17RNdtFqa1x9Qc1oU7O/vqWNQL5JXUld0xTI2rzaeNWthCLizJ MmTM/xwnT5Z2EtNIJxjgEXMXGWWa9Sn3jzO6MqZY3Cl9YIjcghFIh0Yea6JGgQVgEEmyp8m AtkPMY5inxm7ex03p2wLQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:sP1Gom8S87c=:3Um3WFlxvlNkJWmIdfe6Yu qLEw8if3L8ipfGqqj0QajraiKCRtjRro62rIGtsT3x3J/fKmekKA3jG9dZPtl+K4DQTmh/5PF 1oW/QM4X8dxRu0ZZmEjs5Lap7Y3PgEUWECNpcvp5l6GGJicxvB14cD5VRfHvKpPqhvrUUDqqG YaRn7UsFr0sIzx32PCsQFrhY0s0yD+ncbRUVjQebBffHQjdB7L8gDQgDTBLFTeTKGirIAHsTA raqTFnIBZICxgU+DYQ+S9qqeZQdIll9vmkhnf61BYa2a4EGn0vUqVLFKpR/HrEoOjegPxpTb3 CeHyRM4d+YXMLHVcMa1GS8LBGHy8a9Uoi2N7ywwq4/gQmCB54cn33mrIubFwX8AbDmq+lrXaZ MuI61L+GmQnKqr+UwwL+yTj5yfSX46e9HM11KsJwdBxHtwuxKaKnwwozVCFznsxJi3g6q34h/ /xss5zDm2BONHDbEBrHHFbkSr07mqqTmfW3raED6xh8Sj9xSDSdFVp/EcLtKpI8n1wnjDGvhE hMKBbBfG/43xRoFLH4obp72BBpSWTM9CXGbatWlt/vElnyamnrhsXmmVZpNsLlhkLpsKQfUnY REXKvOctcK6/H/SspQi6LONu0HsJzcbDI1tUB1wFEkvbJ9iAGkX5bLEhCFLu0gLKRPrR9nusT C478vAS8CYqh3/HZRTvMyx+i6YydgZSHZXfeNJQgetgLevRhnnUwxN8NmlzPwoo9sAgwU0Kdi AU8g9Wk4IcD53ne+kSCYPkTMARb76Sk/CVrLiGWi6EOmDujPE2YQAaEALGu4/n5D1RZSQvjOb 8MLDEJIO5wxPW063bEeSPXwtJWyK2fvQylkVVsqZapOZnTqQxztZoOeRqAd8OJgbWPyP7uZ Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 14:03:36 -0000 =20 =20
Hi All,

Updating RFC3405 will necessarily require changes to RFC3401 as stated = in its 
introduction.  "This document will be updated and or obsoleted whe= n changes=20
are made to the DDDS specifications."

We are now changing two RFCs so I don't think this fits as a=20
"simple administrative".

But, I may have a work around that is simple and also solves the provis= ional registration problem as stated by Ted.  I could have ready in a = day or so.

Tim
On July 7, 2020 at 3:34 AM "Martin J. D=C3=BCrst" < duerst@it.aoyama.ac.jp>= ; wrote:


On 23/06/2020 07:51, Ben Campbell wrote:
Hi Everyone,

The ART ADs have reminded the chairs that our charter allows us to ado= pt =E2=80=9Csimple administrative=E2=80=9D work such as IANA registration d= ocuments. This draft seems to fit squarely in that category. Does anyone se= e a reason we shouldn=E2=80=99t just adopt it, with the expectation of goin= g immediately to WGLC? (The last-call timeline is the same either way, eith= er 2 weeks WGLC and 2 weeks IETF LC for a working group draft, or 4 weeks I= ETF LC for an AD sponsored draft.)

Triggered by the recent discussion, I had a look at Ted's draft and the
mail up to today. To me, both AD sponsored and Dispatch WG look
reasonable, with a slight preference for the former (if asked to expres= s
such a preference).

With respect to "pending registrations", I do not think these are
relevant, in particular because the thing in question isn't actually a
scheme, as discussed on the relevant list.

I have one comment: The abstract currently reads
"This document removes references to the IETF tree of URI registrations
for registrations in URI.ARPA.". I found this hard to read, and I guess
it's because of the "registrations for registrations" piece. Unless one
is very familiar with the matter at hand, it's easy to think that both
occurrences of "registration" are referencing the same thing. While I'm
at it, it would also be good if the abstract mentioned something
positive. I think a less normative version of (the single sentence that
is) Section 2 would serve well as the abstract.

Regards, Martin.

Thanks!

Ben (as co-chair)

On Jun 3, 2020, at 6:13 PM, Ted Hardie < ted.ietf@gmail.com> wrot= e:

Howdy,

This is one the shortest drafts I've ever written:=20 https://datatracker.ietf.o= rg/doc/draft-hardie-dispatch-rfc3405-update/ < https://datatracker.ietf.= .org/doc/draft-hardie-dispatch-rfc3405-update/> .. Basically, RFC 34= 05 used to require that registrations in URI.ARPA be from the "IETF Tree". = That tree was deprecated after the document was published. As it happens, t= here are very few registrations in URI.ARPA, so we did not catch it and fix= it before now.

This draft updates RFC 3405 to require "permanent" scheme registratio= ns. The salient bit is this:

All registrations in URI.ARPA MUST be for schemes which are permanent
registrations, as they are described in BCP 35.

I'm hoping for a quick dispatch of this, but happy to discuss.

regards,

Ted Hardie
_______________________________________________
dispatch mailing list



_______________________________________________
dispatch mailing list


--
Prof. Dr.sc. Martin J. D=C3=BCrst
Department of Intelligent Information Technology
College of Science and Engineering
Aoyama Gakuin University
Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan

_______________________________________________
dispatch mailing list
=20 From nobody Wed Jul 8 19:36:38 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F513A0CC5 for ; Wed, 8 Jul 2020 19:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, MAY_BE_FORGED=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 HBmkObQvs5zx for ; Wed, 8 Jul 2020 19:36:35 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 733AA3A0CC0 for ; Wed, 8 Jul 2020 19:36:35 -0700 (PDT) Received: from bens-macbook.lan (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 0692aSms092705 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 8 Jul 2020 21:36:30 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1594262190; bh=kdo2BSg9+G0gJ6Z1rUJ/YZaoIKDcJmo6Z5S/Y2Dk3Q8=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=m2fl4UCB2RgBNjdQZnKTG4fZWchtHM8shEpIoMU0S0cPM6SWhuiBdvjCTtNGsENko Y/E36TrvMnX/gwgYQwdEuxTR+GRVuRBB1M4u/SBCLc2LdpZWYUKoQo/bfrfCea/TiJ 4EnbJW2qe0Tgo47eaYC90JP+wuso50M9nk3h5S6A= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be bens-macbook.lan Content-Type: multipart/alternative; boundary="Apple-Mail=_65BE27A9-8166-4E12-A149-4382677506C5" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Ben Campbell X-Priority: 3 In-Reply-To: <1580898449.190942.1594130597348@email.ionos.com> Date: Wed, 8 Jul 2020 21:36:20 -0500 Cc: Patrick McManus , DISPATCH WG Message-Id: <3A1C3068-717D-4822-A110-9F91272B04CB@nostrum.com> References: <85664807-701C-4700-ABB7-D0434F14D6A0@nostrum.com> <1580898449.190942.1594130597348@email.ionos.com> To: Timothy Mcsweeney X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2020 02:36:37 -0000 --Apple-Mail=_65BE27A9-8166-4E12-A149-4382677506C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Tim, Do you plan to submit an internet-draft? If so, please be advised that = the deadline for drafts prior to IETF108 is this coming Monday (7/13). = If you submit a draft prior to the deadline, we can consider it along = with Ted=E2=80=99s draft (either on the list or possibly in the IETF108 = DISPATCH meeting). Thanks, Ben. > On Jul 7, 2020, at 9:03 AM, Timothy Mcsweeney = wrote: >=20 > Hi All, >=20 > Updating RFC3405 will necessarily require changes to RFC3401 as stated = in its=20 > introduction. "This document will be updated and or obsoleted when = changes > are made to the DDDS specifications." >=20 > We are now changing two RFCs so I don't think this fits as a > "simple administrative". >=20 > But, I may have a work around that is simple and also solves the = provisional registration problem as stated by Ted. I could have ready = in a day or so. >=20 > Tim >> On July 7, 2020 at 3:34 AM "Martin J. D=C3=BCrst" < = duerst@it.aoyama.ac.jp > wrote: >>=20 >>=20 >> On 23/06/2020 07:51, Ben Campbell wrote: >>> Hi Everyone, >>>=20 >>> The ART ADs have reminded the chairs that our charter allows us to = adopt =E2=80=9Csimple administrative=E2=80=9D work such as IANA = registration documents. This draft seems to fit squarely in that = category. Does anyone see a reason we shouldn=E2=80=99t just adopt it, = with the expectation of going immediately to WGLC? (The last-call = timeline is the same either way, either 2 weeks WGLC and 2 weeks IETF LC = for a working group draft, or 4 weeks IETF LC for an AD sponsored = draft.) >>=20 >> Triggered by the recent discussion, I had a look at Ted's draft and = the >> mail up to today. To me, both AD sponsored and Dispatch WG look >> reasonable, with a slight preference for the former (if asked to = express >> such a preference). >>=20 >> With respect to "pending registrations", I do not think these are >> relevant, in particular because the thing in question isn't actually = a >> scheme, as discussed on the relevant list. >>=20 >> I have one comment: The abstract currently reads >> "This document removes references to the IETF tree of URI = registrations >> for registrations in URI.ARPA.". I found this hard to read, and I = guess >> it's because of the "registrations for registrations" piece. Unless = one >> is very familiar with the matter at hand, it's easy to think that = both >> occurrences of "registration" are referencing the same thing. While = I'm >> at it, it would also be good if the abstract mentioned something >> positive. I think a less normative version of (the single sentence = that >> is) Section 2 would serve well as the abstract. >>=20 >> Regards, Martin. >>=20 >>> Thanks! >>>=20 >>> Ben (as co-chair) >>>=20 >>>> On Jun 3, 2020, at 6:13 PM, Ted Hardie < ted.ietf@gmail.com = > wrote: >>>>=20 >>>> Howdy, >>>>=20 >>>> This is one the shortest drafts I've ever written: = https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ = = >= .. Basically, RFC 3405 used to require that registrations in URI.ARPA = be from the "IETF Tree". That tree was deprecated after the document was = published. As it happens, there are very few registrations in URI.ARPA, = so we did not catch it and fix it before now. >>>>=20 >>>> This draft updates RFC 3405 to require "permanent" scheme = registrations. The salient bit is this: >>>>=20 >>>> All registrations in URI.ARPA MUST be for schemes which are = permanent >>>> registrations, as they are described in BCP 35. >>>>=20 >>>> I'm hoping for a quick dispatch of this, but happy to discuss. >>>>=20 >>>> regards, >>>>=20 >>>> Ted Hardie >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch = >>>=20 >>>=20 >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch = >>>=20 >>=20 >> -- >> Prof. Dr.sc. Martin J. D=C3=BCrst >> Department of Intelligent Information Technology >> College of Science and Engineering >> Aoyama Gakuin University >> Fuchinobe 5-1-10, Chuo-ku, Sagamihara >> 252-5258 Japan >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch = __________________________= _____________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail=_65BE27A9-8166-4E12-A149-4382677506C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Tim,

Do you plan to = submit an internet-draft? If so, please be advised that the deadline for = drafts prior to IETF108 is this coming Monday (7/13). If you submit a = draft prior to the deadline, we can consider it along with Ted=E2=80=99s = draft (either on the list or possibly in the IETF108 DISPATCH = meeting).

Thanks,

Ben.

On Jul 7, 2020, at 9:03 AM, = Timothy Mcsweeney <tim@dropnumber.com> wrote:

=20 =20 =20
Hi All,

Updating RFC3405 will necessarily require changes to RFC3401 as = stated in its 
introduction.  "This document will be updated and or obsoleted = when changes=20
are made to the DDDS specifications."

We are now changing two RFCs so I don't think this fits as a=20
"simple administrative".

But, I may have a work around that is simple and also solves the = provisional registration problem as stated by Ted.  I could have = ready in a day or so.

Tim
On July 7, 2020 at 3:34 AM "Martin J. D=C3=BCrst" < duerst@it.aoyama.ac.jp> wrote:


On 23/06/2020 07:51, Ben Campbell wrote:
Hi Everyone,

The ART ADs have reminded the chairs that our charter allows us to = adopt =E2=80=9Csimple administrative=E2=80=9D work such as IANA = registration documents. This draft seems to fit squarely in that = category. Does anyone see a reason we shouldn=E2=80=99t just adopt it, = with the expectation of going immediately to WGLC? (The last-call = timeline is the same either way, either 2 weeks WGLC and 2 weeks IETF LC = for a working group draft, or 4 weeks IETF LC for an AD sponsored = draft.)

Triggered by the recent discussion, I had a look at Ted's draft and = the
mail up to today. To me, both AD sponsored and Dispatch WG look
reasonable, with a slight preference for the former (if asked to = express
such a preference).

With respect to "pending registrations", I do not think these are
relevant, in particular because the thing in question isn't actually = a
scheme, as discussed on the relevant list.

I have one comment: The abstract currently reads
"This document removes references to the IETF tree of URI = registrations
for registrations in URI.ARPA.". I found this hard to read, and I = guess
it's because of the "registrations for registrations" piece. Unless = one
is very familiar with the matter at hand, it's easy to think that = both
occurrences of "registration" are referencing the same thing. While = I'm
at it, it would also be good if the abstract mentioned something
positive. I think a less normative version of (the single sentence = that
is) Section 2 would serve well as the abstract.

Regards, Martin.

Thanks!

Ben (as co-chair)

On Jun 3, 2020, at 6:13 PM, Ted Hardie < ted.ietf@gmail.com> wrote:

Howdy,

This is one the shortest drafts I've ever written:=20 https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-= update/ < https://datatracker.ietf...org/doc/draft-hardie-dispatch-rfc340= 5-update/> .. Basically, RFC 3405 used to require that = registrations in URI.ARPA be from the "IETF Tree". That tree was = deprecated after the document was published. As it happens, there are = very few registrations in URI.ARPA, so we did not catch it and fix it = before now.

This draft updates RFC 3405 to require "permanent" scheme = registrations. The salient bit is this:

All registrations in URI.ARPA MUST be for schemes which are = permanent
registrations, as they are described in BCP 35.

I'm hoping for a quick dispatch of this, but happy to discuss.

regards,

Ted Hardie
_______________________________________________
dispatch mailing list



_______________________________________________
dispatch mailing list


--
Prof. Dr.sc. Martin J. D=C3=BCrst
Department of Intelligent Information Technology
College of Science and Engineering
Aoyama Gakuin University
Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan

_______________________________________________
dispatch mailing list
=20
_______________________________________________
dispatch = mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

= --Apple-Mail=_65BE27A9-8166-4E12-A149-4382677506C5-- From nobody Thu Jul 9 07:20:27 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E65603A0BC7 for ; Thu, 9 Jul 2020 07:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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 1YMZ_fNlbrdw for ; Thu, 9 Jul 2020 07:20:23 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (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 365723A0B8F for ; Thu, 9 Jul 2020 07:20:23 -0700 (PDT) Received: from oxusgaltgw04.schlund.de ([10.72.72.50]) by mrelay.perfora.net (mreueus002 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MehbC-1kHpa74BHk-00OKEu; Thu, 09 Jul 2020 16:20:12 +0200 Date: Thu, 9 Jul 2020 10:20:10 -0400 (EDT) From: Timothy Mcsweeney Reply-To: Timothy Mcsweeney To: Ben Campbell Cc: Patrick McManus , DISPATCH WG Message-ID: <2116535970.9156.1594304410818@email.ionos.com> In-Reply-To: <3A1C3068-717D-4822-A110-9F91272B04CB@nostrum.com> References: <85664807-701C-4700-ABB7-D0434F14D6A0@nostrum.com> <1580898449.190942.1594130597348@email.ionos.com> <3A1C3068-717D-4822-A110-9F91272B04CB@nostrum.com> MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.1-Rev32 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:9lJ7ix/PAxXM5q1oHqypz7mgcZDEQipuunGhlpxmD0plLqpPNmN TBevYTzp8qNGXGvo/O0a2MBX+kMw63LSrVBojh8Rf75zFCeXldLPOPicOF7P+dbgw0EGtez y+soXg7DaIsBu0pz/gYcbYs56VwdXnuYk57//WUH67ca9H+vSPKYZuimEFUlJ97iLxFlZoo iZfOvH/dovoJatEJAUPVA== X-UI-Out-Filterresults: notjunk:1;V03:K0:LANALAv1Omw=:K7v/tN68PHVZq1XQSxdfTb 0Fojw81xSwDUKqptIAHfXcC8DTip9/v0cfXUhW9mBY7GcegBw0ZZ8FYP4X6ozvmqAgJGjscks Lz3W03Oc9QlxekECyuPDoGWp0Cl9HZ8u9BuA5BPT9Y+7mLZwFARA61TQ3p4g8I8tLYtnTdY0+ oVxX77XZmWTHVdF+BmueGINgCxLYgWJTxACemEY0eNdznzE+23yai59GG2F9Ny1ZLYgW6LjQR ep8ERlr/DKjiRpaZRmp0GAnBU27RcgoDhRQNtks+0DZ+jsOKZs8Kb+1CBlYjNUfxtPWzwuFLK G/NAXtC4HuaqQxwQlzhEjTQHZPo7yEqchfAeHcJfzh78uhlHiz5B6SkYgOokEeuKN/mIwrmUX d8NRueus0hfGdf5TiI3heUAao0zU3UtZ48wRZyu2spVcToJO0suByg7rylxEC5ooxi9iQWxIE NEcRlBNmAl0sBVe/kyz8SHw5dW3PqOwUBMVawlKADX51oUSU5055/WLg1Fha7QGt9kaJzPpak Yf2sCAs4Jlahjx0yrO/Vx9eH8yKzNNNLoQfC7pktRA5BdSrRZKnbRwARLzzxHAwd4WvwxamFh MNboQNhZEL7jmmcX0RVOrjXRNNPYZq0C+snZVlIxgQK3UmzoA6HMrvNCVPNUzauruVRiZomU1 h8YTfMeGZq5EbkGdonW+TlL1aGTFbuZK2VilEbb6zVm9TNJFjc1dXFPI0hHFhD9HshqSsTJ/S Gxu1iISPY9pDDCOpQSojU8fr98XAcNjtpdVyLCNF0jfMN/R7pWJRLih2wjKRmQNxFZZ2NBPzk vLeTo2QyZkwOlI2Ke7BIqQAHL7aBaA/pFVw+zEBROsDi4c5CKadMeqAEJPWuPsZvBFf+KRC Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2020 14:20:25 -0000 =20 =20
Hi Ben, 

Thanks for the heads up on the deadline,

I am a little surprised that you are choosing to discuss this at all wit= h pending 
registrations and I obviously disagree with that.  But if there are= more than 5 people besides Ted that think the current rules for provisiona= ls in the zone are
too open and need to be further constrained then I will submit a d= raft that does
just that before the deadline. 


On July 8, 2020 at 10:36 PM Ben Campbell <ben@nostrum.com> wrote:= =20

Hi Tim,

Do you plan to submit an internet-draft? If so, please be advised that = the deadline for drafts prior to IETF108 is this coming Monday (7/13). If y= ou submit a draft prior to the deadline, we can consider it along with Ted= =E2=80=99s draft (either on the list or possibly in the IETF108 DISPATCH me= eting).

Thanks,

Ben.=20

On Jul 7, 2020, at 9:03 AM, Timothy Mcsweeney <=20 tim@dropnumber.com<= /a>> wrote:

Hi All,

Updating RFC3405 will necessarily require changes to RFC3401 as s= tated in its 
introduction.  "This document will be updated and or obsolet= ed when changes
are made to the DDDS specifications."

We are now changing two RFCs so I don't think this fits as a
"simple administrative".

But, I may have a work around that is simple and also solves the = provisional registration problem as stated by Ted.  I could have ready= in a day or so.

Tim


On 23/06/2020 07:51, Ben Campbell wrote:
Hi Everyone,

The ART ADs have reminded the chairs that our charter allows us = to adopt =E2=80=9Csimple administrative=E2=80=9D work such as IANA registra= tion documents. This draft seems to fit squarely in that category. Does any= one see a reason we shouldn=E2=80=99t just adopt it, with the expectation o= f going immediately to WGLC? (The last-call timeline is the same either way= , either 2 weeks WGLC and 2 weeks IETF LC for a working group draft, or 4 w= eeks IETF LC for an AD sponsored draft.)

Triggered by the recent discussion, I had a look at Ted's draft a= nd the
mail up to today. To me, both AD sponsored and Dispatch WG look
reasonable, with a slight preference for the former (if asked to = express
such a preference).

With respect to "pending registrations", I do not think these are
relevant, in particular because the thing in question isn't actua= lly a
scheme, as discussed on the relevant list.

I have one comment: The abstract currently reads
"This document removes references to the IETF tree of URI registr= ations
for registrations in URI.ARPA.". I found this hard to read, and I= guess
it's because of the "registrations for registrations" piece. Unle= ss one
is very familiar with the matter at hand, it's easy to think that= both
occurrences of "registration" are referencing the same thing. Whi= le I'm
at it, it would also be good if the abstract mentioned something
positive. I think a less normative version of (the single sentenc= e that
is) Section 2 would serve well as the abstract.

Regards, Martin.

Thanks!

Ben (as co-chair)

On Jun 3, 2020, at 6:13 PM, Ted Hardie <=20 ted.ietf@gmail= .com> wrote:

Howdy,

This is one the shortest drafts I've ever written:=20 https://d= atatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ <=20 https://= datatracker.ietf...org/doc/draft-hardie-dispatch-rfc3405-update/> ..= Basically, RFC 3405 used to require that registrations in URI.ARPA be from= the "IETF Tree". That tree was deprecated after the document was published= . As it happens, there are very few registrations in URI.ARPA, so we did no= t catch it and fix it before now.

This draft updates RFC 3405 to require "permanent" scheme regis= trations. The salient bit is this:

All registrations in URI.ARPA MUST be for schemes which are per= manent
registrations, as they are described in BCP 35.

I'm hoping for a quick dispatch of this, but happy to discuss.

regards,

Ted Hardie
_______________________________________________
dispatch mailing list



_______________________________________________
dispatch mailing list


--
Prof. Dr.sc. Martin J. D=C3=BCrst
Department of Intelligent Information Technology
College of Science and Engineering
Aoyama Gakuin University
Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan

_______________________________________________
dispatch mailing list
_______________________________________________=20
dispatch mailing list=20
dispatch@ietf.org=20
https://www.ietf.org/mailman/listinfo/dispatch=20


 
=20 From nobody Thu Jul 9 08:58:06 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79EDC3A0C9C for ; Thu, 9 Jul 2020 08:58:04 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 13C_HTJV0-h5 for ; Thu, 9 Jul 2020 08:58:01 -0700 (PDT) Received: from mail-ot1-x344.google.com (mail-ot1-x344.google.com [IPv6:2607:f8b0:4864:20::344]) (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 A33E63A0D18 for ; Thu, 9 Jul 2020 08:58:01 -0700 (PDT) Received: by mail-ot1-x344.google.com with SMTP id 18so2040018otv.6 for ; Thu, 09 Jul 2020 08:58:01 -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=ZxPAj3bpSUjoZPbxKqYIsIyUKZT+54XZnY0uchBXDyw=; b=AFM47QGXTNB6TvlwqAN2apBWsyhpE0BQmG/9JRELcHjShiCdJz4zVhCjDiNGNWvMV8 XASR8vOCAkgdMx8fHjQNZNF4q3u5IsE/EK+fyEHeK/I2RUUdl7oUwvuva4Ws7kCCCudN wogqeLmqAHxZO5vXv2u34+UzFFPwMmuugIOOglYpbR7gYirtgzMp2qJ35Tt/0GKygunI UF5kAh2Qtie6d2IJn3kCZ8wPwQJLH5LZVdlfDvpT1iRYb9B7ehJprn5bEAKOVrlyWjFj ze2BPecgDZ3CN9E1+H+3bH/TAMmeRqG54KReqdrBHIu+0dFac8ZT3zJJP44BjE0drUVl N1Nw== 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=ZxPAj3bpSUjoZPbxKqYIsIyUKZT+54XZnY0uchBXDyw=; b=QnYk50/2kirYAGZHz/08jHpTQPMCYHMPYB3L96QZh8BiHCOmOmIUEeSt7YAKwitx4K Kk1MTRLN0SBTKGvML+T3DOsuz+/GLy/XGujX3W0pPaIlun4jv7PhI2gcExMX1o52N8ZX Gj0f4xFL5RhivKvogXPNB8LM91VIecxFl/enb/GhpFnwPrfL/+OkVfCR/dpzGsVbvg9r LH0QWU+uA0FcfDqFWanSt47mYqHMUV5yZV/G/Iu125xNcnf3A64p/uIkynS9JF6gxPK7 Uzo7M4knVLBy47QrmPt6cpBPqNt1X88//5qLE/8FpyH+647uCUICOiBpPGnyr5IgYyR5 41MA== X-Gm-Message-State: AOAM533GNv5t1U0sxSqBufSwK4/iiJZf7p2UBXxX1kr5VC63toxR/rjp oHgg2/fJv1jASJ/zKQRItmJyHQyelARe7LBw2HQ= X-Google-Smtp-Source: ABdhPJxYx2KrDuh7hatxSpqW4Ptt+e8DzlLjwgizwGV7ubWVN+7XKbKTcKzo9yIUtw97tI7ij1OaqmdJ1jPUaoACQpc= X-Received: by 2002:a9d:2cc:: with SMTP id 70mr13855667otl.269.1594310280677; Thu, 09 Jul 2020 08:58:00 -0700 (PDT) MIME-Version: 1.0 References: <85664807-701C-4700-ABB7-D0434F14D6A0@nostrum.com> <1580898449.190942.1594130597348@email.ionos.com> <3A1C3068-717D-4822-A110-9F91272B04CB@nostrum.com> <2116535970.9156.1594304410818@email.ionos.com> In-Reply-To: <2116535970.9156.1594304410818@email.ionos.com> From: Ted Hardie Date: Thu, 9 Jul 2020 08:57:34 -0700 Message-ID: To: Timothy Mcsweeney Cc: Ben Campbell , Patrick McManus , DISPATCH WG Content-Type: multipart/alternative; boundary="000000000000f10e8405aa04496e" Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2020 15:58:05 -0000 --000000000000f10e8405aa04496e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Howdy, On Thu, Jul 9, 2020 at 7:20 AM Timothy Mcsweeney wrote= : > Hi Ben, > > Thanks for the heads up on the deadline, > > I am a little surprised that you are choosing to discuss this at all with > pending > registrations and I obviously disagree with that. But if there are more > than 5 people besides Ted that think the current rules for provisionals i= n > the zone > I don't think I've seen anyone but you argue that the current rules permit provisionals in the zone; if I have missed others reading the rules that way, I'd appreciate a pointer. I think, though, that the key thing is to get some clarity on what the rules should be after the elimination of the IETF tree. Since you obviously disagree with my proposal, having your alternative spelled in a draft does seem like the best way forward. Wherever dispatch sends the question would then have two clear proposals to choose between. regards, Ted Hardie > are > too open and need to be further constrained then I will submit a draft > that does > just that before the deadline. > > > On July 8, 2020 at 10:36 PM Ben Campbell wrote: > > Hi Tim, > > Do you plan to submit an internet-draft? If so, please be advised that th= e > deadline for drafts prior to IETF108 is this coming Monday (7/13). If you > submit a draft prior to the deadline, we can consider it along with Ted= =E2=80=99s > draft (either on the list or possibly in the IETF108 DISPATCH meeting). > > Thanks, > > Ben. > > On Jul 7, 2020, at 9:03 AM, Timothy Mcsweeney < tim@dropnumber.com> > wrote: > > Hi All, > > Updating RFC3405 will necessarily require changes to RFC3401 as stated in > its > introduction. "This document will be updated and or obsoleted when > changes > are made to the DDDS specifications." > > We are now changing two RFCs so I don't think this fits as a > "simple administrative". > > But, I may have a work around that is simple and also solves the > provisional registration problem as stated by Ted. I could have ready in= a > day or so. > > Tim > > On July 7, 2020 at 3:34 AM "Martin J. D=C3=BCrst" < duerst@it.aoyama.ac.j= p> > wrote: > > > On 23/06/2020 07:51, Ben Campbell wrote: > > Hi Everyone, > > The ART ADs have reminded the chairs that our charter allows us to adopt > =E2=80=9Csimple administrative=E2=80=9D work such as IANA registration do= cuments. This > draft seems to fit squarely in that category. Does anyone see a reason we > shouldn=E2=80=99t just adopt it, with the expectation of going immediatel= y to WGLC? > (The last-call timeline is the same either way, either 2 weeks WGLC and 2 > weeks IETF LC for a working group draft, or 4 weeks IETF LC for an AD > sponsored draft.) > > > Triggered by the recent discussion, I had a look at Ted's draft and the > mail up to today. To me, both AD sponsored and Dispatch WG look > reasonable, with a slight preference for the former (if asked to express > such a preference). > > With respect to "pending registrations", I do not think these are > relevant, in particular because the thing in question isn't actually a > scheme, as discussed on the relevant list. > > I have one comment: The abstract currently reads > "This document removes references to the IETF tree of URI registrations > for registrations in URI.ARPA.". I found this hard to read, and I guess > it's because of the "registrations for registrations" piece. Unless one > is very familiar with the matter at hand, it's easy to think that both > occurrences of "registration" are referencing the same thing. While I'm > at it, it would also be good if the abstract mentioned something > positive. I think a less normative version of (the single sentence that > is) Section 2 would serve well as the abstract. > > Regards, Martin. > > Thanks! > > Ben (as co-chair) > > On Jun 3, 2020, at 6:13 PM, Ted Hardie < ted.ietf@gmail..com > > wrote: > > Howdy, > > This is one the shortest drafts I've ever written: > https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ < > https://datatracker.ietf...org/doc/draft-hardie-dispatch-rfc3405-update/ > = > > .. Basically, RFC 3405 used to require that registrations in URI.ARPA be > from the "IETF Tree". That tree was deprecated after the document was > published.. As it happens, there are very few registrations in URI.ARPA, = so > we did not catch it and fix it before now. > > This draft updates RFC 3405 to require "permanent" scheme registrations. > The salient bit is this: > > All registrations in URI.ARPA MUST be for schemes which are permanent > registrations, as they are described in BCP 35. > > I'm hoping for a quick dispatch of this, but happy to discuss. > > regards, > > Ted Hardie > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > -- > Prof. Dr.sc. Martin J. D=C3=BCrst > Department of Intelligent Information Technology > College of Science and Engineering > Aoyama Gakuin University > Fuchinobe 5-1-10, Chuo-ku, Sagamihara > 252-5258 Japan > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --000000000000f10e8405aa04496e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy,

=20 =20 =20
Hi Ben,=C2=A0

Thanks for the heads up on the deadline,

I am a little surprised that you are choosing to discuss this at all wit= h pending=C2=A0
registrations and I obviously disagree with that.=C2=A0 But if there are= more than 5 people besides Ted that think the current rules for provisiona= ls in the zone

I don't thi= nk I've seen anyone but you argue that the current rules permit provisi= onals in the zone; if I have missed others reading the rules that way, I= 9;d appreciate a pointer.

I think, though, that th= e key thing is to get some clarity on what the rules should be after the el= imination of the IETF tree.=C2=A0 Since you obviously disagree with my prop= osal, having your alternative spelled in a draft does seem like the best wa= y forward.=C2=A0 Wherever dispatch sends the question would then have two c= lear proposals to choose between.
=C2=A0
regards,

Ted Hardie
are
too open and need to be further constrained=C2=A0then I will submit a d= raft that does
just that before the deadline.=C2=A0


On July 8, 2020 at 10:36 PM Ben Campbell <ben@nostrum.com> wrote:=20

Hi Tim,

Do you plan to submit an internet-draft? If so, please be advised that = the deadline for drafts prior to IETF108 is this coming Monday (7/13). If y= ou submit a draft prior to the deadline, we can consider it along with Ted= =E2=80=99s draft (either on the list or possibly in the IETF108 DISPATCH me= eting).

Thanks,

Ben.=20

On Jul 7, 2020, at 9:03 AM, Timothy Mcsweeney <=20 tim@dropnumb= er.com> wrote:

Hi All,

Updating RFC3405 will necessarily require changes to RFC3401 as s= tated in its=C2=A0
introduction.=C2=A0 "This document will be updated and or ob= soleted when changes
are made to the DDDS specifications."

We are now changing two RFCs so I don't think this fits as a
"simple administrative".

But, I may have a work around that is simple and also solves the = provisional registration problem as stated by Ted.=C2=A0 I could have ready= in a day or so.

Tim
On July 7, 2020 at 3:34 AM "Martin J. D=C3=BCrst" <= =20 duers= t@it.aoyama.ac.jp> wrote:


On 23/06/2020 07:51, Ben Campbell wrote:
Hi Everyone,

The ART ADs have reminded the chairs that our charter allows us = to adopt =E2=80=9Csimple administrative=E2=80=9D work such as IANA registra= tion documents. This draft seems to fit squarely in that category. Does any= one see a reason we shouldn=E2=80=99t just adopt it, with the expectation o= f going immediately to WGLC? (The last-call timeline is the same either way= , either 2 weeks WGLC and 2 weeks IETF LC for a working group draft, or 4 w= eeks IETF LC for an AD sponsored draft.)

Triggered by the recent discussion, I had a look at Ted's dra= ft and the
mail up to today. To me, both AD sponsored and Dispatch WG look
reasonable, with a slight preference for the former (if asked to = express
such a preference).

With respect to "pending registrations", I do not think= these are
relevant, in particular because the thing in question isn't a= ctually a
scheme, as discussed on the relevant list.

I have one comment: The abstract currently reads
"This document removes references to the IETF tree of URI re= gistrations
for registrations in URI.ARPA.". I found this hard to read, = and I guess
it's because of the "registrations for registrations&quo= t; piece. Unless one
is very familiar with the matter at hand, it's easy to think = that both
occurrences of "registration" are referencing the same = thing. While I'm
at it, it would also be good if the abstract mentioned something
positive. I think a less normative version of (the single sentenc= e that
is) Section 2 would serve well as the abstract.

Regards, Martin.

Thanks!

Ben (as co-chair)

On Jun 3, 2020, at 6:13 PM, Ted Hardie <=20 ted.iet= f@gmail..com> wrote:

Howdy,

This is one the shortest drafts I've ever written:=20 https://datatracker.= ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ <=20 https://datatracker= .ietf...org/doc/draft-hardie-dispatch-rfc3405-update/> .. Basically,= RFC 3405 used to require that registrations in URI.ARPA be from the "= IETF Tree". That tree was deprecated after the document was published.= . As it happens, there are very few registrations in URI.ARPA, so we did no= t catch it and fix it before now.

This draft updates RFC 3405 to require "permanent" sc= heme registrations. The salient bit is this:

All registrations in URI.ARPA MUST be for schemes which are per= manent
registrations, as they are described in BCP 35.

I'm hoping for a quick dispatch of this, but happy to discu= ss.

regards,

Ted Hardie
_______________________________________________
dispatch mailing list



_______________________________________________
dispatch mailing list


--
Prof. Dr.sc. Martin J. D=C3=BCrst
Department of Intelligent Information Technology
College of Science and Engineering
Aoyama Gakuin University
Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan

_______________________________________________
dispatch mailing list
_______________________________________________=20
dispatch mailing list=20
dispatch@ietf= .org=20
https://www.ietf.org/mailman/listinfo/dispatch=20


=C2=A0
=20
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--000000000000f10e8405aa04496e-- From nobody Thu Jul 9 10:29:14 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6970E3A0D23 for ; Thu, 9 Jul 2020 10:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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 x34XvurwrFbz for ; Thu, 9 Jul 2020 10:29:09 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (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 76A3D3A0D22 for ; Thu, 9 Jul 2020 10:29:09 -0700 (PDT) Received: from oxusgaltgw04.schlund.de ([10.72.72.50]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0McDMP-1k9Bvi3JTD-00JawE; Thu, 09 Jul 2020 19:28:57 +0200 Date: Thu, 9 Jul 2020 13:28:57 -0400 (EDT) From: Timothy Mcsweeney Reply-To: Timothy Mcsweeney To: Ted Hardie Cc: Ben Campbell , Patrick McManus , DISPATCH WG Message-ID: <1777741348.21431.1594315737558@email.ionos.com> In-Reply-To: References: <85664807-701C-4700-ABB7-D0434F14D6A0@nostrum.com> <1580898449.190942.1594130597348@email.ionos.com> <3A1C3068-717D-4822-A110-9F91272B04CB@nostrum.com> <2116535970.9156.1594304410818@email.ionos.com> MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.1-Rev32 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:MHEMOx9RazoGaQIpci4MA4+um3AqR+O/joDmrgkINsjg4DDp1nA uvLFy0gt7Ow+ZVaS9v1MPohNdBXx4W2bjv54bfaf78/DOxEKzwhAAYT7tFGbobohOv5ZMjR OFeDJnX5Yi+aBFFOlvAfKxNW/UkvOmTV503h3F9zs7UvuT6Q83TEMdlbGkpKqK4fHuEf5Pf UJfeb7nlW5E8AkpKtP9DQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:3B6yDCCdj8w=:uzQ81y7lJgrvdirf9cSOar n7a6QjXSQFSh0Nr5SS72x/yf/LmT3ixpBupWVXadzJvBr1vxHNTlxWuxDhchgeJDwqwKAUND6 oHlJizE2uDEqZ7XaJ+RZjPSi13xql/DjffZ9tLUUqAthpiy6b0YxS3H355UGksEYEDfIlFuOc wAyyFHafCOIyj2NAOXtnYf25yZXVQylbebBIV0/9Ix/GWi9GKtB3uOIbDqCsQK3BHOGXZXdim 4DXkPymFvYxOeZnqGldfJxqG1lvttyeICFCSIIgkp+mRwSOU3ecN7donDtJfVIw0A7lPZ1iW3 AEWofnFiTjBtEyyOoNKYjUvk+mMuj0JWLYHYatSAmPSyzZdaPlTQ0HCZ+lKwnkptnUo/r4tp+ cp5cfyhzfvFHlPT7AltUky3RT28z5LDn9/lxiFdKARm20tgRJM+/9ax2iQxWuVXb3/4dWHZmB urH9+U/k1Li3NyrVck+h86JFZpbMcIL1v5bu3FK6QUuwCR0pNoU1R3gt6DSkijRBTbLOgJ6Ag 9p5nt2/aDDQUvdfijbXtyDUCOuqW18yQIbb1/MYufje/MhAhegbfH+NUBYmipSdFhKZPjuA07 iAwqhXcUF2X+yc/x8weDrHWl/T7gB+jd7vWkVd3sLfBn/obKg3mlzA5TKg8ErWKjKCUjD0GtX nSh8bMMTmiokevsQuWxRgUo+78dpsuHahrE9KEs9ZZRmqAhzjGsqNASomqQXDhdbXWEf4hjmp AhnkDR+gWiZuiuqAjSMeLELQgSBezcyOahoSjofQXAhmdbDLxDnkSuRqcI75F/vsMDN69CQH1 4ZTXINxFcbceCWUewKvVP2tUZMHB9lgbn2+Q5PCzxz+saNbB5nolMsefsEo4CX5ioZRuCSJ Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2020 17:29:12 -0000 =20 =20
Ted, 

Section 2 (Updated Requirements) of your draft says:
"All registrations in URI.ARPA MUST be for schemes which are permanent r= egistrations, as they are described in BCP 35."

I take that as:
We must update this because permanent registrations are not required.&nb= sp; Otherwise there is no reason for an update. =20

If you are going to argue both sides, my draft and I will just stay out = of it.  Here is your pointer.   https://www.ietf.org/id/draft-hardie-dispatch-rfc3405-up= date-01.html#section-2

Tim


On July 9, 2020 at 11:57 AM Ted Hardie <ted.ietf@gmail.com> wrote:= =20

Howdy,=20

On Thu, Jul 9, 2020 at 7:20 AM Timothy Mcsweeney <=20 tim@dropnumber.com> wrot= e:=20
Hi Ben, 

Thanks for the heads up on the deadline,

I am a little surprised that you are choosing to discuss this at al= l with pending 
registrations and I obviously disagree with that.  But if ther= e are more than 5 people besides Ted that think the current rules for provi= sionals in the zone

I don't think I've seen anyone but you argue that the current rules p= ermit provisionals in the zone; if I have missed others reading the rules t= hat way, I'd appreciate a pointer.

I think, though, that the key thing is to get some clarity on what th= e rules should be after the elimination of the IETF tree.  Since you o= bviously disagree with my proposal, having your alternative spelled in a dr= aft does seem like the best way forward.  Wherever dispatch sends the = question would then have two clear proposals to choose between.=20

regards,

Ted Hardie=20
are
too open and need to be further constrained then I will submit= a draft that does
just that before the deadline. 


On July 8, 2020 at 10:36 PM Ben Campbell <=20 ben@nostrum.com> wrote:=20

Hi Tim,

Do you plan to submit an internet-draft? If so, please be advised = that the deadline for drafts prior to IETF108 is this coming Monday (7/13).= If you submit a draft prior to the deadline, we can consider it along with= Ted=E2=80=99s draft (either on the list or possibly in the IETF108 DISPATC= H meeting).

Thanks,

Ben.=20

On Jul 7, 2020, at 9:03 AM, Timothy Mcsweeney <=20 tim@dropnumber.com> wrote:

Hi All,

Updating RFC3405 will necessarily require changes to RFC3401= as stated in its 
introduction.  "This document will be updated and or ob= soleted when changes
are made to the DDDS specifications."

We are now changing two RFCs so I don't think this fits as a
"simple administrative".

But, I may have a work around that is simple and also solves= the provisional registration problem as stated by Ted.  I could have = ready in a day or so.

Tim
On July 7, 2020 at 3:34 AM "Martin J. D=C3=BCrst" <=20 duerst@it.aoyama.ac.jp> wrote:


On 23/06/2020 07:51, Ben Campbell wrote:
Hi Everyone,

The ART ADs have reminded the chairs that our charter allow= s us to adopt =E2=80=9Csimple administrative=E2=80=9D work such as IANA reg= istration documents. This draft seems to fit squarely in that category. Doe= s anyone see a reason we shouldn=E2=80=99t just adopt it, with the expectat= ion of going immediately to WGLC? (The last-call timeline is the same eithe= r way, either 2 weeks WGLC and 2 weeks IETF LC for a working group draft, o= r 4 weeks IETF LC for an AD sponsored draft.)

Triggered by the recent discussion, I had a look at Ted's dr= aft and the
mail up to today. To me, both AD sponsored and Dispatch WG l= ook
reasonable, with a slight preference for the former (if aske= d to express
such a preference).

With respect to "pending registrations", I do not think thes= e are
relevant, in particular because the thing in question isn't = actually a
scheme, as discussed on the relevant list.

I have one comment: The abstract currently reads
"This document removes references to the IETF tree of URI re= gistrations
for registrations in URI.ARPA.". I found this hard to read, = and I guess
it's because of the "registrations for registrations" piece.= Unless one
is very familiar with the matter at hand, it's easy to think= that both
occurrences of "registration" are referencing the same thing= . While I'm
at it, it would also be good if the abstract mentioned somet= hing
positive. I think a less normative version of (the single se= ntence that
is) Section 2 would serve well as the abstract.

Regards, Martin.

Thanks!

Ben (as co-chair)

On Jun 3, 2020, at 6:13 PM, Ted Hardie <=20 ted.ietf@gmail..com> wrote:

Howdy,

This is one the shortest drafts I've ever written:=20 https://datatra= cker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ <=20 https://datatr= acker.ietf...org/doc/draft-hardie-dispatch-rfc3405-update/> .. Basic= ally, RFC 3405 used to require that registrations in URI.ARPA be from the "= IETF Tree". That tree was deprecated after the document was published.. As = it happens, there are very few registrations in URI.ARPA, so we did not cat= ch it and fix it before now.

This draft updates RFC 3405 to require "permanent" scheme = registrations. The salient bit is this:

All registrations in URI.ARPA MUST be for schemes which ar= e permanent
registrations, as they are described in BCP 35.

I'm hoping for a quick dispatch of this, but happy to disc= uss.

regards,

Ted Hardie
_______________________________________________
dispatch mailing list



_______________________________________________
dispatch mailing list


--
Prof. Dr.sc. Martin J. D=C3=BCrst
Department of Intelligent Information Technology
College of Science and Engineering
Aoyama Gakuin University
Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan

_______________________________________________
dispatch mailing list
_______________________________________________=20
dispatch mailing list=20
dispatch@ietf.org=20
https://www.ietf.org/mailman/listinfo/dispat= ch=20


 
_______________________________________________=20
dispatch mailing list=20
dispatch@ietf.org=20
https://www.ietf.org/mailman/listinfo/dispatch= =20

 
=20 From nobody Thu Jul 9 12:10:01 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408623A0DC4 for ; Thu, 9 Jul 2020 12:10:00 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 ddaPsqs0cr5P for ; Thu, 9 Jul 2020 12:09:57 -0700 (PDT) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 4DFAE3A079C for ; Thu, 9 Jul 2020 12:09:57 -0700 (PDT) Received: by mail-ot1-x32f.google.com with SMTP id 5so2440718oty.11 for ; Thu, 09 Jul 2020 12:09:57 -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=bIgmrSlZU7yYd4fwpjyYhwaFgYpUus7++/wdzgrRw6k=; b=PU49TQuq67u2ekFo5H/tQRb+dNT40mgj7QFy/7rbP62V6251YE4QVkRsZ6bkAutcUH 6qtaOqMkIg7GVIWaz1pBLFKQ1sJCwQgiIu04nKwyJnxCM8ERlGZC1/I8zDPPitC/RhkC RRUth1XmXX0J5gXMkL7ruSR1EjOJ/1amnwuRnKsaRRVv19m0qWkmajATcUXRioFxIubB xXjtGGyQkMewANTLOWl7lVk507yghbF8qWNNZixtFcB4AH0zZrfAA7aL/9f6lHfYTtyd 80fHPhZYedRtJ7tVk6zN4lP4XLJZMlkm+J6mpXlUq1xkUJVMLi0DEGKHEy27LvT368+q ns2w== 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=bIgmrSlZU7yYd4fwpjyYhwaFgYpUus7++/wdzgrRw6k=; b=cLgbAaZUgRCOFTjTX0sH3oUwMIOAmNW4Fi77bcJjOCDPbZkesmpr6p+yAm6+Fg4Tf8 VW6FN6Bq1VrFMDCCGjsW5lmZhLqXfB2SzCCggnEh57ncj5wWBJWJaa1rFg3UEED8AdDM puMuaEh2FemzT2u9yzZ/3w6+4SbCsb8MSawZh61Hrc2WhTeVl7bi657HRyF1BmMxvnCD Q5tGBcbubFytfcCrRviF9NtTGBbuKYGzmLh0U6LvS5TyLzmDaa7dar5QfeYeMP7DWLGJ PAiccG0zy5naf55ncqvCDAdmp/6NQSdGiYMbeg8dg0hdgDBGz8HEquCLVVUzBgsYu6De 2Odg== X-Gm-Message-State: AOAM533EmhygO8toH/CqZkqdYNd+Tvh06HLWGl0nhNMFUtH5Ym/ItOuJ E2pN09jT6teDx02TKk29DYAZJKzAnMFysqNQ3d0= X-Google-Smtp-Source: ABdhPJwM5hJeYDjOQx2MJc637u7d3vtMiuGd0SwwkI0r+AQUm2izbVwNluDku2JfAGEOBrvdYI2pzjJcf1IgbqCrviE= X-Received: by 2002:a9d:3f66:: with SMTP id m93mr35968775otc.49.1594321796443; Thu, 09 Jul 2020 12:09:56 -0700 (PDT) MIME-Version: 1.0 References: <85664807-701C-4700-ABB7-D0434F14D6A0@nostrum.com> <1580898449.190942.1594130597348@email.ionos.com> <3A1C3068-717D-4822-A110-9F91272B04CB@nostrum.com> <2116535970.9156.1594304410818@email.ionos.com> <1777741348.21431.1594315737558@email.ionos.com> In-Reply-To: <1777741348.21431.1594315737558@email.ionos.com> From: Ted Hardie Date: Thu, 9 Jul 2020 12:09:30 -0700 Message-ID: To: Timothy Mcsweeney Cc: Ben Campbell , Patrick McManus , DISPATCH WG Content-Type: multipart/alternative; boundary="00000000000055b1e305aa06f896" Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2020 19:10:00 -0000 --00000000000055b1e305aa06f896 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 9, 2020 at 10:28 AM Timothy Mcsweeney wrote: > Ted, > > Section 2 (Updated Requirements) of your draft says: > "All registrations in URI.ARPA MUST be for schemes which are permanent > registrations, as they are described in BCP 35." > > I take that as: > We must update this because permanent registrations are not required. > Otherwise there is no reason for an update. > The reason for the update is that IETF tree registrations *are* required. That effectively closes the registry, without the community having made the affirmative decision to do so. I want to fix that bug. I currently think that the closest replacement to the IETF tree would be permanent registration and that we should fix this by requiring that. But I'm happy to see a clear draft espousing some other way of fixing the bug; if you have an idea about that, please write the draft. regards, Ted > > If you are going to argue both sides, my draft and I will just stay out o= f > it. Here is your pointer. > https://www.ietf.org/id/draft-hardie-dispatch-rfc3405-update-01.html#sect= ion-2 > > Tim > > > On July 9, 2020 at 11:57 AM Ted Hardie wrote: > > Howdy, > > On Thu, Jul 9, 2020 at 7:20 AM Timothy Mcsweeney < tim@dropnumber.com> > wrote: > > Hi Ben, > > Thanks for the heads up on the deadline, > > I am a little surprised that you are choosing to discuss this at all with > pending > registrations and I obviously disagree with that. But if there are more > than 5 people besides Ted that think the current rules for provisionals i= n > the zone > > > I don't think I've seen anyone but you argue that the current rules permi= t > provisionals in the zone; if I have missed others reading the rules that > way, I'd appreciate a pointer. > > I think, though, that the key thing is to get some clarity on what the > rules should be after the elimination of the IETF tree. Since you > obviously disagree with my proposal, having your alternative spelled in a > draft does seem like the best way forward. Wherever dispatch sends the > question would then have two clear proposals to choose between. > > regards, > > Ted Hardie > > are > too open and need to be further constrained then I will submit a draft > that does > just that before the deadline. > > > On July 8, 2020 at 10:36 PM Ben Campbell < ben@nostrum.com> wrote: > > Hi Tim, > > Do you plan to submit an internet-draft? If so, please be advised that th= e > deadline for drafts prior to IETF108 is this coming Monday (7/13). If you > submit a draft prior to the deadline, we can consider it along with Ted= =E2=80=99s > draft (either on the list or possibly in the IETF108 DISPATCH meeting). > > Thanks, > > Ben. > > On Jul 7, 2020, at 9:03 AM, Timothy Mcsweeney < tim@dropnumber.com> > wrote: > > Hi All, > > Updating RFC3405 will necessarily require changes to RFC3401 as stated in > its > introduction. "This document will be updated and or obsoleted when > changes > are made to the DDDS specifications." > > We are now changing two RFCs so I don't think this fits as a > "simple administrative". > > But, I may have a work around that is simple and also solves the > provisional registration problem as stated by Ted. I could have ready in= a > day or so. > > Tim > > On July 7, 2020 at 3:34 AM "Martin J. D=C3=BCrst" < duerst@it.aoyama.ac.j= p> > wrote: > > > On 23/06/2020 07:51, Ben Campbell wrote: > > Hi Everyone, > > The ART ADs have reminded the chairs that our charter allows us to adopt > =E2=80=9Csimple administrative=E2=80=9D work such as IANA registration do= cuments. This > draft seems to fit squarely in that category. Does anyone see a reason we > shouldn=E2=80=99t just adopt it, with the expectation of going immediatel= y to WGLC? > (The last-call timeline is the same either way, either 2 weeks WGLC and 2 > weeks IETF LC for a working group draft, or 4 weeks IETF LC for an AD > sponsored draft.) > > > Triggered by the recent discussion, I had a look at Ted's draft and the > mail up to today. To me, both AD sponsored and Dispatch WG look > reasonable, with a slight preference for the former (if asked to express > such a preference). > > With respect to "pending registrations", I do not think these are > relevant, in particular because the thing in question isn't actually a > scheme, as discussed on the relevant list. > > I have one comment: The abstract currently reads > "This document removes references to the IETF tree of URI registrations > for registrations in URI.ARPA.". I found this hard to read, and I guess > it's because of the "registrations for registrations" piece. Unless one > is very familiar with the matter at hand, it's easy to think that both > occurrences of "registration" are referencing the same thing. While I'm > at it, it would also be good if the abstract mentioned something > positive. I think a less normative version of (the single sentence that > is) Section 2 would serve well as the abstract. > > Regards, Martin. > > Thanks! > > Ben (as co-chair) > > On Jun 3, 2020, at 6:13 PM, Ted Hardie < ted.ietf@gmail..com > > wrote: > > Howdy, > > This is one the shortest drafts I've ever written: > https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ < > https://datatracker.ietf...org/doc/draft-hardie-dispatch-rfc3405-update/ > = > > .. Basically, RFC 3405 used to require that registrations in URI.ARPA be > from the "IETF Tree". That tree was deprecated after the document was > published.. As it happens, there are very few registrations in URI.ARPA, = so > we did not catch it and fix it before now. > > This draft updates RFC 3405 to require "permanent" scheme registrations. > The salient bit is this: > > All registrations in URI.ARPA MUST be for schemes which are permanent > registrations, as they are described in BCP 35. > > I'm hoping for a quick dispatch of this, but happy to discuss. > > regards, > > Ted Hardie > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > -- > Prof. Dr.sc. Martin J. D=C3=BCrst > Department of Intelligent Information Technology > College of Science and Engineering > Aoyama Gakuin University > Fuchinobe 5-1-10, Chuo-ku, Sagamihara > 252-5258 Japan > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > --00000000000055b1e305aa06f896 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jul 9, 2020 at 10:28 AM Timothy M= csweeney <tim@dropnumber.com&g= t; wrote:
=20 =20 =20
Ted,=C2=A0

Section 2 (Updated Requirements) of your draft says:
"All registrations in URI.ARPA MUST be for schemes which are perman= ent registrations, as they are described in BCP 35."

I take that as:
We must update this because permanent registrations are not required.=C2= =A0 Otherwise there is no reason for an update.=C2=A0=20

The reason for the update is= that IETF tree registrations *are* required.=C2=A0 That effectively closes= the registry, without the community having made the affirmative decision t= o do so.=C2=A0 I want to fix that bug.=C2=A0

= I currently think that the closest replacement to the IETF tree would be pe= rmanent registration and that we should fix this by requiring that.=C2=A0 B= ut I'm happy to see a clear draft espousing some other way of fixing th= e bug; if you have an idea about that, please write the draft.
regards,

Ted

=


=C2=A0

If you are going to argue both sides, my draft and I will just stay out = of it.=C2=A0 Here is your pointer.=C2=A0=C2=A0 https://www.ietf.org/id/draft-hardie-d= ispatch-rfc3405-update-01.html#section-2

Tim


On July 9, 2020 at 11:57 AM Ted Hardie <ted.ietf@gmail.com> wrote:=20

Howdy,=20

On Thu, Jul 9, 2020 at 7:20 AM Timothy Mcsweeney <=20 tim@dropnumbe= r.com> wrote:=20
Hi Ben,=C2=A0

Thanks for the heads up on the deadline,

I am a little surprised that you are choosing to discuss this at al= l with pending=C2=A0
registrations and I obviously disagree with that.=C2=A0 But if ther= e are more than 5 people besides Ted that think the current rules for provi= sionals in the zone

I don't think I've seen anyone but you argue that the current= rules permit provisionals in the zone; if I have missed others reading the= rules that way, I'd appreciate a pointer.

I think, though, that the key thing is to get some clarity on what th= e rules should be after the elimination of the IETF tree.=C2=A0 Since you o= bviously disagree with my proposal, having your alternative spelled in a dr= aft does seem like the best way forward.=C2=A0 Wherever dispatch sends the = question would then have two clear proposals to choose between.=20

regards,

Ted Hardie=20
are
too open and need to be further constrained=C2=A0then I will submit= a draft that does
just that before the deadline.=C2=A0


On July 8, 2020 at 10:36 PM Ben Campbell <=20 ben@nostrum.com> wrote:=20

Hi Tim,

Do you plan to submit an internet-draft? If so, please be advised = that the deadline for drafts prior to IETF108 is this coming Monday (7/13).= If you submit a draft prior to the deadline, we can consider it along with= Ted=E2=80=99s draft (either on the list or possibly in the IETF108 DISPATC= H meeting).

Thanks,

Ben.=20

On Jul 7, 2020, at 9:03 AM, Timothy Mcsweeney <=20 tim@dropnumber.com> wrote:

Hi All,

Updating RFC3405 will necessarily require changes to RFC3401= as stated in its=C2=A0
introduction.=C2=A0 "This document will be updated and = or obsoleted when changes
are made to the DDDS specifications."

We are now changing two RFCs so I don't think this fits = as a
"simple administrative".

But, I may have a work around that is simple and also solves= the provisional registration problem as stated by Ted.=C2=A0 I could have = ready in a day or so.

Tim
On July 7, 2020 at 3:34 AM "Martin J. D=C3=BCrst" = <=20 duerst@it.aoyama.ac.jp> wrote:


On 23/06/2020 07:51, Ben Campbell wrote:
Hi Everyone,

The ART ADs have reminded the chairs that our charter allow= s us to adopt =E2=80=9Csimple administrative=E2=80=9D work such as IANA reg= istration documents. This draft seems to fit squarely in that category. Doe= s anyone see a reason we shouldn=E2=80=99t just adopt it, with the expectat= ion of going immediately to WGLC? (The last-call timeline is the same eithe= r way, either 2 weeks WGLC and 2 weeks IETF LC for a working group draft, o= r 4 weeks IETF LC for an AD sponsored draft.)

Triggered by the recent discussion, I had a look at Ted'= s draft and the
mail up to today. To me, both AD sponsored and Dispatch WG l= ook
reasonable, with a slight preference for the former (if aske= d to express
such a preference).

With respect to "pending registrations", I do not = think these are
relevant, in particular because the thing in question isn= 9;t actually a
scheme, as discussed on the relevant list.

I have one comment: The abstract currently reads
"This document removes references to the IETF tree of U= RI registrations
for registrations in URI.ARPA.". I found this hard to r= ead, and I guess
it's because of the "registrations for registration= s" piece. Unless one
is very familiar with the matter at hand, it's easy to t= hink that both
occurrences of "registration" are referencing the = same thing. While I'm
at it, it would also be good if the abstract mentioned somet= hing
positive. I think a less normative version of (the single se= ntence that
is) Section 2 would serve well as the abstract.

Regards, Martin.

Thanks!

Ben (as co-chair)

On Jun 3, 2020, at 6:13 PM, Ted Hardie <=20 ted.ietf@gmail..com> wrote:

Howdy,

This is one the shortest drafts I've ever written:=20 https://datatra= cker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ <=20 https://datatr= acker.ietf...org/doc/draft-hardie-dispatch-rfc3405-update/> .. Basic= ally, RFC 3405 used to require that registrations in URI.ARPA be from the &= quot;IETF Tree". That tree was deprecated after the document was publi= shed.. As it happens, there are very few registrations in URI.ARPA, so we d= id not catch it and fix it before now.

This draft updates RFC 3405 to require "permanent&quo= t; scheme registrations. The salient bit is this:

All registrations in URI.ARPA MUST be for schemes which ar= e permanent
registrations, as they are described in BCP 35.

I'm hoping for a quick dispatch of this, but happy to = discuss.

regards,

Ted Hardie
_______________________________________________
dispatch mailing list



_______________________________________________
dispatch mailing list


--
Prof. Dr.sc. Martin J. D=C3=BCrst
Department of Intelligent Information Technology
College of Science and Engineering
Aoyama Gakuin University
Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan

_______________________________________________
dispatch mailing list
_______________________________________________=20
dispatch mailing list=20
dispatch@ietf.org=20
https://www.ietf.org/mailman/listinfo/dispa= tch=20


=C2=A0
_______________________________________________=20
dispatch mailing list=20
dispatch@ietf.org=20
https://www.ietf.org/mailman/listinfo/dispatch= =20

=C2=A0
=20
--00000000000055b1e305aa06f896-- From nobody Thu Jul 9 12:43:55 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5DEC3A0E6C for ; Thu, 9 Jul 2020 12:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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 XpweKDvgW5Cf for ; Thu, 9 Jul 2020 12:43:51 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (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 AD3F43A0E6A for ; Thu, 9 Jul 2020 12:43:50 -0700 (PDT) Received: from oxusgaltgw04.schlund.de ([10.72.72.50]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1MTRlQ-1kL1j505oy-00TnAj; Thu, 09 Jul 2020 21:43:39 +0200 Date: Thu, 9 Jul 2020 15:43:38 -0400 (EDT) From: Timothy Mcsweeney Reply-To: Timothy Mcsweeney To: Ted Hardie Cc: Ben Campbell , Patrick McManus , DISPATCH WG Message-ID: <166222013.29010.1594323818783@email.ionos.com> In-Reply-To: References: <85664807-701C-4700-ABB7-D0434F14D6A0@nostrum.com> <1580898449.190942.1594130597348@email.ionos.com> <3A1C3068-717D-4822-A110-9F91272B04CB@nostrum.com> <2116535970.9156.1594304410818@email.ionos.com> <1777741348.21431.1594315737558@email.ionos.com> MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.1-Rev32 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:7GwIG3Wr3AgVv7s11h0rybVwASgJ2i0RV21ntpPWM/Dfe7OgGSg LU0Ujd60Nj/65Ug8ncdeetCq25ssFCFMDrz2QvEEgIAzXObndPaWhXXgE3w46YCeTJh/euo S1Yp82Oy3S7O2MaL4CRGf+T7s/P9oK8XC+K/dMMLP/hAUh5Kghqjn78KvJLbltaNlWID7Mg lrskWIVGYtlVxeiyzrRPA== X-UI-Out-Filterresults: notjunk:1;V03:K0:ZZLwlAdo3mk=:jIDOgdNGuGcXSoBlAl6m30 Vq0Q7tVcfFRuF8H63Wm1VysUvY5IWMov1ErVf1ApGAGR3+VtsEc/aMAszLffzIN2e4HpxT2Uf d9DON4HvzHS9XWioKY6Z1dxZiBo8UiN5LCUrj18x1m7ZXGFviaBEkai1IWH0QMzLajhIXVrX1 7aQtRmP+LL3Axr9w0yOwlgew2jYiaCs1QnI1QXs6rHXtDwTj6AIc/SH+8vUJju7vHyTBqN27O Ygw+eE3Z66x9zY0p0aJW8z0pTsQH9ua5L1qMOVIR6s/QSYe0NY7nu+jFa8BZI2cYbtywMnm98 mv2jytoopm++ClAM/LAqGw6FsSlK8ZAbRcwxY64/1gPpY7psZneKjF0zFzm4nW6inVLmCLzGE wxZMKehzdhyv/2+0wEM6144I2W/lutTn5Hhm73ecaklebwcOkKQgcZHZEWmmQF5qGCpthyNTn eat9EtzudrOZleiRWkHJik/h7r4CEFvIarBGBUmzJREz7M87vP6FSOOnqzu9FQDcrh4FriVdR TUhfF1DL6uGYvdlWrt0tfo6qR6AFB9Hx9bAyJdrN0OnSeQ2pzuWAZ4EeGevVnIYMzTL14nIu8 So7dtpgVpvCBtaMwvQ7IQN5wf50OI4O8cYoB8XizdESrFEVnoZsxQptKaKwmdEten5roWJasY P3WuFry12g6HbIFT5XOgkzJkBWYmst6h5ObyYKjIH0Y+XMssuoywBwQBDd105sVoU4aXKvp1z Dq8aMBAehh02G8w9bJtziRr3amQBTzFOP6tQN66x49CsQ7YuBDN1Q9aDn5MPJpgi5RjOn4KBE 6Pxm/N92qFBcweAjWvbUoehzIocJK0r6RBQlEsXw1JWhqxK27geEeBfDkjXFOC5S/zBR/Cu Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2020 19:43:53 -0000 =20 =20
You're talking about the [ 10] reference= in section=20 3.1.1 in 3= 405 and when I click on the reference it sends me right to=20 BCP35.

>The reason for the update is that IETF tree registrations *are* requ= ired.

That is now, scheme registration is required, including provisionals.&nb= sp; See, no bug.

Tim




On July 9, 2020 at 3:09 PM Ted Hardie <ted.ietf@gmail.com> wrote:= =20

On Thu, Jul 9, 2020 at 10:28 AM Timothy Mcsweeney <=20 tim@dropnumber.com> wrote= :=20
Ted, 

Section 2 (Updated Requirements) of your draft says:
"All registrations in URI.ARPA MUST be for schemes which are perman= ent registrations, as they are described in BCP 35."

I take that as:
We must update this because permanent registrations are not require= d.  Otherwise there is no reason for an update. 

The reason for the update is that IETF tree registrations *are* requi= red.  That effectively closes the registry, without the community havi= ng made the affirmative decision to do so.  I want to fix that bug.&nb= sp;=20

I currently think that the closest replacement to the IETF tree would= be permanent registration and that we should fix this by requiring that.&n= bsp; But I'm happy to see a clear draft espousing some other way of fixing = the bug; if you have an idea about that, please write the draft.

regards,

Ted=20





If you are going to argue both sides, my draft and I will just stay= out of it.  Here is your pointer.  =20 https://www.ietf= .org/id/draft-hardie-dispatch-rfc3405-update-01.html#section-2

Tim


On July 9, 2020 at 11:57 AM Ted Hardie <=20 ted.ietf@gmail.com> wrote:=20

Howdy,=20

On Thu, Jul 9, 2020 at 7:20 AM Timothy Mcsweeney <=20 tim@dropnumber.com> wrote:=20
Hi Ben, 

Thanks for the heads up on the deadline,

I am a little surprised that you are choosing to discuss this = at all with pending 
registrations and I obviously disagree with that.  But if= there are more than 5 people besides Ted that think the current rules for = provisionals in the zone

I don't think I've seen anyone but you argue that the current ru= les permit provisionals in the zone; if I have missed others reading the ru= les that way, I'd appreciate a pointer.

I think, though, that the key thing is to get some clarity on wh= at the rules should be after the elimination of the IETF tree.  Since = you obviously disagree with my proposal, having your alternative spelled in= a draft does seem like the best way forward.  Wherever dispatch sends= the question would then have two clear proposals to choose between.=20

regards,

Ted Hardie=20
are
too open and need to be further constrained then I will s= ubmit a draft that does
just that before the deadline. 


On July 8, 2020 at 10:36 PM Ben Campbell <=20 ben@nostrum.com> wrote:=20

Hi Tim,

Do you plan to submit an internet-draft? If so, please be adv= ised that the deadline for drafts prior to IETF108 is this coming Monday (7= /13). If you submit a draft prior to the deadline, we can consider it along= with Ted=E2=80=99s draft (either on the list or possibly in the IETF108 DI= SPATCH meeting).

Thanks,

Ben.=20

On Jul 7, 2020, at 9:03 AM, Timothy Mcsweeney <=20 tim@dropnumber.com> wrote:

Hi All,

Updating RFC3405 will necessarily require changes to RF= C3401 as stated in its 
introduction.  "This document will be updated and = or obsoleted when changes
are made to the DDDS specifications."

We are now changing two RFCs so I don't think this fits= as a
"simple administrative".

But, I may have a work around that is simple and also s= olves the provisional registration problem as stated by Ted.  I could = have ready in a day or so.

Tim
On July 7, 2020 at 3:34 AM "Martin J. D=C3=BCrst" <= =20 duerst@it.aoyama.ac.jp> wrote:


On 23/06/2020 07:51, Ben Campbell wrote:
Hi Everyone,

The ART ADs have reminded the chairs that our charter = allows us to adopt =E2=80=9Csimple administrative=E2=80=9D work such as IAN= A registration documents. This draft seems to fit squarely in that category= . Does anyone see a reason we shouldn=E2=80=99t just adopt it, with the exp= ectation of going immediately to WGLC? (The last-call timeline is the same = either way, either 2 weeks WGLC and 2 weeks IETF LC for a working group dra= ft, or 4 weeks IETF LC for an AD sponsored draft.)

Triggered by the recent discussion, I had a look at Ted= 's draft and the
mail up to today. To me, both AD sponsored and Dispatch= WG look
reasonable, with a slight preference for the former (if= asked to express
such a preference).

With respect to "pending registrations", I do not think= these are
relevant, in particular because the thing in question i= sn't actually a
scheme, as discussed on the relevant list.

I have one comment: The abstract currently reads
"This document removes references to the IETF tree of U= RI registrations
for registrations in URI.ARPA.". I found this hard to r= ead, and I guess
it's because of the "registrations for registrations" p= iece. Unless one
is very familiar with the matter at hand, it's easy to = think that both
occurrences of "registration" are referencing the same = thing. While I'm
at it, it would also be good if the abstract mentioned = something
positive. I think a less normative version of (the sing= le sentence that
is) Section 2 would serve well as the abstract.

Regards, Martin.

Thanks!

Ben (as co-chair)

On Jun 3, 2020, at 6:13 PM, Ted Hardie <=20 ted.ietf@gmail..com> wrote:

Howdy,

This is one the shortest drafts I've ever written:=20 https://da= tatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ <=20 https://d= atatracker.ietf...org/doc/draft-hardie-dispatch-rfc3405-update/> .. = Basically, RFC 3405 used to require that registrations in URI.ARPA be from = the "IETF Tree". That tree was deprecated after the document was published.= . As it happens, there are very few registrations in URI.ARPA, so we did no= t catch it and fix it before now.

This draft updates RFC 3405 to require "permanent" sc= heme registrations. The salient bit is this:

All registrations in URI.ARPA MUST be for schemes whi= ch are permanent
registrations, as they are described in BCP 35.

I'm hoping for a quick dispatch of this, but happy to= discuss.

regards,

Ted Hardie
_______________________________________________
dispatch mailing list



_______________________________________________
dispatch mailing list


--
Prof. Dr.sc. Martin J. D=C3=BCrst
Department of Intelligent Information Technology
College of Science and Engineering
Aoyama Gakuin University
Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan

_______________________________________________
dispatch mailing list
_______________________________________________=20
dispatch mailing list=20
dispatch@ietf.org=20
https://www.ietf.org/mailman/listinfo/d= ispatch=20


 
_______________________________________________=20
dispatch mailing list=20
dispatch@ietf.org=20
https://www.ietf.org/mailman/listinfo/dispatc= h=20

 

 
=20 From nobody Thu Jul 9 13:04:28 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C840D3A07EE for ; Thu, 9 Jul 2020 13:04:22 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 mUUsgYldw9b5 for ; Thu, 9 Jul 2020 13:04:20 -0700 (PDT) Received: from mail-oo1-xc30.google.com (mail-oo1-xc30.google.com [IPv6:2607:f8b0:4864:20::c30]) (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 E83A93A05A4 for ; Thu, 9 Jul 2020 13:04:19 -0700 (PDT) Received: by mail-oo1-xc30.google.com with SMTP id t6so577520ooh.4 for ; Thu, 09 Jul 2020 13:04:19 -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=+IOGnglz0L19oxvHixOLeCEZ9fEoECLBNuk6B8BGWL0=; b=vAIL81Fpl8Sc9GvzGhaOkG4mH9eZczHPHA+Cmpg5F4I1w7NM5V4CSuNvkhmT0vd5XT CGZkLKCa6njAAJnMZnDWpaW+ytbKnYn1FTWqLtP7krjp1kwWAK8QqfbgTf7pfn0doJCf 8uA2nYULoMAs9nsn8b6Ln+CBeGdW+bw3NJ792N+HQfpTYY9E3n+1SaBwB5SuCyHE5Ck2 fvZ+dssEyG+4b/0O/IxKu4naD7RL65cFzgMa9R7D676l3cvqnQ0GlL0P1uiYW4xqrzKD H8g59RcKidBiCcrkLY6YIwHOwVUKLdxXcIUiKxooZrxw03RQ8qGJbMbFVONPDmvydxSg 78aA== 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=+IOGnglz0L19oxvHixOLeCEZ9fEoECLBNuk6B8BGWL0=; b=o7pTLCaOTEsAeq8T9poo7ockPSJND5v8D+plrO2jOF8CaBwuDyIoZzQeeIVaKzej/M sJawNTKM+X6tTSyUc8ew05TegLvqTNTnQwAspd5brAsZJ11/hhW7FV9RT8XZfL/9DV/G m2HPSjGiPSMS78P/VaqF23q1zO4SkDTDhZjL3+rNZmEsIGNboMYphMq3bNVdb47TBSLZ SQzfJVkALQpqQ7jtDfOVZRoybhqlTXSghGoYY3hiFOQ1DQ4QASItvWGr3nimAOvCZdkX XbOuuozq8AISZWvsdqP+FtrflO8ewnr0y7uSNJFFKBtNfuhv2wepwiiqZgo44MJqoB+R iWFA== X-Gm-Message-State: AOAM530Pge8ZTYAx5C3oxBapcr577lykgdJBjxJZK+rcBqrIxP7yIaTX JWTUX0nWPCqguJ8/DSm50VqIJE35yCsq1y8vJas= X-Google-Smtp-Source: ABdhPJzBLBHrxsqZxKEW2UTMoiWJ/Aet05qFtrDRcNA1dG/Toq+GDjbBxz6cQ00Z003i24qZQH661uwFfdaaVlSMR8I= X-Received: by 2002:a4a:bd0b:: with SMTP id n11mr7082043oop.66.1594325059089; Thu, 09 Jul 2020 13:04:19 -0700 (PDT) MIME-Version: 1.0 References: <85664807-701C-4700-ABB7-D0434F14D6A0@nostrum.com> <1580898449.190942.1594130597348@email.ionos.com> <3A1C3068-717D-4822-A110-9F91272B04CB@nostrum.com> <2116535970.9156.1594304410818@email.ionos.com> <1777741348.21431.1594315737558@email.ionos.com> <166222013.29010.1594323818783@email.ionos.com> In-Reply-To: <166222013.29010.1594323818783@email.ionos.com> From: Ted Hardie Date: Thu, 9 Jul 2020 13:03:52 -0700 Message-ID: To: Timothy Mcsweeney Cc: Ben Campbell , Patrick McManus , DISPATCH WG Content-Type: multipart/alternative; boundary="000000000000cdb87305aa07bae8" Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2020 20:04:27 -0000 --000000000000cdb87305aa07bae8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 9, 2020 at 12:43 PM Timothy Mcsweeney wrote: > You're talking about the [ 10 ] > reference in section 3.1.1 in 3405 > and when I click on > the reference it sends me right to BCP35 > . > > >The reason for the update is that IETF tree registrations *are* required= . > > That is now, scheme registration is required, including provisionals. > See, no bug. > > Tim > > > Quite simply, that's not what the document says. The previous effort to simply re-interpret it (see https://www.rfc-editor.org/errata/eid2842) was already rejected. regards, Ted > > > On July 9, 2020 at 3:09 PM Ted Hardie wrote: > > On Thu, Jul 9, 2020 at 10:28 AM Timothy Mcsweeney < tim@dropnumber.com> > wrote: > > Ted, > > Section 2 (Updated Requirements) of your draft says: > "All registrations in URI.ARPA MUST be for schemes which are permanent > registrations, as they are described in BCP 35." > > I take that as: > We must update this because permanent registrations are not required. > Otherwise there is no reason for an update. > > > The reason for the update is that IETF tree registrations *are* required. > That effectively closes the registry, without the community having made t= he > affirmative decision to do so. I want to fix that bug. > > I currently think that the closest replacement to the IETF tree would be > permanent registration and that we should fix this by requiring that. Bu= t > I'm happy to see a clear draft espousing some other way of fixing the bug= ; > if you have an idea about that, please write the draft. > > regards, > > Ted > > > > > > If you are going to argue both sides, my draft and I will just stay out o= f > it. Here is your pointer. > https://www.ietf.org/id/draft-hardie-dispatch-rfc3405-update-01.html#sect= ion-2 > > Tim > > > On July 9, 2020 at 11:57 AM Ted Hardie < ted.ietf@gmail.com> wrote: > > Howdy, > > On Thu, Jul 9, 2020 at 7:20 AM Timothy Mcsweeney < tim@dropnumber.com> > wrote: > > Hi Ben, > > Thanks for the heads up on the deadline, > > I am a little surprised that you are choosing to discuss this at all with > pending > registrations and I obviously disagree with that. But if there are more > than 5 people besides Ted that think the current rules for provisionals i= n > the zone > > > I don't think I've seen anyone but you argue that the current rules permi= t > provisionals in the zone; if I have missed others reading the rules that > way, I'd appreciate a pointer. > > I think, though, that the key thing is to get some clarity on what the > rules should be after the elimination of the IETF tree. Since you > obviously disagree with my proposal, having your alternative spelled in a > draft does seem like the best way forward. Wherever dispatch sends the > question would then have two clear proposals to choose between. > > regards, > > Ted Hardie > > are > too open and need to be further constrained then I will submit a draft > that does > just that before the deadline. > > > On July 8, 2020 at 10:36 PM Ben Campbell < ben@nostrum.com> wrote: > > Hi Tim, > > Do you plan to submit an internet-draft? If so, please be advised that th= e > deadline for drafts prior to IETF108 is this coming Monday (7/13). If you > submit a draft prior to the deadline, we can consider it along with Ted= =E2=80=99s > draft (either on the list or possibly in the IETF108 DISPATCH meeting). > > Thanks, > > Ben. > > On Jul 7, 2020, at 9:03 AM, Timothy Mcsweeney < tim@dropnumber.com> > wrote: > > Hi All, > > Updating RFC3405 will necessarily require changes to RFC3401 as stated in > its > introduction. "This document will be updated and or obsoleted when > changes > are made to the DDDS specifications." > > We are now changing two RFCs so I don't think this fits as a > "simple administrative". > > But, I may have a work around that is simple and also solves the > provisional registration problem as stated by Ted. I could have ready in= a > day or so. > > Tim > > On July 7, 2020 at 3:34 AM "Martin J. D=C3=BCrst" < duerst@it.aoyama.ac.j= p> > wrote: > > > On 23/06/2020 07:51, Ben Campbell wrote: > > Hi Everyone, > > The ART ADs have reminded the chairs that our charter allows us to adopt > =E2=80=9Csimple administrative=E2=80=9D work such as IANA registration do= cuments. This > draft seems to fit squarely in that category. Does anyone see a reason we > shouldn=E2=80=99t just adopt it, with the expectation of going immediatel= y to WGLC? > (The last-call timeline is the same either way, either 2 weeks WGLC and 2 > weeks IETF LC for a working group draft, or 4 weeks IETF LC for an AD > sponsored draft.) > > > Triggered by the recent discussion, I had a look at Ted's draft and the > mail up to today. To me, both AD sponsored and Dispatch WG look > reasonable, with a slight preference for the former (if asked to express > such a preference). > > With respect to "pending registrations", I do not think these are > relevant, in particular because the thing in question isn't actually a > scheme, as discussed on the relevant list. > > I have one comment: The abstract currently reads > "This document removes references to the IETF tree of URI registrations > for registrations in URI.ARPA.". I found this hard to read, and I guess > it's because of the "registrations for registrations" piece. Unless one > is very familiar with the matter at hand, it's easy to think that both > occurrences of "registration" are referencing the same thing. While I'm > at it, it would also be good if the abstract mentioned something > positive. I think a less normative version of (the single sentence that > is) Section 2 would serve well as the abstract. > > Regards, Martin. > > Thanks! > > Ben (as co-chair) > > On Jun 3, 2020, at 6:13 PM, Ted Hardie < ted.ietf@gmail..com > > wrote: > > Howdy, > > This is one the shortest drafts I've ever written: > https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ < > https://datatracker.ietf...org/doc/draft-hardie-dispatch-rfc3405-update/ > = > > .. Basically, RFC 3405 used to require that registrations in URI.ARPA be > from the "IETF Tree". That tree was deprecated after the document was > published.. As it happens, there are very few registrations in URI.ARPA, = so > we did not catch it and fix it before now. > > This draft updates RFC 3405 to require "permanent" scheme registrations. > The salient bit is this: > > All registrations in URI.ARPA MUST be for schemes which are permanent > registrations, as they are described in BCP 35. > > I'm hoping for a quick dispatch of this, but happy to discuss. > > regards, > > Ted Hardie > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > -- > Prof. Dr.sc. Martin J. D=C3=BCrst > Department of Intelligent Information Technology > College of Science and Engineering > Aoyama Gakuin University > Fuchinobe 5-1-10, Chuo-ku, Sagamihara > 252-5258 Japan > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > > > > --000000000000cdb87305aa07bae8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jul 9, 2020 at 12:43 PM Timothy M= csweeney <tim@dropnumber.com&g= t; wrote:
=20 =20 =20

=
regards,

Ted


=C2=A0


On July 9, 2020 at 3:09 PM Ted Hardie <ted.ietf@gmail.com> wrote:=20

On Thu, Jul 9, 2020 at 10:28 AM Timothy Mcsweeney <=20 tim@dropnumber= .com> wrote:=20
Ted,=C2=A0

Section 2 (Updated Requirements) of your draft says:
"All registrations in URI.ARPA MUST be for schemes which are p= ermanent registrations, as they are described in BCP 35."

I take that as:
We must update this because permanent registrations are not require= d.=C2=A0 Otherwise there is no reason for an update.=C2=A0

The reason for the update is that IETF tree registrations *are* requi= red.=C2=A0 That effectively closes the registry, without the community havi= ng made the affirmative decision to do so.=C2=A0 I want to fix that bug.=C2= =A0=20

I currently think that the closest replacement to the IETF tree would= be permanent registration and that we should fix this by requiring that.= =C2=A0 But I'm happy to see a clear draft espousing some other way of f= ixing the bug; if you have an idea about that, please write the draft.

regards,

Ted=20





If you are going to argue both sides, my draft and I will just stay= out of it.=C2=A0 Here is your pointer.=C2=A0=C2=A0=20 https://www.ietf= .org/id/draft-hardie-dispatch-rfc3405-update-01.html#section-2

Tim


On July 9, 2020 at 11:57 AM Ted Hardie <=20 ted.ietf@gmail.com> wrote:=20

Howdy,=20

On Thu, Jul 9, 2020 at 7:20 AM Timothy Mcsweeney <=20 tim@dropnumber.com> wrote:=20
Hi Ben,=C2=A0

Thanks for the heads up on the deadline,

I am a little surprised that you are choosing to discuss this = at all with pending=C2=A0
registrations and I obviously disagree with that.=C2=A0 But if= there are more than 5 people besides Ted that think the current rules for = provisionals in the zone

I don't think I've seen anyone but you argue that the cu= rrent rules permit provisionals in the zone; if I have missed others readin= g the rules that way, I'd appreciate a pointer.

I think, though, that the key thing is to get some clarity on wh= at the rules should be after the elimination of the IETF tree.=C2=A0 Since = you obviously disagree with my proposal, having your alternative spelled in= a draft does seem like the best way forward.=C2=A0 Wherever dispatch sends= the question would then have two clear proposals to choose between.=20

regards,

Ted Hardie=20
are
too open and need to be further constrained=C2=A0then I will s= ubmit a draft that does
just that before the deadline.=C2=A0


On July 8, 2020 at 10:36 PM Ben Campbell <=20 ben@nostrum.com> wrote:=20

Hi Tim,

Do you plan to submit an internet-draft? If so, please be adv= ised that the deadline for drafts prior to IETF108 is this coming Monday (7= /13). If you submit a draft prior to the deadline, we can consider it along= with Ted=E2=80=99s draft (either on the list or possibly in the IETF108 DI= SPATCH meeting).

Thanks,

Ben.=20

On Jul 7, 2020, at 9:03 AM, Timothy Mcsweeney <=20 tim@dropnumber.com> wrote:

Hi All,

Updating RFC3405 will necessarily require changes to RF= C3401 as stated in its=C2=A0
introduction.=C2=A0 "This document will be updated= and or obsoleted when changes
are made to the DDDS specifications."

We are now changing two RFCs so I don't think this = fits as a
"simple administrative".

But, I may have a work around that is simple and also s= olves the provisional registration problem as stated by Ted.=C2=A0 I could = have ready in a day or so.

Tim
On July 7, 2020 at 3:34 AM "Martin J. D=C3=BCrst&q= uot; <=20 duerst@it.aoyama.ac.jp> wrote:


On 23/06/2020 07:51, Ben Campbell wrote:
Hi Everyone,

The ART ADs have reminded the chairs that our charter = allows us to adopt =E2=80=9Csimple administrative=E2=80=9D work such as IAN= A registration documents. This draft seems to fit squarely in that category= . Does anyone see a reason we shouldn=E2=80=99t just adopt it, with the exp= ectation of going immediately to WGLC? (The last-call timeline is the same = either way, either 2 weeks WGLC and 2 weeks IETF LC for a working group dra= ft, or 4 weeks IETF LC for an AD sponsored draft.)

Triggered by the recent discussion, I had a look at Ted= 's draft and the
mail up to today. To me, both AD sponsored and Dispatch= WG look
reasonable, with a slight preference for the former (if= asked to express
such a preference).

With respect to "pending registrations", I do= not think these are
relevant, in particular because the thing in question i= sn't actually a
scheme, as discussed on the relevant list.

I have one comment: The abstract currently reads
"This document removes references to the IETF tree= of URI registrations
for registrations in URI.ARPA.". I found this hard= to read, and I guess
it's because of the "registrations for registr= ations" piece. Unless one
is very familiar with the matter at hand, it's easy= to think that both
occurrences of "registration" are referencing= the same thing. While I'm
at it, it would also be good if the abstract mentioned = something
positive. I think a less normative version of (the sing= le sentence that
is) Section 2 would serve well as the abstract.

Regards, Martin.

Thanks!

Ben (as co-chair)

On Jun 3, 2020, at 6:13 PM, Ted Hardie <=20 ted.ietf@gmail..com> wrote:

Howdy,

This is one the shortest drafts I've ever written= :=20 https://da= tatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ <=20 https://d= atatracker.ietf...org/doc/draft-hardie-dispatch-rfc3405-update/> .. = Basically, RFC 3405 used to require that registrations in URI.ARPA be from = the "IETF Tree". That tree was deprecated after the document was = published.. As it happens, there are very few registrations in URI.ARPA, so= we did not catch it and fix it before now.

This draft updates RFC 3405 to require "permanen= t" scheme registrations. The salient bit is this:

All registrations in URI.ARPA MUST be for schemes whi= ch are permanent
registrations, as they are described in BCP 35.

I'm hoping for a quick dispatch of this, but happ= y to discuss.

regards,

Ted Hardie
_______________________________________________
dispatch mailing list



_______________________________________________
dispatch mailing list


--
Prof. Dr.sc. Martin J. D=C3=BCrst
Department of Intelligent Information Technology
College of Science and Engineering
Aoyama Gakuin University
Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan

_______________________________________________
dispatch mailing list
_______________________________________________=20
dispatch mailing list=20
dispatch@ietf.org=20
https://www.ietf.org/mailman/listinfo/d= ispatch=20


=C2=A0
_______________________________________________=20
dispatch mailing list=20
dispatch@ietf.org=20
https://www.ietf.org/mailman/listinfo/dispa= tch=20

=C2=A0

=C2=A0
=20
--000000000000cdb87305aa07bae8-- From nobody Thu Jul 9 13:31:15 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9252A3A082D for ; Thu, 9 Jul 2020 13:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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 k0SbOHWHJPSU for ; Thu, 9 Jul 2020 13:31:11 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (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 5954F3A07F5 for ; Thu, 9 Jul 2020 13:31:11 -0700 (PDT) Received: from oxusgaltgw04.schlund.de ([10.72.72.50]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MFe8h-1k5Ouf34HV-00EdHh; Thu, 09 Jul 2020 22:31:00 +0200 Date: Thu, 9 Jul 2020 16:31:00 -0400 (EDT) From: Timothy Mcsweeney Reply-To: Timothy Mcsweeney To: Ted Hardie Cc: Ben Campbell , DISPATCH WG , Patrick McManus Message-ID: <577450265.31749.1594326660123@email.ionos.com> In-Reply-To: <166222013.29010.1594323818783@email.ionos.com> References: <85664807-701C-4700-ABB7-D0434F14D6A0@nostrum.com> <1580898449.190942.1594130597348@email.ionos.com> <3A1C3068-717D-4822-A110-9F91272B04CB@nostrum.com> <2116535970.9156.1594304410818@email.ionos.com> <1777741348.21431.1594315737558@email.ionos.com> <166222013.29010.1594323818783@email.ionos.com> MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.1-Rev32 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:5vgdVmdSkZkMpnnQujyjfgl+HjfSOLfwSZ1zPFnnLfBKqCtyg+C iATX42o0n1uy3oA9DhTrdSRRkD9wLpRREoV0RUgYEHJ4oDBLDRCWJxZQvI0biezTG4zwUTa fxfDDqwNKZtae1nIW2cx6nfkXeUV/2Vq1lFANTV3E9HKhBTJzJwwGj/oDP5NininkocP8Hh 28llra0lQ6AdNygWkBi4A== X-UI-Out-Filterresults: notjunk:1;V03:K0:FZ3QgsT9jA8=:XhBqkdE7tYEg+bQtPzq72i zJ0+s0X93cGDDMiEbe3nrKdcQPQ1X3ts3WHev9qEEK397zzoM/0ELjQpGVlqYRYJndEU0FAkH V6I+CSKXMcsQsa98ye1A8s8WEdAcIZ3UduTzz7q87sATsUTUWiPLRziH0nU+u89/GvXnRFqxJ QrMoWbjjbBuoDJpjyTmpBtButHiGQRdLz8xALQKmWVYcEdSd5WyjyDw0I2UFLF9rEwP5Vjuy7 iUWGOTbyl4WbC5H9XDxNn3rYYFuYbi4/hFqQiwLsavyZkG1nw8K9322cnplrs0LSrAflqsumU vUK9IBC3Zw9NjFBH2NFvhVWYbHW20PrKZhPRtvm4gG/Ou/wl7hLq9Av59dIpvR+6M/rRYVVyR f8VM+U/20diJorOPn04AC2L3Yuccw1CuxlGokWy226TfDJ3HtKdSogLq855h28fcz72wYfBTW k7AlSUqnu3bUHDt9VC2L3b80lX29UISvKtiDpALZVNhpTHyzae4WSxR5asJiJURso3hBojTte F6Ll4ufw++iEbgm1+4To00xKteb7pMo6ypIMR5kARBlo8hQ4MVSLOCS8ifxqC3BCeKUBvvr6+ XWExFulmBQE/QNCaOiynk4PO3WWXGSRWcYUe+10iEkAuX9fqqnlKb6AOtWRsZ17d6naOzleWf Eh/Wv7T4/I10bP4gI2a5Ynok45LUOiR/ZYprIph0Bu6kAX8VZKFaIbNOD9LuT7cUWj39XtINc mVLKlZ3r94q27jaGc8dlOVEJjlCDGhr0RWePRu+3WtmGw9NY4GAd4jGvi2BTBuRK7vvDI186B xO7qJPpiM0zOIR8R/hBD5yhcVKca7M5uOeqICGKEATodyZ1p1U95mNpsvQPS6lrkqKyeoMY Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2020 20:31:14 -0000 =20 =20
Yeah I looked at that a month ago already but unfortunately it doesn't m= atter if you change the reference from [10] to [11] it still goes to BCP35.=   Still no bug :-)
On July 9, 2020 at 3:43 PM Timothy Mcsweeney <tim@dropnumber.com> = wrote:=20

You're talking about the [=20 10] referenc= e in section=20 3.1.1 in = 3405 and when I click on the reference it sends me right to=20 BCP35.

>The reason for the update is that IETF tree registrations *are* req= uired.

That is now, scheme registration is required, including provisionals.&n= bsp; See, no bug.

Tim




On July 9, 2020 at 3:09 PM Ted Hardie <ted.ietf@gmail.com> wrote:= =20

On Thu, Jul 9, 2020 at 10:28 AM Timothy Mcsweeney <=20 tim@dropnumber.com> wrot= e:=20
Ted, 

Section 2 (Updated Requirements) of your draft says:
"All registrations in URI.ARPA MUST be for schemes which are perma= nent registrations, as they are described in BCP 35."

I take that as:
We must update this because permanent registrations are not requir= ed.  Otherwise there is no reason for an update. 

The reason for the update is that IETF tree registrations *are* requ= ired.  That effectively closes the registry, without the community hav= ing made the affirmative decision to do so.  I want to fix that bug.&n= bsp;=20

I currently think that the closest replacement to the IETF tree woul= d be permanent registration and that we should fix this by requiring that.&= nbsp; But I'm happy to see a clear draft espousing some other way of fixing= the bug; if you have an idea about that, please write the draft.

regards,

Ted=20





If you are going to argue both sides, my draft and I will just sta= y out of it.  Here is your pointer.  =20 https://www.iet= f..org/id/draft-hardie-dispatch-rfc3405-update-01.html#section-2

Tim


On July 9, 2020 at 11:57 AM Ted Hardie <=20 ted.ietf@gmail.com> wrote:=20

Howdy,=20

On Thu, Jul 9, 2020 at 7:20 AM Timothy Mcsweeney <=20 tim@dropnumber.com> wrote:=20
Hi Ben, 

Thanks for the heads up on the deadline,

I am a little surprised that you are choosing to discuss this= at all with pending 
registrations and I obviously disagree with that.  But i= f there are more than 5 people besides Ted that think the current rules for= provisionals in the zone

I don't think I've seen anyone but you argue that the current r= ules permit provisionals in the zone; if I have missed others reading the r= ules that way, I'd appreciate a pointer.

I think, though, that the key thing is to get some clarity on w= hat the rules should be after the elimination of the IETF tree.  Since= you obviously disagree with my proposal, having your alternative spelled i= n a draft does seem like the best way forward.  Wherever dispatch send= s the question would then have two clear proposals to choose between.=20

regards,

Ted Hardie=20
are
too open and need to be further constrained then I will = submit a draft that does
just that before the deadline. 


On July 8, 2020 at 10:36 PM Ben Campbell <=20 ben@nostrum.com> wrote:=20

Hi Tim,

Do you plan to submit an internet-draft? If so, please be ad= vised that the deadline for drafts prior to IETF108 is this coming Monday (= 7/13). If you submit a draft prior to the deadline, we can consider it alon= g with Ted=E2=80=99s draft (either on the list or possibly in the IETF108 D= ISPATCH meeting).

Thanks,

Ben.=20

On Jul 7, 2020, at 9:03 AM, Timothy Mcsweeney <=20 tim@dropnumber.com> wrote:

Hi All,

Updating RFC3405 will necessarily require changes to R= FC3401 as stated in its 
introduction.  "This document will be updated and= or obsoleted when changes
are made to the DDDS specifications."

We are now changing two RFCs so I don't think this fit= s as a
"simple administrative".

But, I may have a work around that is simple and also = solves the provisional registration problem as stated by Ted.  I could= have ready in a day or so.

Tim
On July 7, 2020 at 3:34 AM "Martin J. D=C3=BCrst" <= =20 duerst@it.aoyama.ac.jp> wrote:


On 23/06/2020 07:51, Ben Campbell wrote:
Hi Everyone,

The ART ADs have reminded the chairs that our charter= allows us to adopt =E2=80=9Csimple administrative=E2=80=9D work such as IA= NA registration documents. This draft seems to fit squarely in that categor= y.. Does anyone see a reason we shouldn=E2=80=99t just adopt it, with the e= xpectation of going immediately to WGLC? (The last-call timeline is the sam= e either way, either 2 weeks WGLC and 2 weeks IETF LC for a working group d= raft, or 4 weeks IETF LC for an AD sponsored draft.)

Triggered by the recent discussion, I had a look at Te= d's draft and the
mail up to today. To me, both AD sponsored and Dispatc= h WG look
reasonable, with a slight preference for the former (i= f asked to express
such a preference).

With respect to "pending registrations", I do not thin= k these are
relevant, in particular because the thing in question = isn't actually a
scheme, as discussed on the relevant list.

I have one comment: The abstract currently reads
"This document removes references to the IETF tree of = URI registrations
for registrations in URI.ARPA.". I found this hard to = read, and I guess
it's because of the "registrations for registrations" = piece. Unless one
is very familiar with the matter at hand, it's easy to= think that both
occurrences of "registration" are referencing the same= thing. While I'm
at it, it would also be good if the abstract mentioned= something
positive. I think a less normative version of (the sin= gle sentence that
is) Section 2 would serve well as the abstract.

Regards, Martin.

Thanks!

Ben (as co-chair)

On Jun 3, 2020, at 6:13 PM, Ted Hardie <=20 ted.ietf@gmail..com> wrote:

Howdy,

This is one the shortest drafts I've ever written:= =20 https://= datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ <=20 https:/= /datatracker.ietf...org/doc/draft-hardie-dispatch-rfc3405-update/> .= . Basically, RFC 3405 used to require that registrations in URI.ARPA be fro= m the "IETF Tree". That tree was deprecated after the document was publishe= d... As it happens, there are very few registrations in URI.ARPA, so we did= not catch it and fix it before now.

This draft updates RFC 3405 to require "permanent" s= cheme registrations. The salient bit is this:

All registrations in URI.ARPA MUST be for schemes wh= ich are permanent
registrations, as they are described in BCP 35.

I'm hoping for a quick dispatch of this, but happy t= o discuss.

regards,

Ted Hardie
_______________________________________________
dispatch mailing list



_______________________________________________
dispatch mailing list


--
Prof. Dr.sc. Martin J. D=C3=BCrst
Department of Intelligent Information Technology
College of Science and Engineering
Aoyama Gakuin University
Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan

_______________________________________________
dispatch mailing list
_______________________________________________=20
dispatch mailing list=20
dispatch@ietf.org=20
https://www.ietf.org/mailman/listinfo/= dispatch=20


 
_______________________________________________=20
dispatch mailing list=20
dispatch@ietf.org=20
https://www.ietf.org/mailman/listinfo/dispat= ch=20

 

 
_______________________________________________ dispatch mailing l= ist dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch

 
=20 From nobody Thu Jul 9 13:49:50 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 064153A0842 for ; Thu, 9 Jul 2020 13:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.276, MAY_BE_FORGED=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 YqELO9o-7WbM for ; Thu, 9 Jul 2020 13:49:45 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 27FFE3A083E for ; Thu, 9 Jul 2020 13:49:45 -0700 (PDT) Received: from bens-macbook.lan (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 069KnZZX031192 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 9 Jul 2020 15:49:37 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1594327779; bh=agd0ZbeuKV1mnlFVN7AUk5alK5V2ES0cN7M3qevIm48=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=pP27h8S/MIFRH0Sj8Ejg1B9R8vpqs1KQ3z0Sxku5v+k8478pdkoH2p6V/Omi1nR5I oU90PAT9HiV0JWQJKLUXiHz1h2zEFpWAgjIUASDUSRKn3eXfMVSlqjx/1x2J+lVqoh wXRKzS3Gf0H2P+6BrOQfIYIOQLEgNDwGMhCeE9bc= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be bens-macbook.lan Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Ben Campbell X-Priority: 3 In-Reply-To: <577450265.31749.1594326660123@email.ionos.com> Date: Thu, 9 Jul 2020 15:49:27 -0500 Cc: Ted Hardie , DISPATCH WG , Patrick McManus Content-Transfer-Encoding: quoted-printable Message-Id: <9F0CD6C0-DCA9-434D-83C0-2954D4896528@nostrum.com> References: <85664807-701C-4700-ABB7-D0434F14D6A0@nostrum.com> <1580898449.190942.1594130597348@email.ionos.com> <3A1C3068-717D-4822-A110-9F91272B04CB@nostrum.com> <2116535970.9156.1594304410818@email.ionos.com> <1777741348.21431.1594315737558@email.ionos.com> <166222013.29010.1594323818783@email.ionos.com> <577450265.31749.1594326660123@email.ionos.com> To: Timothy Mcsweeney X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2020 20:49:47 -0000 (as individual) I believe Ted refers to the sentence that says "In order to be inserted = into the URI.ARPA zone, the subsequent URI scheme MUST be registered = under the IETF URI tree.=E2=80=9D The fact that the following sentence = makes a now incorrect statement about the content of [BCP35] does not = mitigate the problem, nor does it change the MUST in the previous = sentence. So IMO, Ted is correct, there is a bug. Ben. So I agree with Ted=E2=80=99s interpretation that there is in fact a = bug. > On Jul 9, 2020, at 3:31 PM, Timothy Mcsweeney = wrote: >=20 > Yeah I looked at that a month ago already but unfortunately it doesn't = matter if you change the reference from [10] to [11] it still goes to = BCP35. Still no bug :-) >> On July 9, 2020 at 3:43 PM Timothy Mcsweeney = wrote:=20 >>=20 >> You're talking about the [ 10] reference in section 3.1.1 in 3405 and = when I click on the reference it sends me right to BCP35. >>=20 >> >The reason for the update is that IETF tree registrations *are* = required. >>=20 >> That is now, scheme registration is required, including provisionals. = See, no bug. >>=20 >> Tim >>=20 >>=20 >>=20 >>=20 >>> On July 9, 2020 at 3:09 PM Ted Hardie wrote:=20 >>>=20 >>> On Thu, Jul 9, 2020 at 10:28 AM Timothy Mcsweeney < = tim@dropnumber.com> wrote:=20 >>> Ted,=20 >>>=20 >>> Section 2 (Updated Requirements) of your draft says: >>> "All registrations in URI.ARPA MUST be for schemes which are = permanent registrations, as they are described in BCP 35." >>>=20 >>> I take that as: >>> We must update this because permanent registrations are not = required. Otherwise there is no reason for an update.=20 >>>=20 >>> The reason for the update is that IETF tree registrations *are* = required. That effectively closes the registry, without the community = having made the affirmative decision to do so. I want to fix that bug. =20= >>>=20 >>> I currently think that the closest replacement to the IETF tree = would be permanent registration and that we should fix this by requiring = that. But I'm happy to see a clear draft espousing some other way of = fixing the bug; if you have an idea about that, please write the draft. >>>=20 >>> regards, >>>=20 >>> Ted=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> If you are going to argue both sides, my draft and I will just stay = out of it. Here is your pointer. = https://www.ietf..org/id/draft-hardie-dispatch-rfc3405-update-01.html#sect= ion-2 >>>=20 >>> Tim >>>=20 >>>=20 >>>> On July 9, 2020 at 11:57 AM Ted Hardie < ted.ietf@gmail.com> wrote:=20= >>>>=20 >>>> Howdy,=20 >>>>=20 >>>> On Thu, Jul 9, 2020 at 7:20 AM Timothy Mcsweeney < = tim@dropnumber.com> wrote:=20 >>>> Hi Ben,=20 >>>>=20 >>>> Thanks for the heads up on the deadline, >>>>=20 >>>> I am a little surprised that you are choosing to discuss this at = all with pending=20 >>>> registrations and I obviously disagree with that. But if there are = more than 5 people besides Ted that think the current rules for = provisionals in the zone >>>>=20 >>>> I don't think I've seen anyone but you argue that the current rules = permit provisionals in the zone; if I have missed others reading the = rules that way, I'd appreciate a pointer. >>>>=20 >>>> I think, though, that the key thing is to get some clarity on what = the rules should be after the elimination of the IETF tree. Since you = obviously disagree with my proposal, having your alternative spelled in = a draft does seem like the best way forward. Wherever dispatch sends = the question would then have two clear proposals to choose between.=20 >>>>=20 >>>> regards, >>>>=20 >>>> Ted Hardie=20 >>>> are >>>> too open and need to be further constrained then I will submit a = draft that does >>>> just that before the deadline.=20 >>>>=20 >>>>=20 >>>>> On July 8, 2020 at 10:36 PM Ben Campbell < ben@nostrum.com> wrote:=20= >>>>>=20 >>>>> Hi Tim, >>>>>=20 >>>>> Do you plan to submit an internet-draft? If so, please be advised = that the deadline for drafts prior to IETF108 is this coming Monday = (7/13). If you submit a draft prior to the deadline, we can consider it = along with Ted=E2=80=99s draft (either on the list or possibly in the = IETF108 DISPATCH meeting). >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> Ben.=20 >>>>>=20 >>>>>> On Jul 7, 2020, at 9:03 AM, Timothy Mcsweeney < = tim@dropnumber.com> wrote: >>>>>>=20 >>>>>> Hi All, >>>>>>=20 >>>>>> Updating RFC3405 will necessarily require changes to RFC3401 as = stated in its=20 >>>>>> introduction. "This document will be updated and or obsoleted = when changes >>>>>> are made to the DDDS specifications." >>>>>>=20 >>>>>> We are now changing two RFCs so I don't think this fits as a >>>>>> "simple administrative". >>>>>>=20 >>>>>> But, I may have a work around that is simple and also solves the = provisional registration problem as stated by Ted. I could have ready = in a day or so. >>>>>>=20 >>>>>> Tim >>>>>>> On July 7, 2020 at 3:34 AM "Martin J. D=C3=BCrst" < = duerst@it.aoyama.ac.jp> wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>> On 23/06/2020 07:51, Ben Campbell wrote: >>>>>>>> Hi Everyone, >>>>>>>>=20 >>>>>>>> The ART ADs have reminded the chairs that our charter allows us = to adopt =E2=80=9Csimple administrative=E2=80=9D work such as IANA = registration documents. This draft seems to fit squarely in that = category.. Does anyone see a reason we shouldn=E2=80=99t just adopt it, = with the expectation of going immediately to WGLC? (The last-call = timeline is the same either way, either 2 weeks WGLC and 2 weeks IETF LC = for a working group draft, or 4 weeks IETF LC for an AD sponsored = draft.) >>>>>>>=20 >>>>>>> Triggered by the recent discussion, I had a look at Ted's draft = and the >>>>>>> mail up to today. To me, both AD sponsored and Dispatch WG look >>>>>>> reasonable, with a slight preference for the former (if asked to = express >>>>>>> such a preference). >>>>>>>=20 >>>>>>> With respect to "pending registrations", I do not think these = are >>>>>>> relevant, in particular because the thing in question isn't = actually a >>>>>>> scheme, as discussed on the relevant list. >>>>>>>=20 >>>>>>> I have one comment: The abstract currently reads >>>>>>> "This document removes references to the IETF tree of URI = registrations >>>>>>> for registrations in URI.ARPA.". I found this hard to read, and = I guess >>>>>>> it's because of the "registrations for registrations" piece. = Unless one >>>>>>> is very familiar with the matter at hand, it's easy to think = that both >>>>>>> occurrences of "registration" are referencing the same thing. = While I'm >>>>>>> at it, it would also be good if the abstract mentioned something >>>>>>> positive. I think a less normative version of (the single = sentence that >>>>>>> is) Section 2 would serve well as the abstract. >>>>>>>=20 >>>>>>> Regards, Martin. >>>>>>>=20 >>>>>>>> Thanks! >>>>>>>>=20 >>>>>>>> Ben (as co-chair) >>>>>>>>=20 >>>>>>>>> On Jun 3, 2020, at 6:13 PM, Ted Hardie < ted.ietf@gmail..com> = wrote: >>>>>>>>>=20 >>>>>>>>> Howdy, >>>>>>>>>=20 >>>>>>>>> This is one the shortest drafts I've ever written: = https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ < = https://datatracker.ietf...org/doc/draft-hardie-dispatch-rfc3405-update/> = .. Basically, RFC 3405 used to require that registrations in URI.ARPA be = from the "IETF Tree". That tree was deprecated after the document was = published... As it happens, there are very few registrations in = URI.ARPA, so we did not catch it and fix it before now. >>>>>>>>>=20 >>>>>>>>> This draft updates RFC 3405 to require "permanent" scheme = registrations. The salient bit is this: >>>>>>>>>=20 >>>>>>>>> All registrations in URI.ARPA MUST be for schemes which are = permanent >>>>>>>>> registrations, as they are described in BCP 35. >>>>>>>>>=20 >>>>>>>>> I'm hoping for a quick dispatch of this, but happy to discuss. >>>>>>>>>=20 >>>>>>>>> regards, >>>>>>>>>=20 >>>>>>>>> Ted Hardie >>>>>>>>> _______________________________________________ >>>>>>>>> dispatch mailing list >>>>>>>>> dispatch@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> dispatch mailing list >>>>>>>> dispatch@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>>>>>=20 >>>>>>>=20 >>>>>>> -- >>>>>>> Prof. Dr.sc. Martin J. D=C3=BCrst >>>>>>> Department of Intelligent Information Technology >>>>>>> College of Science and Engineering >>>>>>> Aoyama Gakuin University >>>>>>> Fuchinobe 5-1-10, Chuo-ku, Sagamihara >>>>>>> 252-5258 Japan >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> dispatch mailing list >>>>>>> dispatch@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>>> _______________________________________________=20 >>>>>> dispatch mailing list=20 >>>>>> dispatch@ietf.org=20 >>>>>> https://www.ietf.org/mailman/listinfo/dispatch=20 >>>>>=20 >>>>=20 >>>> =20 >>>> _______________________________________________=20 >>>> dispatch mailing list=20 >>>> dispatch@ietf.org=20 >>>> https://www.ietf.org/mailman/listinfo/dispatch=20 >>>=20 >>> =20 >>=20 >> =20 >> _______________________________________________ dispatch mailing list = dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch >=20 > =20 From nobody Thu Jul 9 17:08:35 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C77D3A09E3 for ; Thu, 9 Jul 2020 17:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 1E_18YENFRaF for ; Thu, 9 Jul 2020 17:08:32 -0700 (PDT) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 A892E3A09E9 for ; Thu, 9 Jul 2020 17:08:30 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id f7so4105197wrw.1 for ; Thu, 09 Jul 2020 17:08:30 -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; bh=VNH0xQvDArN733j9nl5BHv9dtZs5Ox0esit52qWHBMI=; b=HRi2MYuTGtXCBwT1VUJJqhRvMBwKmD6LKlXXRPOIzrpLvkSS1yPvnnjt7uPOm/Hlne Dx/SnZijUXe+YX8jKyDlp22sCdp5ASZSc8CKKz2i+kwnD3/sGu9SUwuhcmyXsCfI07c/ SdXdeE0mHu458gIM/8JCS5yol+yY8N2X2aWgfNkb9j8rb46e1H2IoY6aHhU98M0bm5md j5MBSP50d6bY63RxqU9upa/AM1zyzTuiwNIOMckeOD0DFCE7911CrUYRnxfP3IriVfNv wfRS1V35EMah8CtEd/mH1jlEDxRZPuNNR/6zUNLI6Bk536cxLJo5ipkdwbv3jXBKLq3F fKoQ== 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=VNH0xQvDArN733j9nl5BHv9dtZs5Ox0esit52qWHBMI=; b=bJUgbwRsRkcvVfN7Ixg4igXAHYBvSFdBOoHBdPUr1Eje62JEf/j/sFWW8l/XVhtX8l nN+DZMCijDm0ZAmo0ZFcZ43/Uhn+N78YGyClm9QBmAg6IUyEqHINtSCVN8ljzYNb6dag S8pCQRz+6eif+k78Mho1wUOiJ4lV6RQiK8eiqwaJKlGDzM+wQRTAxAu1MVKbvMfU2wVw S0CHzr2JJZGL26n6Cvsiwn2LOZsLegNMmkyfNQ2GYZT1R2X7/ONwvUvPQUM2XtlLOXa+ xAG3KTc2eeQJrhhS/gk/5YO9G8ODKzQ+X9LBDC+PUAN8oNz+U3bJ0f13ggCZGjFE9GK7 8gxQ== X-Gm-Message-State: AOAM530UIULquXR2qHBUUsZxV0iZXZk6RPnBxc6gsrkZaElVT3nTQ1sK 4tqQLAPg/N+dLf+K1XGdTPM+PytCINwQiS0NwPSe+V5v X-Google-Smtp-Source: ABdhPJwoPP6t4jp2RAwWeXNHlWe/5VbGGe0qSNVR/VOluhZKDZire6lD00gaOZEbXhwQI6elCoijfy2RILzWMPPi+5U= X-Received: by 2002:a5d:62d1:: with SMTP id o17mr63573819wrv.162.1594339708830; Thu, 09 Jul 2020 17:08:28 -0700 (PDT) MIME-Version: 1.0 From: E Sam Date: Thu, 9 Jul 2020 20:08:18 -0400 Message-ID: To: DISPATCH WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [dispatch] Forced SMTP redirects X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2020 00:08:34 -0000 Hello everyone, I have published a new internet-draft that might be of interest. As always, its on the Datatracker: https://datatracker.ietf.org/doc/draft-sam-smtp-redirects/ Some questions and thoughts for you: Should 557 be a separate response code or should we just redefine 551? I want to get your opinions. Even if mail clients don't end up trying to reach the new address or we end up making it so, it at least mandates the new replacement email to be included in the response. This would clear up any ambiguity with the existing 511 response code. Anyway, Let me know what you think! I think its a good idea, but some people here might think otherwise. I plan on writing more email related internet-drafts anyway. Just want to see what people think. There is the mail store WG but that seems like its geared more for protocols like IMAP than SMTP, so I have put it in DISPATCH. Obviously if there is something like a loop in redirects or an excessively long redirect loop; the mail client should give up. Note: as for the NNTP draft, I'll let my friend who is far more knowledgeable in Usenet (he even has his own server) work on that one. Have a good day! From nobody Thu Jul 9 18:59:49 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB773A0BCA for ; Thu, 9 Jul 2020 18:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=nqZ7A9ac; dkim=pass (1536-bit key) header.d=taugh.com header.b=Zune74/L 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 3qJPDHOqWdO1 for ; Thu, 9 Jul 2020 18:59:45 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 4206A3A0BC7 for ; Thu, 9 Jul 2020 18:59:44 -0700 (PDT) Received: (qmail 39746 invoked from network); 10 Jul 2020 01:59:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=9b3c.5f07cb8d.k2007; bh=/3xM7GDPFxLIu3nbpynF3jEhZDCKe15qSkPqufwK1nM=; b=nqZ7A9ac0o3Fffvzc99ux06jjszH1e/QPliwwjniMiHrvKvy04CVQuvjiopFG7xn1RCexfMjsX7hWf/Y9kLlab76jxkpU4HddM6O1mnXEYa0Bxh1cwXAGxkc/nkGaOFEmW+B5y4PburIX2HBtyKx1PSffWXd1oQMhu5sgsdhUPV7O0hQv9hK7yulVTIMstdeTfxg2DuOtqD9Kt8M/AE8Zo7N8kDxUnkdwzn7qKeJj/pUwlJhTIGDnjg6tFMfT+d9 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=9b3c.5f07cb8d.k2007; bh=/3xM7GDPFxLIu3nbpynF3jEhZDCKe15qSkPqufwK1nM=; b=Zune74/LhZ8oGbR4FXOr9ZqfhthFzAtKKTKP8H6vw7IRR6IRCzy2JbBtga6pSXadb0ADrET339hCAfzmWDQbq0NqxZOJyJYSnKoA3dIR4819XM2oQ9bYIsrlhAk6a2GK/kCgus9dflum5LL2sbhQ3gdyoMoB52YEJ1VNETTR5/Km593/b2kv+oATTYlm9alDzt2pjp+KGkT1J1ApA1MqhZNxhsPTbTOU4gTXJ+iBkKGeGIGzcugnmVRwkNJaeepk Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 10 Jul 2020 01:59:40 -0000 Received: by ary.qy (Postfix, from userid 501) id 0BE2D1C78A2F; Thu, 9 Jul 2020 21:59:47 -0400 (EDT) Date: 9 Jul 2020 21:59:47 -0400 Message-Id: <20200710015947.0BE2D1C78A2F@ary.qy> From: "John Levine" To: dispatch@ietf.org In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dispatch] Forced SMTP redirects X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2020 01:59:47 -0000 I'd suggest reposting this to the ietf-smtp list where people who've been around a lot longer than I have can explain why nobody implements 551 redirects (and as far as I can tell, nobody ever did) and there is assigning a different response code won't change that. It may seem like a good idea, but turns out not to work in practice. FWIW I looked through the last seven months of my mail server's logs and the total number of 551 responses is zero. R's, John PS: There have been some attempts at setting up change-of-address services where you can register old and new addresses, so mail servers could query them after getting a 550, and they never went anywhere either. See US Patents 6,654,789, 6,892,222, and 7,080,122. On the other hand, a lot of mail systems now let users keep their addresses after they leave, ranging from ISPs like Comcast and Spectrum to universities who turn student addresses into alumni addresses. They let you forward the mail, or you can add it to the list of accounts your MUA checks, or either or both. In article you write: >Hello everyone, > > >I have published a new internet-draft that might be of interest. > > >As always, its on the Datatracker: > >https://datatracker.ietf.org/doc/draft-sam-smtp-redirects/ From nobody Sun Jul 12 04:43:49 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C4D3A03F3 for ; Sun, 12 Jul 2020 04:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=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=itaoyama.onmicrosoft.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 m66zqe7Ml2kn for ; Sun, 12 Jul 2020 04:43:44 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-eopbgr1400137.outbound.protection.outlook.com [40.107.140.137]) (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 C86AD3A03F2 for ; Sun, 12 Jul 2020 04:43:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bMfc1IV91YfSbYvK+FcoqjJQvL7S5SaoFH44a6+h34dLIWVR5QTRPoHI9bkVnOZ8P8CulrZxuYoNcfBqenQ9ksfApRxn5B/0m0MykBEWUR83Nvq68mSWGiWiUatpjJy9EqH9ZcsBRkIMTpNOO4gyRKBFIdQJENRdMHR17IsNkpp8wG1IstWhKZc/fAtWHDI2TVhSxb2CvonQOPJ6Dbqc3Mv5TNo74jvU9AlBZNh4DC/1M0dILXNxj1wMtgnbXx/siGWJKKOyW6GAVb2C5t3yfFEuiZvjctC+SZHgzVhI+sEwOsRwZg71pM3QAEf2SqVs/tt9ft99GJznGE6VLNNSow== 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=LlOZVMF5paJ/zZmf19ZwT3etOuuqlVKd4EOf2JkWDkM=; b=hP0FCzqmhRzxClqd4GkG9vhtLf/WlHVYnkgRzqO8Fe7gGvt5A7NQqYsyDxSF9uAvLmSIveRE+PygI2xwdzOzwW/Jbel/oRVdGHUTasFPFjdww0zr7h2a89iKU9K76V+1M04kDR+m7meU7vg6vNS1ABPFIaoXqdRC+m4++utGQWwSjm3N9MYTMZS/cynN+ks70Veavm90okBDjZyjNO5zsI+fJthMp8KJggWtk7YtPDcx+H6uexzhAjyUIo310NEIguLqkZecnq3WJ/LJV5HbDGAQhr1+Lk/7dCl9fr6dXW9LZJgOocjpxsDZ9usO8FIJtpcc4TBa62eSim1JlLblBA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LlOZVMF5paJ/zZmf19ZwT3etOuuqlVKd4EOf2JkWDkM=; b=mAHwIqsZYHskfeIgycadZ6426pp1UyUQUHIp0/O1/IONimp+wsv0kjB4lgwb+KK/GqWUkslCULCgfQPnKInloLkMN26Ol6LjpJJlEVJnbVBr3xxc3l2kv6zvLgUDJF03i8nCxnkk8KYPvuVu4XtW9vbh0wEhS16kTcMoy7BsOns= Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from OSBPR01MB2566.jpnprd01.prod.outlook.com (2603:1096:604:1c::13) by OSBPR01MB3382.jpnprd01.prod.outlook.com (2603:1096:604:45::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.23; Sun, 12 Jul 2020 11:43:41 +0000 Received: from OSBPR01MB2566.jpnprd01.prod.outlook.com ([fe80::d1a0:ea71:e6f9:9778]) by OSBPR01MB2566.jpnprd01.prod.outlook.com ([fe80::d1a0:ea71:e6f9:9778%7]) with mapi id 15.20.3174.025; Sun, 12 Jul 2020 11:43:40 +0000 To: Timothy Mcsweeney , Ted Hardie Cc: Ben Campbell , DISPATCH WG , Patrick McManus References: <85664807-701C-4700-ABB7-D0434F14D6A0@nostrum.com> <1580898449.190942.1594130597348@email.ionos.com> <3A1C3068-717D-4822-A110-9F91272B04CB@nostrum.com> <2116535970.9156.1594304410818@email.ionos.com> <1777741348.21431.1594315737558@email.ionos.com> <166222013.29010.1594323818783@email.ionos.com> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: Date: Sun, 12 Jul 2020 20:43:39 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <166222013.29010.1594323818783@email.ionos.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: TYCPR01CA0118.jpnprd01.prod.outlook.com (2603:1096:405:4::34) To OSBPR01MB2566.jpnprd01.prod.outlook.com (2603:1096:604:1c::13) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.6] (125.203.82.4) by TYCPR01CA0118.jpnprd01.prod.outlook.com (2603:1096:405:4::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.21 via Frontend Transport; Sun, 12 Jul 2020 11:43:40 +0000 X-Originating-IP: [125.203.82.4] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8d05063c-3261-4598-d527-08d82658d2b3 X-MS-TrafficTypeDiagnostic: OSBPR01MB3382: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: QmmVafTd5Xc6kULZ6pNz6yweewRg2TOkuIg3H/HW8H260KFtizdosR9e2m+LNJrEnGDEgv951faH1Sm0gFQ0CfpKrKO/Q/gYBfRLYL9ZzdHFQ/bCGsZje/kXTUi7f1ycPDkFLRYg93MQH4IDxK9lWGw0d1xgmX9YybRZvVdrYpCUQIdUjeOYSVctH3xJeIYNHkwAPlrpordvVQjbQ1KDkoB/JHI0fMloKJEFscLVI0LDXRtkkBsN1X9GHa/QDqf6EeZW0tGEyNmyoM0S1cwluq5RW1gEKUPnYFKhcV75ct2ErSbpUeHveXT7GCkWLMpCuJSXER1lHY0ysWjfCUua50pjwTW7h7csvth2NH4hiBdTJEVoweluIXhiLDveVxSSUTQG8JdTOkXtggB8CCFat1C9ijBMFmtiPtQvln1UZt4mielboXnc6lTRDJzSjifeuWxtsxBvrnducITXAnarsw== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:OSBPR01MB2566.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(396003)(136003)(39840400004)(366004)(376002)(346002)(66574015)(26005)(186003)(16526019)(4326008)(786003)(16576012)(316002)(54906003)(86362001)(53546011)(31686004)(15650500001)(30864003)(5660300002)(110136005)(2616005)(8676002)(956004)(8936002)(31696002)(2906002)(36916002)(66946007)(508600001)(966005)(52116002)(66476007)(83380400001)(66556008)(6486002)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: hSXxCfhVxkbo6bT5oYibyJYEAgWt3V/t36fp7S/Tw00yqLdW6Dy3NzHbCUElTmDhpV91Z+IqoXcFSz5pB0IWegz5oTrtdMy8oC2gUKsOLqd3sLO/BwefzAZBsiFeXdJMBHJmw9x+0dZyCOW3rhUetrBNaeu4QLzsAIaJJCiB3Z29AjUQ6wKORk4Vj+4kAfJeXH8bnJKqur8IyN1RHBZ+ilS8dsHRt41abKL73wkmh9sQSluIqREVoyHM6W1jN+4oEajBFcJPcG5KzcwfOeUA9dmoPBcILTxoJTq4gIQQkKiFZdVzH4ip0qPhEao/P/C5SFs2E63Z0NkixPshA4ZCIHd0xREaK7pupBLl9D1kq7bB3oolWEAMjC1cCj0ltXEVn6SssOF6zKP+fPeEReTJwTc6hkyxGjNSRgZXmAGy2EPVgAZL2mLLirq+B2gNvMELLtEsdrir3Cp9cl9WCoi2xrjpjIrqEJ26+zepyNj3j6k= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 8d05063c-3261-4598-d527-08d82658d2b3 X-MS-Exchange-CrossTenant-AuthSource: OSBPR01MB2566.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jul 2020 11:43:40.9142 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: UxZCpwWQJ+QOQubsicuCaKoc7SdBqy8F0b63TMKZf3wy7WOjPzO6Iw25CZHpI2u4rJpC3grkbpw6/gdV83SjBg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSBPR01MB3382 Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2020 11:43:48 -0000 On 10/07/2020 04:43, Timothy Mcsweeney wrote: > You're talking about the [ 10 ] > reference in section 3.1.1 in 3405 > and when I click on the > reference it sends me right to BCP35 . When I look at >>>> [10] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", BCP 35, RFC 2717, January 1999. >>>> it has two links, one for BCP 35 (which now redirects to something else which doesn't actually match the reference data) and one for RFC 2717 (which matches the original reference, including author and date of publication). RFC 2717 then says: >>>> 2.2 The IETF Tree The IETF tree is intended for URL schemes of general interest to the Internet community. The tree exists for URL schemes that require a substantive review and approval process. It is expected that applicability statements for particular applications will be published from time to time that recommend implementation of, and support for, URL schemes that have proven particularly useful in those contexts. >>>> > >The reason for the update is that IETF tree registrations *are* required. Yes, and the closest to that ("URL schemes of general interest to the Internet community", "require a substantive review and approval process") we currently have is permanent registration, so that's where Ted's proposal (which I fully support) comes from. > That is now, scheme registration is required, including provisionals. See, no bug. No. That there's a link somewhere doesn't mean you can interpret things any which way. The reference you follow (in one specific way) comes from >>>> 3.1.1 Only Schemes in the IETF Tree Allowed In order to be inserted into the URI.ARPA zone, the subsequent URI scheme MUST be registered under the IETF URI tree. The requirements for this tree are specified in [10]. >>>> This means that the reference is for defining the requirements of the IETF URI tree. The current BCP 35 doesn't contain such requirements, and therefore doesn't make any sense. The old BCP 35 (RFC 2717) is clear, but is no longer in force. As a consequence, we have a dangling reference (IETF Tree is no longer defined in a valid IETF spec). We cannot just say "let's assume this means whatever suits me best" or "by chance there's a link (out of two) that leads to a spec that includes something that suits me", but we have to recognize that we have a problem with the spec (when updating BCP 35, its authors forgot to update RFC 3405), and have to fix that. And the fix that Ted is proposing is the fix that is closest to the original intent, and takes into account the reason for the original restriction. Regards, Martin. > Tim > > > > >> On July 9, 2020 at 3:09 PM Ted Hardie wrote: >> >> On Thu, Jul 9, 2020 at 10:28 AM Timothy Mcsweeney < tim@dropnumber.com >> > wrote: >> >> __ >> Ted, >> >> Section 2 (Updated Requirements) of your draft says: >> "All registrations in URI.ARPA MUST be for schemes which are permanent >> registrations, as they are described in BCP 35." >> >> I take that as: >> We must update this because permanent registrations are not required. >> Otherwise there is no reason for an update. >> >> >> The reason for the update is that IETF tree registrations *are* required. >> That effectively closes the registry, without the community having made the >> affirmative decision to do so. I want to fix that bug. >> >> I currently think that the closest replacement to the IETF tree would be >> permanent registration and that we should fix this by requiring that. But I'm >> happy to see a clear draft espousing some other way of fixing the bug; if you >> have an idea about that, please write the draft. >> >> regards, >> >> Ted >> >> >> >> >> >> If you are going to argue both sides, my draft and I will just stay out of >> it. Here is your pointer. >> https://www.ietf..org/id/draft-hardie-dispatch-rfc3405-update-01.html#section-2 >> >> >> >> Tim >> >> >>> On July 9, 2020 at 11:57 AM Ted Hardie < ted.ietf@gmail.com >>> > wrote: >>> >>> Howdy, >>> >>> On Thu, Jul 9, 2020 at 7:20 AM Timothy Mcsweeney < tim@dropnumber.com >>> > wrote: >>> >>> __ >>> Hi Ben, >>> >>> Thanks for the heads up on the deadline, >>> >>> I am a little surprised that you are choosing to discuss this at all >>> with pending >>> registrations and I obviously disagree with that. But if there are >>> more than 5 people besides Ted that think the current rules for >>> provisionals in the zone >>> >>> >>> I don't think I've seen anyone but you argue that the current rules >>> permit provisionals in the zone; if I have missed others reading the >>> rules that way, I'd appreciate a pointer. >>> >>> I think, though, that the key thing is to get some clarity on what the >>> rules should be after the elimination of the IETF tree. Since you >>> obviously disagree with my proposal, having your alternative spelled in a >>> draft does seem like the best way forward. Wherever dispatch sends the >>> question would then have two clear proposals to choose between. >>> >>> regards, >>> >>> Ted Hardie >>> >>> are >>> too open and need to be further constrained then I will submit a >>> draft that does >>> just that before the deadline. >>> >>> >>>> On July 8, 2020 at 10:36 PM Ben Campbell < ben@nostrum.com >>>> > wrote: >>>> >>>> Hi Tim, >>>> >>>> Do you plan to submit an internet-draft? If so, please be advised >>>> that the deadline for drafts prior to IETF108 is this coming Monday >>>> (7/13). If you submit a draft prior to the deadline, we can consider >>>> it along with Ted’s draft (either on the list or possibly in the >>>> IETF108 DISPATCH meeting). >>>> >>>> Thanks, >>>> >>>> Ben. >>>> >>>>> On Jul 7, 2020, at 9:03 AM, Timothy Mcsweeney < tim@dropnumber.com >>>>> > wrote: >>>>> >>>>> Hi All, >>>>> >>>>> Updating RFC3405 will necessarily require changes to RFC3401 as >>>>> stated in its >>>>> introduction. "This document will be updated and or obsoleted when >>>>> changes >>>>> are made to the DDDS specifications." >>>>> >>>>> We are now changing two RFCs so I don't think this fits as a >>>>> "simple administrative". >>>>> >>>>> But, I may have a work around that is simple and also solves the >>>>> provisional registration problem as stated by Ted. I could have >>>>> ready in a day or so. >>>>> >>>>> Tim >>>>>> On July 7, 2020 at 3:34 AM "Martin J. Dürst" < >>>>>> duerst@it.aoyama.ac.jp > wrote: >>>>>> >>>>>> >>>>>> On 23/06/2020 07:51, Ben Campbell wrote: >>>>>>> Hi Everyone, >>>>>>> >>>>>>> The ART ADs have reminded the chairs that our charter allows us >>>>>>> to adopt “simple administrative” work such as IANA registration >>>>>>> documents. This draft seems to fit squarely in that category.. >>>>>>> Does anyone see a reason we shouldn’t just adopt it, with the >>>>>>> expectation of going immediately to WGLC? (The last-call timeline >>>>>>> is the same either way, either 2 weeks WGLC and 2 weeks IETF LC >>>>>>> for a working group draft, or 4 weeks IETF LC for an AD sponsored >>>>>>> draft.) >>>>>> >>>>>> Triggered by the recent discussion, I had a look at Ted's draft >>>>>> and the >>>>>> mail up to today. To me, both AD sponsored and Dispatch WG look >>>>>> reasonable, with a slight preference for the former (if asked to >>>>>> express >>>>>> such a preference). >>>>>> >>>>>> With respect to "pending registrations", I do not think these are >>>>>> relevant, in particular because the thing in question isn't >>>>>> actually a >>>>>> scheme, as discussed on the relevant list. >>>>>> >>>>>> I have one comment: The abstract currently reads >>>>>> "This document removes references to the IETF tree of URI >>>>>> registrations >>>>>> for registrations in URI.ARPA.". I found this hard to read, and I >>>>>> guess >>>>>> it's because of the "registrations for registrations" piece. >>>>>> Unless one >>>>>> is very familiar with the matter at hand, it's easy to think that >>>>>> both >>>>>> occurrences of "registration" are referencing the same thing. >>>>>> While I'm >>>>>> at it, it would also be good if the abstract mentioned something >>>>>> positive. I think a less normative version of (the single sentence >>>>>> that >>>>>> is) Section 2 would serve well as the abstract. >>>>>> >>>>>> Regards, Martin. >>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> Ben (as co-chair) >>>>>>> >>>>>>>> On Jun 3, 2020, at 6:13 PM, Ted Hardie < ted.ietf@gmail..com >>>>>>>> > wrote: >>>>>>>> >>>>>>>> Howdy, >>>>>>>> >>>>>>>> This is one the shortest drafts I've ever written: >>>>>>>> https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ >>>>>>>> >>>>>>>> < >>>>>>>> https://datatracker.ietf...org/doc/draft-hardie-dispatch-rfc3405-update/> >>>>>>>> .. Basically, RFC 3405 used to require that registrations in >>>>>>>> URI.ARPA be from the "IETF Tree". That tree was deprecated after >>>>>>>> the document was published... As it happens, there are very few >>>>>>>> registrations in URI.ARPA, so we did not catch it and fix it >>>>>>>> before now. >>>>>>>> >>>>>>>> This draft updates RFC 3405 to require "permanent" scheme >>>>>>>> registrations. The salient bit is this: >>>>>>>> >>>>>>>> All registrations in URI.ARPA MUST be for schemes which are >>>>>>>> permanent >>>>>>>> registrations, as they are described in BCP 35. >>>>>>>> >>>>>>>> I'm hoping for a quick dispatch of this, but happy to discuss. >>>>>>>> >>>>>>>> regards, >>>>>>>> >>>>>>>> Ted Hardie >>>>>>>> _______________________________________________ >>>>>>>> dispatch mailing list >>>>>>>> dispatch@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> dispatch mailing list >>>>>>> dispatch@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>>>> >>>>>> >>>>>> -- >>>>>> Prof. Dr.sc. Martin J. Dürst >>>>>> Department of Intelligent Information Technology >>>>>> College of Science and Engineering >>>>>> Aoyama Gakuin University >>>>>> Fuchinobe 5-1-10, Chuo-ku, Sagamihara >>>>>> 252-5258 Japan >>>>>> >>>>>> _______________________________________________ >>>>>> dispatch mailing list >>>>>> dispatch@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >> > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > -- Prof. Dr.sc. Martin J. Dürst Department of Intelligent Information Technology College of Science and Engineering Aoyama Gakuin University Fuchinobe 5-1-10, Chuo-ku, Sagamihara 252-5258 Japan From nobody Mon Jul 13 06:33:50 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96FA23A11E6 for ; Mon, 13 Jul 2020 06:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=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 JLvopN2BJ7I5 for ; Mon, 13 Jul 2020 06:33:46 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (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 42D313A11E0 for ; Mon, 13 Jul 2020 06:33:46 -0700 (PDT) Received: from oxusgaltgw05.schlund.de ([10.72.72.51]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0Me9Ie-1kEBUt0fug-00Pvan; Mon, 13 Jul 2020 15:33:29 +0200 Date: Mon, 13 Jul 2020 09:33:27 -0400 (EDT) From: Timothy Mcsweeney Reply-To: Timothy Mcsweeney To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Cc: Ben Campbell , DISPATCH WG , Patrick McManus Message-ID: <630535283.101560.1594647207701@email.ionos.com> In-Reply-To: References: <85664807-701C-4700-ABB7-D0434F14D6A0@nostrum.com> <1580898449.190942.1594130597348@email.ionos.com> <3A1C3068-717D-4822-A110-9F91272B04CB@nostrum.com> <2116535970.9156.1594304410818@email.ionos.com> <1777741348.21431.1594315737558@email.ionos.com> <166222013.29010.1594323818783@email.ionos.com> MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.1-Rev32 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:hxWZjg9GZNHh6NEl3zIQJNbWHtRuURhrmuhzdXFvmoG1e+3MBiK EddQ9XMpKqzWkp1v4wrDJrkeXmnNWFKuhaIMvHThNZZYgQntR0PFPXx/qLd5Z6t/HQrBHh+ EmtCWgyDVKiH6uzRpHTTVStq6zDq5DFkblzCq6DosbkNQN8WTa8WYGrqXCz4KVPr5W4jxJx XlPWvvYx5E+EIxqoseLoA== X-UI-Out-Filterresults: notjunk:1;V03:K0:i3Q//A/yuac=:MneQ/Oh2GCVbOhb/LAnZLK UixE5LEdexiL/bNA3OJwZfDlI4q69o7U3izz04tXujYJpiRZ/iPTiaIqstB1yhWfelpA57x0I bEGv394Ld7FZops0L/fKfGG0ctAeNyDTNczTC7uDy43t+pCc2muGB6Q8DkE+e2a/xhYSL0SoW gpeUdcTKnx48nW8BeBsYPkn3n6MOV/7pe8XZ2p7CNQbq0gyKC3QAKgBaFekrEYKLcpVGgMG0P maMB3GbcXHqqv4UjI+Z51pScozHlNa0oSOveEmNUxqC21LJWyXSeuu+Pm1uApfN8cxeMycPFI dyucp1VDQ0pmSLnKG48SFHtNeUoSkJk16IgaO/cE91G0jaTwKsInSfUHVVWSRJvobqqSBijlE bN7j1JQTi/O2sMPo+qxaBf39OuNhJvxmg7+qymBptWDSKAgsKSbh6NGpDIQ/mFi9rzzEremsx 51+/lMmLFMde3tf37/YfkeEjsOSHXstd0B/xcWu2d6cvld3kuxxI2+0f8IrTqeCBQL2F33nnz Bj7B/Wwl5wcWTJwKYwEdJQoPbeAfyRXYXWuWEMjP0KSQUSbzLiNs7Kn06dZlrMy9uNG3zaSA8 26TT987v0U36DucfJVnQ7SWGZdACAvLvjIk9t2Hd5pE7Bh5MomAO1WeA/yjRQPVhlx13T/w1k cGy1lqfhiK28appvPA5Cdwh9ncywr39/7ePkNigLudylueTLhR4Y/PkvdfHTCAZx0gPG7x+P2 FA2tGb7uy9fvHX/mvbD8n9jOFAXEvVr2WUXL38cCieJ4RNEjKWIIru4kA+J0NbWy1P1S1bsgl l86G9Stkpz6JU1Kf9CaCjth/PRAHugOg4pwZbhGICdELOHBxHUD+J8cQxOz4GLKlNXlf5xn Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2020 13:33:49 -0000 =20 =20
Martin, 

>The current BCP 35 doesn't contain such requirements, and
>therefore doesn't make any sense.

That's right, BCP doesn't contain such requirements.
Whether or not makes sense to you is immaterial.
Thank you for helping me state my case.

Tim





On July 12, 2020 at 7:43 AM "Martin J. D=C3=BCrst" < duerst@it.aoyama.ac.jp>= ; wrote:


On 10/07/2020 04:43, Timothy Mcsweeney wrote:
reference in section 3.1.1 in 3405
When I look at

>>>>
[10] Petke, R. and I. King, "Registration Procedures for URL Scheme
Names", BCP 35, RFC 2717, January 1999.
>>>>
it has two links, one for BCP 35 (which now redirects to something else
which doesn't actually match the reference data) and one for RFC 2717
(which matches the original reference, including author and date of
publication).

RFC 2717 then says:

>>>>
2.2 The IETF Tree

The IETF tree is intended for URL schemes of general interest to the
Internet community. The tree exists for URL schemes that require a
substantive review and approval process. It is expected that
applicability statements for particular applications will be
published from time to time that recommend implementation of, and
support for, URL schemes that have proven particularly useful in
those contexts.
>>>>

>The reason for the update is that IETF tree registrations *are* re= quired.
Yes, and the closest to that ("URL schemes of general interest to the
Internet community", "require a substantive review and approval
process") we currently have is permanent registration, so that's where
Ted's proposal (which I fully support) comes from.

That is now, scheme registration is required, including provisionals. = See, no bug.
No. That there's a link somewhere doesn't mean you can interpret things
any which way. The reference you follow (in one specific way) comes fro= m

>>>>
3.1.1 Only Schemes in the IETF Tree Allowed

In order to be inserted into the URI.ARPA zone, the subsequent URI
scheme MUST be registered under the IETF URI tree. The requirements
for this tree are specified in [10].
>>>>

This means that the reference is for defining the requirements of the
IETF URI tree. The current BCP 35 doesn't contain such requirements, an= d
therefore doesn't make any sense. The old BCP 35 (RFC 2717) is clear,
but is no longer in force. As a consequence, we have a dangling
reference (IETF Tree is no longer defined in a valid IETF spec). We
cannot just say "let's assume this means whatever suits me best" or "by
chance there's a link (out of two) that leads to a spec that includes
something that suits me", but we have to recognize that we have a
problem with the spec (when updating BCP 35, its authors forgot to
update RFC 3405), and have to fix that.

And the fix that Ted is proposing is the fix that is closest to the
original intent, and takes into account the reason for the original
restriction.

Regards, Martin.


Tim




On July 9, 2020 at 3:09 PM Ted Hardie < ted.ietf@gmail.com> wrot= e:
>> On Thu, Jul 9, 2020 at 10:28 AM Timothy Mcsweeney <=20 tim@dropnumber.com
>> <mailto: tim@dropnumber.com>> wr= ote:
>>
>> __
>> Ted,
>>
>> Section 2 (Updated Requirements) of your draft says:
>> "All registrations in URI.ARPA MUST be for schemes which are p= ermanent
>> registrations, as they are described in BCP 35."
>>
>> I take that as:
>> We must update this because permanent registrations are not re= quired.
>> Otherwise there is no reason for an update.
>>
>>
>> The reason for the update is that IETF tree registrations *are= * required.
>> That effectively closes the registry, without the community ha= ving made the
>> affirmative decision to do so. I want to fix that bug.
>>
>> I currently think that the closest replacement to the IETF tre= e would be
>> permanent registration and that we should fix this by requirin= g that. But I'm
>> happy to see a clear draft espousing some other way of fixing = the bug; if you
>> have an idea about that, please write the draft.
>>
>> regards,
>>
>> Ted
>>
>>
>>
>>
>>
>> If you are going to argue both sides, my draft and I will just= stay out of
>> it. Here is your pointer.
>>
>>
>> Tim
>>
>>
>>> On July 9, 2020 at 11:57 AM Ted Hardie <=20 ted.ietf@gmail.com
>>> <mailto: ted.ietf@gmail.com>> wr= ote:
>>>
>>> Howdy,
>>>
>>> On Thu, Jul 9, 2020 at 7:20 AM Timothy Mcsweeney <=20 tim@dropnumber.com
>>> <mailto: tim@dropnumber.com>> wr= ote:
>>>
>>> __
>>> Hi Ben,
>>>
>>> Thanks for the heads up on the deadline,
>>>
>>> I am a little surprised that you are choosing to discuss t= his at all
>>> with pending
>>> registrations and I obviously disagree with that. But if t= here are
>>> more than 5 people besides Ted that think the current rule= s for
>>> provisionals in the zone
>>>
>>>
>>> I don't think I've seen anyone but you argue that the curr= ent rules
>>> permit provisionals in the zone; if I have missed others r= eading the
>>> rules that way, I'd appreciate a pointer.
>>>
>>> I think, though, that the key thing is to get some clarity= on what the
>>> rules should be after the elimination of the IETF tree. Si= nce you
>>> obviously disagree with my proposal, having your alternati= ve spelled in a
>>> draft does seem like the best way forward. Wherever dispat= ch sends the
>>> question would then have two clear proposals to choose bet= ween.
>>>
>>> regards,
>>>
>>> Ted Hardie
>>>
>>> are
>>> too open and need to be further constrained then I will su= bmit a
>>> draft that does
>>> just that before the deadline.
>>>
>>>
>>>> On July 8, 2020 at 10:36 PM Ben Campbell <=20 ben@nostrum.com
>>>> <mailto: ben@nostrum.com>> wrote:
>>>>
>>>> Hi Tim,
>>>>
>>>> Do you plan to submit an internet-draft? If so, please= be advised
>>>> that the deadline for drafts prior to IETF108 is this = coming Monday
>>>> (7/13). If you submit a draft prior to the deadline, w= e can consider
>>>> it along with Ted=E2=80=99s draft (either on the list = or possibly in the
>>>> IETF108 DISPATCH meeting).
>>>>
>>>> Thanks,
>>>>
>>>> Ben.
>>>>
>>>>> On Jul 7, 2020, at 9:03 AM, Timothy Mcsweeney <= =20 tim@dropnumber.com
>>>>> <mailto: tim@dropnumber.com>> wr= ote:
>>>>>
>>>>> Hi All,
>>>>>
>>>>> Updating RFC3405 will necessarily require changes = to RFC3401 as
>>>>> stated in its
>>>>> introduction. "This document will be updated and o= r obsoleted when
>>>>> changes
>>>>> are made to the DDDS specifications."
>>>>>
>>>>> We are now changing two RFCs so I don't think this= fits as a
>>>>> "simple administrative".
>>>>>
>>>>> But, I may have a work around that is simple and a= lso solves the
>>>>> provisional registration problem as stated by Ted.= I could have
>>>>> ready in a day or so.
>>>>>
>>>>> Tim
>>>>>> On July 7, 2020 at 3:34 AM "Martin J. D=C3=BCr= st" <
>>>>>>=20 duerst@it.aoyama.ac.jp &l= t;mailto: duerst@it.aoyama.ac..jp>&= gt; wrote:
>>>>>>
>>>>>>
>>>>>> On 23/06/2020 07:51, Ben Campbell wrote:
>>>>>>> Hi Everyone,
>>>>>>>
>>>>>>> The ART ADs have reminded the chairs that = our charter allows us
>>>>>>> to adopt =E2=80=9Csimple administrative=E2= =80=9D work such as IANA registration
>>>>>>> documents. This draft seems to fit squarel= y in that category..
>>>>>>> Does anyone see a reason we shouldn=E2=80= =99t just adopt it, with the
>>>>>>> expectation of going immediately to WGLC? = (The last-call timeline
>>>>>>> is the same either way, either 2 weeks WGL= C and 2 weeks IETF LC
>>>>>>> for a working group draft, or 4 weeks IETF= LC for an AD sponsored
>>>>>>> draft.)
>>>>>>
>>>>>> Triggered by the recent discussion, I had a lo= ok at Ted's draft
>>>>>> and the
>>>>>> mail up to today. To me, both AD sponsored and= Dispatch WG look
>>>>>> reasonable, with a slight preference for the f= ormer (if asked to
>>>>>> express
>>>>>> such a preference).
>>>>>>
>>>>>> With respect to "pending registrations", I do = not think these are
>>>>>> relevant, in particular because the thing in q= uestion isn't
>>>>>> actually a
>>>>>> scheme, as discussed on the relevant list.
>>>>>>
>>>>>> I have one comment: The abstract currently rea= ds
>>>>>> "This document removes references to the IETF = tree of URI
>>>>>> registrations
>>>>>> for registrations in URI.ARPA.". I found this = hard to read, and I
>>>>>> guess
>>>>>> it's because of the "registrations for registr= ations" piece.
>>>>>> Unless one
>>>>>> is very familiar with the matter at hand, it's= easy to think that
>>>>>> both
>>>>>> occurrences of "registration" are referencing = the same thing.
>>>>>> While I'm
>>>>>> at it, it would also be good if the abstract m= entioned something
>>>>>> positive. I think a less normative version of = (the single sentence
>>>>>> that
>>>>>> is) Section 2 would serve well as the abstract= .
>>>>>>
>>>>>> Regards, Martin.
>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> Ben (as co-chair)
>>>>>>>
>>>>>>>> On Jun 3, 2020, at 6:13 PM, Ted Hardie= <=20 ted.ietf@gmail..com
>>>>>>>> <mailto: ted.ietf@gmail.com>> wr= ote:
>>>>>>>>
>>>>>>>> Howdy,
>>>>>>>>
>>>>>>>> This is one the shortest drafts I've e= ver written:
>>>>>>>> <
>>>>>>>> .. Basically, RFC 3405 used to require= that registrations in
>>>>>>>> URI.ARPA be from the "IETF Tree". That= tree was deprecated after
>>>>>>>> the document was published... As it ha= ppens, there are very few
>>>>>>>> registrations in URI.ARPA, so we did n= ot catch it and fix it
>>>>>>>> before now.
>>>>>>>>
>>>>>>>> This draft updates RFC 3405 to require= "permanent" scheme
>>>>>>>> registrations. The salient bit is this= :
>>>>>>>>
>>>>>>>> All registrations in URI.ARPA MUST be = for schemes which are
>>>>>>>> permanent
>>>>>>>> registrations, as they are described i= n BCP 35.
>>>>>>>>
>>>>>>>> I'm hoping for a quick dispatch of thi= s, but happy to discuss.
>>>>>>>>
>>>>>>>> regards,
>>>>>>>>
>>>>>>>> Ted Hardie
>>>>>>>> ______________________________________= _________
>>>>>>>> dispatch mailing list
>>>>>>>>=20 dispatch@ietf.org <mailto: dispatch@ietf.org>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> __________________________________________= _____
>>>>>>> dispatch mailing list
>>>>>>>=20 dispatch@ietf.org <mailto: dispatch@ietf.org>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Prof. Dr.sc. Martin J. D=C3=BCrst
>>>>>> Department of Intelligent Information Technolo= gy
>>>>>> College of Science and Engineering
>>>>>> Aoyama Gakuin University
>>>>>> Fuchinobe 5-1-10, Chuo-ku, Sagamihara
>>>>>> 252-5258 Japan
>>>>>>
>>>>>> ______________________________________________= _
>>>>>> dispatch mailing list
>>>>>>=20 dispatch@ietf.org <mailto: dispatch@ietf.org>
>>>>> _______________________________________________
>>>>> dispatch mailing list
>>>>
>>>
>>> _______________________________________________
>>> dispatch mailing list
>>>
>>

_______________________________________________
dispatch mailing list

--
Prof. Dr.sc. Martin J. D=C3=BCrst
Department of Intelligent Information Technology
College of Science and Engineering
Aoyama Gakuin University
Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan
=20 From nobody Mon Jul 13 18:36:33 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9498C3A07E3 for ; Mon, 13 Jul 2020 18:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=mnot.net header.b=TS3o1sw7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=t3pqeFji 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 f0QXJf3_UQpv for ; Mon, 13 Jul 2020 18:36:31 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E709F3A077A for ; Mon, 13 Jul 2020 18:36:30 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 0F1AE268 for ; Mon, 13 Jul 2020 21:36:29 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 13 Jul 2020 21:36:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=from :content-type:content-transfer-encoding:mime-version:subject :message-id:date:to; s=fm3; bh=XV8jCMqnz8rdXPdUFI2v+vd4WlW9bndE5 UFtCdG7Kx0=; b=TS3o1sw7YK5iymrXDrC4XkrSQdBH+LEFm+hg+KZwPPPINEO0a HHFi3H8LjSuF3BM2Cg7+VK9GTvLRN2abMMZtA1uPnqBZnCNX9nlMKtG64GbGUzL7 mGFGxqJxtXJyBsNQ0bYCfqxCooCTDTk2nVFvDDE+hcGPl4OALdTrOdq+8e6KCfz8 TCj2FmPVGPRxNRwxkq2HneUZ4b3MHJVJjB80dI8tdNeqxnL3tmSxQFAW81aKNTKE W/6pgii3aV95B7Cn/eVqVQEpg2Z5kn8DHTX7MugSO4/dVa1/QL0o8uNbFWLv8fvW LD38cLUFbzofxbOdUnNkqroituQ2zrosAqauQ== 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=fm3; bh=XV8jCM qnz8rdXPdUFI2v+vd4WlW9bndE5UFtCdG7Kx0=; b=t3pqeFjihiFMwZkjNdezBb z4Gca46WmIVEMgrlp58zaNr/u8dhfCJcv3AiUdq9Dv0JFX6yBud6F+czemii78BD NA6R9XHPl/ecIaj/kQ5uSkekNfWpe8IUFKlZkVnzIC7D/SEocO+ZMHNICl2HdfKk CgwppIPnWNGnQwZDdyTqIi4FP2BRe8u7TuhPJFOb0LQkztQTtcRI49h5sX7iCrSV ODyZ5kMxaXwvfuIbpv+U75/xX9KZuBBTyv/sXKgAN1VHY1dvtKoxdz439zvktikt eByk4/2bGzQA9AVw1LwDArs3yHe1VvmUGAEmLVFD11960ZMyoi/Cuw4TTO62GYnA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrvdelgdegiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhtgfgggfukfffvffosehtqhhmtdhhtdejnecuhfhrohhmpeforghrkhcupfho thhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnh eptdevteeujedufedtgeeggfehlefhtdeludetieekvedtledutdfhffekkeetvedtnecu ffhomhgrihhnpehmnhhothdrnhgvthenucfkphepudduledrudejrdduheekrddvhedune cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohht sehmnhhothdrnhgvth X-ME-Proxy: Received: from marks-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 50CEB3280063 for ; Mon, 13 Jul 2020 21:36:28 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: <111A89F4-CBD6-4C63-A45A-C7458E7413FF@mnot.net> Date: Tue, 14 Jul 2020 11:36:25 +1000 To: DISPATCH WG X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [dispatch] A WG for HTTP API Building Blocks X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2020 01:36:33 -0000 I've been chatting with folks in the background for a while about = starting a WG to take on specs to help folks building HTTP APIs.[1] HTTP has been used for machine-to-machine communication for most of its = lifetime, there are a number of functions that are designed and = implemented in an ad hoc fashion, or with several competing approaches. = Establishing a WG to standardise some common functions might help, both = by documenting some common building blocks, and serving as a locus for a = new community -- one that's related to but distinct from the HTTP WG. For example, these specifications were either AD-sponsored or on the = Independent stream, but could have been in-scope for such a WG: - rfc6570 URI Template - rfc6892 The 'describes' Link Relation Type - rfc6901 JSON Pointer - rfc6902 JSON Patch - rfc7807 Problem Details for HTTP APIs - rfc8288 Web Linking - rfc8594 The Sunset HTTP Header Field - rfc8631 Link Relation Types for Web Services ... and there are also a number of current drafts that such a WG might = consider, e.g.: - draft-wilde-linkset - draft-nottingham-link-hint - draft-dalal-deprecation-header - draft-polli-ratelimit-headers This is the proposed charter: ~~~ HTTP APIs Working Group (HTTPAPI) HTTP is often for not only Web browsing, but also machine-to-machine = communication, often called '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: =E2=80=A2 Specifications for new HTTP header and/or trailer = fields =E2=80=A2 Specifications for new message body formats, or = conventions for use in them (e.g., patterns of JSON objects) =E2=80=A2 Proposals for new HTTP status codes, methods, or other = generic extensions, to be considered by the HTTP Working Group =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 = work items for APIs for specific use cases, and it will not define new = HTTP extension points, or new extensions that are likely to be used by = Web browsers. New work items can be added after a Call for Adoption on the working = group mailing list and consultation with the Area Director. 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. This Working Group will need to coordinate closely with the HTTP Working = Group. ~~~ Because a large part of the task here is building a representative = community, I think this group should be chartered without specific = documents; it can deliberate on what's appropriate to start with once = constituted. It should also be periodically evaluated to make sure that = it's functioning well and representative of the greater community, with = the assumption that if it isn't, it would be closed (I'd hope that ADs = do that for every WG anyway, but since this is trying to establish a new = venue, it should be considered on probation). The ADs have responded positively, and asked me to bring this to = DISPATCH for wider review. I'm happy to talk about it in the meeting if = there's time. Cheers, 1. a.k.a. "RESTful APIs", although that's a misunderstanding of what = REST is. -- Mark Nottingham https://www.mnot.net/ From nobody Mon Jul 13 18:50:07 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95A63A0D6C for ; Mon, 13 Jul 2020 18:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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=fastmailteam.com header.b=4IxWw/Af; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CCZ+sqTF 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 vbG8YRpwY6xJ for ; Mon, 13 Jul 2020 18:50:04 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F7743A0976 for ; Mon, 13 Jul 2020 18:50:04 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id AA7AB5C01ED for ; Mon, 13 Jul 2020 21:50:03 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Mon, 13 Jul 2020 21:50:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm3; bh=WlUtpdE 0FoP3dHgAbw1fbT/E7RjU8VH8w83ZXmFX45w=; b=4IxWw/AfnbKSY2b+N/mCNW1 kx/RO5wbh6lZZejUF1esyLuHwtGU32CKm390t/59tKxoLxk3B8VpSAlwpC8t9hKt K1KF0cvYlEx5FT6WuD52Ta9ovDCNlkXLUzpklKlH0pIVgptHLuj3BYkUZzu831Uc meZSPGlgLUhfKVo/tLQ0s2jQwAEXKvrxqHlNOqhK6kdp0sZfWuylbAftqgH+hnOR 4WGaP4fJnxaYKY6iMMvDYg4pemt6gh4sFaGqiw9S0VZksLgFVmYdEVvFpxLbvOqt fhSv05893TBkMSUbgeFYXS7vGiLMixmXk+vppm56fyie5ENltPjjnOEkm+k23oQ= = 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=fm3; bh=WlUtpd E0FoP3dHgAbw1fbT/E7RjU8VH8w83ZXmFX45w=; b=CCZ+sqTF7baQUXxrkl+2lA xV36IyYIk4UwGPuwys9AJClWep6FJ5JXG5EC32cVTWKQEDpUfI7y1dTGa2XGynos J9rIgpo77lcLgU0L+reUPLvLmsNMDYTLdkr4q9UHGEb65mTJQW5LUlPWxFfYgieS rSWf/eewo0lHV+TZuCIDJnYkNe/7Xl5roQI9KPTyknkL+6/LA4vfUos2uuFMVsMu WxaNoMGGCVRZ+2In8UY9u83omRu9v0CxfdqInZdyX+kHZBPmWkyvjIyldJB7wXqR GHoYlKzm36IaeBnTR+HmOGimOksB2nv9qvBF+KCFJ4U9okZG7wxJBhzym3e9V7Qw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrvdelgdegkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepvdduueeihefgvd ehueeujeejuedugfeigfevteefleetfeffgfdtjeejgfeuuddvnecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrih hlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3E467180125; Mon, 13 Jul 2020 21:50:03 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-637-g57f734b-fm-idx2020-20200709.002-g57f734bf Mime-Version: 1.0 Message-Id: <5e605403-e34c-4078-9bea-a57f35aac674@dogfood.fastmail.com> In-Reply-To: <111A89F4-CBD6-4C63-A45A-C7458E7413FF@mnot.net> References: <111A89F4-CBD6-4C63-A45A-C7458E7413FF@mnot.net> Date: Tue, 14 Jul 2020 11:49:41 +1000 From: "Bron Gondwana" To: dispatch@ietf.org Content-Type: multipart/alternative; boundary=a88ab5ee848245799bba2e23c24d27e3 Archived-At: Subject: Re: [dispatch] A WG for HTTP API Building Blocks X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2020 01:50:06 -0000 --a88ab5ee848245799bba2e23c24d27e3 Content-Type: text/plain On Tue, Jul 14, 2020, at 11:36, Mark Nottingham wrote: > I've been chatting with folks in the background for a while about starting a WG to take on specs to help folks building HTTP APIs.[1] I support this idea. > For example, these specifications were either AD-sponsored or on the Independent stream, but could have been in-scope for such a WG: > - rfc6570 URI Template > - rfc6892 The 'describes' Link Relation Type > - rfc6901 JSON Pointer > - rfc6902 JSON Patch > - rfc7807 Problem Details for HTTP APIs > - rfc8288 Web Linking > - rfc8594 The Sunset HTTP Header Field > - rfc8631 Link Relation Types for Web Services > > ... and there are also a number of current drafts that such a WG might consider, e.g.: > - draft-wilde-linkset > - draft-nottingham-link-hint > - draft-dalal-deprecation-header > - draft-polli-ratelimit-headers Particularly with such a large set of evidence in favour of the need for it! I do feel that there's some crossover to consider with the WPACK working group's work and non-realtime transfer of data. Cheers, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --a88ab5ee848245799bba2e23c24d27e3 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Tue, Jul 14, 2020, at 11:36, Mark Nottingham wrote:
=
I've been chatting with folks in the background for a whi= le about starting a WG to take on specs to help folks building HTTP APIs= .[1]

<= div style=3D"font-family:Arial;">I support this idea.

For example, these specifica= tions were either AD-sponsored or on the Independent stream, but could h= ave been in-scope for such a WG:
- rfc6570 URI Template
- = rfc6892 The 'describes' Link Relation Type
- rfc6901 JSON Pointer
- rfc6902 JSON Patch
= - rfc7807 Problem Details for HTTP APIs
- rfc8288 Web Linking
- rfc8594 The Sunset HTTP Header Field
- rfc8631 Link Relation Types for Web Services

... and there are also a number of= current drafts that such a WG might consider, e.g.:
- draft-wilde-linkset
- draft-nottingham-link-hint
- draft-dalal-deprecation-header
- draft-polli-ratelimit-headers

Particularly with such a large set of evidence in favour = of the need for it!

I do feel that there's some crossover= to consider with the WPACK working group's work and non-realtime transf= er of data.

Cheers,

Bron.

--
  Bron Gondwana, CEO, Fa= stmail Pty Ltd
  brong@fastmailteam.com


--a88ab5ee848245799bba2e23c24d27e3-- From nobody Mon Jul 13 22:14:27 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B3D3A102C; Mon, 13 Jul 2020 22:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 PmrbS4Rsq5Jb; Mon, 13 Jul 2020 22:14:22 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABBFB3A105C; Mon, 13 Jul 2020 22:14:21 -0700 (PDT) Received: from [172.16.42.100] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4B5TFy2Rqkz17pB; Tue, 14 Jul 2020 07:14:14 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann Date: Tue, 14 Jul 2020 07:14:13 +0200 Cc: json@ietf.org, cbor@ietf.org X-Mao-Original-Outgoing-Id: 616396453.48809-57f0931c8f541d04c3fe093b442b147f Content-Transfer-Encoding: quoted-printable Reply-To: dispatch@ietf.org Message-Id: <77B617C1-2148-4AE6-8428-DAD43D01FBC5@tzi.org> References: <159467093010.19477.7181341398452455173@ietfa.amsl.com> To: dispatch@ietf.org X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [dispatch] draft-goessner-dispatch-jsonpath-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2020 05:14:25 -0000 (Reply-To set to dispatch@ietf.org) I would like to initiate discussion for = draft-goessner-dispatch-jsonpath: https://www.ietf.org/id/draft-goessner-dispatch-jsonpath-00.html It says: > This document picks up the popular JSONPath specification dated > 2007-02-21 and provides a more normative definition for it. > It is intended as a submission to the IETF DISPATCH WG, in order to > find the right way to complete standardization of this specification. > In its current state, it is a strawman document showing what needs to > be covered. (For some reason the abstract landed in the Contributing note; typical = Internet-Draft deadline day botch.) This is a widely implemented specification that has been around for more = than a decade; now may be a good opportunity to finally go ahead and = turn it into a proper Internet standards document. The immediate cause = for writing this up now is that some IoT discovery work (some of which = happens in W3C) can make good use of JSONPath. Clearly, we already have = JSON Pointer (RFC 6901) for a more limited set of applications; the = specification would do good in defining how these two fit together. There is no active WG that immediately fits this work. Eventually CDDL may pick JSONPath up in the form of a predicate = operator; this might make the CBOR WG the right group (which probably = would then go ahead and write up another specification that makes = JSONPath useful for querying CBOR instances that go beyond the JSON = generic data model). Reopening the JSON WG may be another approach, as may be creating a = short-lived targeted WG. Please discuss! Gr=C3=BC=C3=9Fe, Carsten > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-goessner-dispatch-jsonpath-00.txt > Date: 2020-07-13 at 22:08:50 CEST > To: "Stefan G=C3=B6ssner" , "Stefan = Gossner" , "Carsten Bormann" = >=20 >=20 > A new version of I-D, draft-goessner-dispatch-jsonpath-00.txt > has been successfully submitted by Carsten Bormann and posted to the > IETF repository. >=20 > Name: draft-goessner-dispatch-jsonpath > Revision: 00 > Title: JSONPath -- XPath for JSON > Document date: 2020-07-12 > Group: Individual Submission > Pages: 14 > URL: = https://www.ietf.org/internet-drafts/draft-goessner-dispatch-jsonpath-00.t= xt > Status: = https://datatracker.ietf.org/doc/draft-goessner-dispatch-jsonpath/ > Htmlized: = https://tools.ietf.org/html/draft-goessner-dispatch-jsonpath-00 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-goessner-dispatch-jsonpath >=20 >=20 > Abstract: > insert abstract here >=20 >=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 From nobody Mon Jul 13 22:32:24 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8C03A1094 for ; Mon, 13 Jul 2020 22:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.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 jVKuggS1Wp0p for ; Mon, 13 Jul 2020 22:32:03 -0700 (PDT) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 E6F983A1093 for ; Mon, 13 Jul 2020 22:32:02 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id c11so10633508lfh.8 for ; Mon, 13 Jul 2020 22:32:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pIoIX5AteUHnh6Z2KNOJWVr0y+sNuILejdpxjFr/D5Y=; b=gm8QoWjMi/szV2m9VMrHJmDd+06BeW3auW5Tsbs9dzDUz8KADItH6n6NgaeHEsU706 /KqtbvwOlVXhQ0232ePSeDhWYtunm8goy8akgJoNCR/axT/dW7Uhn28x0wXlkjbRo6Bb +d966OkieUe6uXozHGn9rAh536aC9UI4FM17dNDl43+UV0yMsbkmcuOZwuFNmSIh1bFv LwOttDSx6JYwtugoh5PC66P10WNuKUss7KOZLlVExRQstitV0qBK3yiikdMGKExvntqO ObCtCXJFfgPXb5Ko+V3C2ReWZ0yEFEed2UZRlWn6ydQy1lH3Wuhfnmiu5R05pj0AjJsH zAdw== 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=pIoIX5AteUHnh6Z2KNOJWVr0y+sNuILejdpxjFr/D5Y=; b=ZmfYit/fBbnY1rxP1XCS2CXTumq77SzRRUqSv7oAADzQ2gedgoAeaqhbPjLkeBCjHz PZ03T7gmWjFwKaUybyI4SqxCs0UvmtbLDSpqvfEhNHHxmgFLi/QalmUTwd9sFPk44h2x 7xrlNLTJgB4o0Fh7tNUpvwon4UT4FUqH5RiwJKoI+/5a6PXJiOAMJGUj68+woC+ZLxrl ZNTc0T+4xXNTMEFllFMz84xt+19K2oR9x+Q9F5qbAlzVKgm8DFuFplHssL3XcLNXFT0x LNK5XzOwjKd7yIgDBFO6yrSCeUOB8UJ5iBH4U5NI5ZB29qd61+i6HcuDHUkguUT0f6ni r+PQ== X-Gm-Message-State: AOAM530+tL8UkmpJAojcZT02LYLaJMzALZxoxAhid+i27z2MB7l4yTlY 0Lc6ds2tNksXIUx8GDDPsNCSGWX0cIOsx+4lyPQXg8QpMhA= X-Google-Smtp-Source: ABdhPJzMwFogvX2gUSLErP48dvnn5NQFHMQBQBuXxQ65nob8f7mchla12/LUbVc5gCGf4BVbsvMJI+e34JtIKug42H4= X-Received: by 2002:ac2:4422:: with SMTP id w2mr1281492lfl.152.1594704720671; Mon, 13 Jul 2020 22:32:00 -0700 (PDT) MIME-Version: 1.0 References: <159467093010.19477.7181341398452455173@ietfa.amsl.com> <77B617C1-2148-4AE6-8428-DAD43D01FBC5@tzi.org> In-Reply-To: <77B617C1-2148-4AE6-8428-DAD43D01FBC5@tzi.org> From: Tim Bray Date: Mon, 13 Jul 2020 22:31:49 -0700 Message-ID: To: dispatch@ietf.org Cc: cbor@ietf.org, JSON WG Content-Type: multipart/alternative; boundary="00000000000065c69005aa60201d" Archived-At: Subject: Re: [dispatch] [Json] draft-goessner-dispatch-jsonpath-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2020 05:32:06 -0000 --00000000000065c69005aa60201d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable During my time at AWS I worked very heavily with JSONPath and lamented a useful referenceable spec. I would be happy to invest cycles into this work. There currently isn't a JSON working group but I suppose it wouldn't be too hard to reconstitute it for this purpose. On Mon, Jul 13, 2020 at 10:14 PM Carsten Bormann wrote: > (Reply-To set to dispatch@ietf.org) > > I would like to initiate discussion for draft-goessner-dispatch-jsonpath: > > https://www.ietf.org/id/draft-goessner-dispatch-jsonpath-00.html > > It says: > > > This document picks up the popular JSONPath specification dated > > 2007-02-21 and provides a more normative definition for it. > > It is intended as a submission to the IETF DISPATCH WG, in order to > > find the right way to complete standardization of this specification. > > In its current state, it is a strawman document showing what needs to > > be covered. > > (For some reason the abstract landed in the Contributing note; typical > Internet-Draft deadline day botch.) > > This is a widely implemented specification that has been around for more > than a decade; now may be a good opportunity to finally go ahead and turn > it into a proper Internet standards document. The immediate cause for > writing this up now is that some IoT discovery work (some of which happen= s > in W3C) can make good use of JSONPath. Clearly, we already have JSON > Pointer (RFC 6901) for a more limited set of applications; the > specification would do good in defining how these two fit together. > > There is no active WG that immediately fits this work. > > Eventually CDDL may pick JSONPath up in the form of a predicate operator; > this might make the CBOR WG the right group (which probably would then go > ahead and write up another specification that makes JSONPath useful for > querying CBOR instances that go beyond the JSON generic data model). > > Reopening the JSON WG may be another approach, as may be creating a > short-lived targeted WG. > > Please discuss! > > Gr=C3=BC=C3=9Fe, Carsten > > > > > Begin forwarded message: > > > > From: internet-drafts@ietf.org > > Subject: New Version Notification for > draft-goessner-dispatch-jsonpath-00.txt > > Date: 2020-07-13 at 22:08:50 CEST > > To: "Stefan G=C3=B6ssner" , "Stefan Gos= sner" > , "Carsten Bormann" > > > > > > A new version of I-D, draft-goessner-dispatch-jsonpath-00.txt > > has been successfully submitted by Carsten Bormann and posted to the > > IETF repository. > > > > Name: draft-goessner-dispatch-jsonpath > > Revision: 00 > > Title: JSONPath -- XPath for JSON > > Document date: 2020-07-12 > > Group: Individual Submission > > Pages: 14 > > URL: > https://www.ietf.org/internet-drafts/draft-goessner-dispatch-jsonpath-00.= txt > > Status: > https://datatracker.ietf.org/doc/draft-goessner-dispatch-jsonpath/ > > Htmlized: > https://tools.ietf.org/html/draft-goessner-dispatch-jsonpath-00 > > Htmlized: > https://datatracker.ietf.org/doc/html/draft-goessner-dispatch-jsonpath > > > > > > Abstract: > > insert abstract here > > > > > > > > > > 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 > > > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --00000000000065c69005aa60201d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dur= ing my time at AWS I worked very heavily with JSONPath and lamented a usefu= l referenceable spec. I would be happy to invest cycles into this work. The= re currently isn't a JSON working group but I suppose it wouldn't b= e too hard to reconstitute it for this purpose. =C2=A0

On Mon, Jul 13,= 2020 at 10:14 PM Carsten Bormann <cabo@= tzi.org> wrote:
(Reply-To set to dispatch@ietf.org)

I would like to initiate discussion for draft-goessner-dispatch-jsonpath:
https://www.ietf.org/id/draft-goessn= er-dispatch-jsonpath-00.html

It says:

> This document picks up the popular JSONPath specification dated
> 2007-02-21 and provides a more normative definition for it.
> It is intended as a submission to the IETF DISPATCH WG, in order to > find the right way to complete standardization of this specification.<= br> > In its current state, it is a strawman document showing what needs to<= br> > be covered.

(For some reason the abstract landed in the Contributing note; typical Inte= rnet-Draft deadline day botch.)

This is a widely implemented specification that has been around for more th= an a decade; now may be a good opportunity to finally go ahead and turn it = into a proper Internet standards document.=C2=A0 The immediate cause for wr= iting this up now is that some IoT discovery work (some of which happens in= W3C) can make good use of JSONPath.=C2=A0 Clearly, we already have JSON Po= inter (RFC 6901) for a more limited set of applications; the specification = would do good in defining how these two fit together.

There is no active WG that immediately fits this work.

Eventually CDDL may pick JSONPath up in the form of a predicate operator; t= his might make the CBOR WG the right group (which probably would then go ah= ead and write up another specification that makes JSONPath useful for query= ing CBOR instances that go beyond the JSON generic data model).

Reopening the JSON WG may be another approach, as may be creating a short-l= ived targeted WG.

Please discuss!

Gr=C3=BC=C3=9Fe, Carsten



> Begin forwarded message:
>
> From: in= ternet-drafts@ietf.org
> Subject: New Version Notification for draft-goessner-dispatch-jsonpath= -00.txt
> Date: 2020-07-13 at 22:08:50 CEST
> To: "Stefan G=C3=B6ssner" <stefan.goessner@fh-dortmund.de>= ;, "Stefan Gossner" <stefan.goessner@fh-dortmund.de>, "Ca= rsten Bormann" <c= abo@tzi.org>
>
>
> A new version of I-D, draft-goessner-dispatch-jsonpath-00.txt
> has been successfully submitted by Carsten Bormann and posted to the > IETF repository.
>
> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-goessner-dispatch-jsonpat= h
> Revision:=C2=A0 =C2=A0 =C2=A000
> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 JSONPath= -- XPath for JSON
> Document date:=C2=A0 =C2=A0 =C2=A0 =C2=A0 2020-07-12
> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individu= al Submission
> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 14
> URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-goess= ner-dispatch-jsonpath-00.txt
> Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-goessner-dispatch-jsonpa= th/
> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-goessner-dispatch-jsonpath-00
> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-goessner-dispatch-j= sonpath
>
>
> Abstract:
>=C2=A0 =C2=A0insert abstract here
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> The IETF Secretariat
>
>

_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json
--00000000000065c69005aa60201d-- From nobody Tue Jul 14 00:37:09 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6FFD3A11D9; Tue, 14 Jul 2020 00:37:04 -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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, 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 ojXb8ROAvs2H; Tue, 14 Jul 2020 00:37:02 -0700 (PDT) Received: from smtp.iit.cnr.it (mx4.iit.cnr.it [146.48.98.151]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 753A73A1313; Tue, 14 Jul 2020 00:36:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.iit.cnr.it (Postfix) with ESMTP id 52B0FB80272; Tue, 14 Jul 2020 09:36:46 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mx4.iit.cnr.it Received: from smtp.iit.cnr.it ([127.0.0.1]) by localhost (mx4.iit.cnr.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4PCMrv_Hk_Y; Tue, 14 Jul 2020 09:36:43 +0200 (CEST) Received: from [192.12.193.108] (pc-loffredo.nic.it [192.12.193.108]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by smtp.iit.cnr.it (Postfix) with ESMTPSA id 1DDBEB80227; Tue, 14 Jul 2020 09:36:43 +0200 (CEST) To: Tim Bray , dispatch@ietf.org Cc: cbor@ietf.org, JSON WG References: <159467093010.19477.7181341398452455173@ietfa.amsl.com> <77B617C1-2148-4AE6-8428-DAD43D01FBC5@tzi.org> From: Mario Loffredo Message-ID: <467d225e-6dcf-4e5f-1101-27e4c074c6af@iit.cnr.it> Date: Tue, 14 Jul 2020 09:33:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------884645419007A2EC64A0E4E8" Content-Language: it Archived-At: Subject: Re: [dispatch] [Json] draft-goessner-dispatch-jsonpath-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2020 07:37:05 -0000 This is a multi-part message in MIME format. --------------884645419007A2EC64A0E4E8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Il 14/07/2020 07:31, Tim Bray ha scritto: > During my time at AWS I worked very heavily with JSONPath and lamented > a useful referenceable spec. I would be happy to invest cycles into > this work. There currently isn't a JSON working group but I suppose it > wouldn't be too hard to reconstitute it for this purpose. +1 Mario > > On Mon, Jul 13, 2020 at 10:14 PM Carsten Bormann > wrote: > > (Reply-To set to dispatch@ietf.org ) > > I would like to initiate discussion for > draft-goessner-dispatch-jsonpath: > > https://www.ietf.org/id/draft-goessner-dispatch-jsonpath-00.html > > It says: > > > This document picks up the popular JSONPath specification dated > > 2007-02-21 and provides a more normative definition for it. > > It is intended as a submission to the IETF DISPATCH WG, in order to > > find the right way to complete standardization of this > specification. > > In its current state, it is a strawman document showing what > needs to > > be covered. > > (For some reason the abstract landed in the Contributing note; > typical Internet-Draft deadline day botch.) > > This is a widely implemented specification that has been around > for more than a decade; now may be a good opportunity to finally > go ahead and turn it into a proper Internet standards document.  > The immediate cause for writing this up now is that some IoT > discovery work (some of which happens in W3C) can make good use of > JSONPath.  Clearly, we already have JSON Pointer (RFC 6901) for a > more limited set of applications; the specification would do good > in defining how these two fit together. > > There is no active WG that immediately fits this work. > > Eventually CDDL may pick JSONPath up in the form of a predicate > operator; this might make the CBOR WG the right group (which > probably would then go ahead and write up another specification > that makes JSONPath useful for querying CBOR instances that go > beyond the JSON generic data model). > > Reopening the JSON WG may be another approach, as may be creating > a short-lived targeted WG. > > Please discuss! > > Grüße, Carsten > > > > > Begin forwarded message: > > > > From: internet-drafts@ietf.org > > Subject: New Version Notification for > draft-goessner-dispatch-jsonpath-00.txt > > Date: 2020-07-13 at 22:08:50 CEST > > To: "Stefan Gössner" >, "Stefan Gossner" > >, "Carsten Bormann" > > > > > > > > A new version of I-D, draft-goessner-dispatch-jsonpath-00.txt > > has been successfully submitted by Carsten Bormann and posted to the > > IETF repository. > > > > Name:         draft-goessner-dispatch-jsonpath > > Revision:     00 > > Title:                JSONPath -- XPath for JSON > > Document date:        2020-07-12 > > Group:                Individual Submission > > Pages:                14 > > URL: > https://www.ietf.org/internet-drafts/draft-goessner-dispatch-jsonpath-00.txt > > Status: > https://datatracker.ietf.org/doc/draft-goessner-dispatch-jsonpath/ > > Htmlized: > https://tools.ietf.org/html/draft-goessner-dispatch-jsonpath-00 > > Htmlized: > https://datatracker.ietf.org/doc/html/draft-goessner-dispatch-jsonpath > > > > > > Abstract: > >   insert abstract here > > > > > > > > > > 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 > > > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json -- Dr. Mario Loffredo Systems and Technological Development Unit Institute of Informatics and Telematics (IIT) National Research Council (CNR) via G. Moruzzi 1, I-56124 PISA, Italy Phone: +39.0503153497 Mobile: +39.3462122240 Web: http://www.iit.cnr.it/mario.loffredo --------------884645419007A2EC64A0E4E8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


Il 14/07/2020 07:31, Tim Bray ha scritto:
During my time at AWS I worked very heavily with JSONPath and lamented a useful referenceable spec. I would be happy to invest cycles into this work. There currently isn't a JSON working group but I suppose it wouldn't be too hard to reconstitute it for this purpose. 

+1

Mario


On Mon, Jul 13, 2020 at 10:14 PM Carsten Bormann <cabo@tzi.org> wrote:
(Reply-To set to dispatch@ietf.org)

I would like to initiate discussion for draft-goessner-dispatch-jsonpath:

https://www.ietf.org/id/draft-goessner-dispatch-jsonpath-00.html

It says:

> This document picks up the popular JSONPath specification dated
> 2007-02-21 and provides a more normative definition for it.
> It is intended as a submission to the IETF DISPATCH WG, in order to
> find the right way to complete standardization of this specification.
> In its current state, it is a strawman document showing what needs to
> be covered.

(For some reason the abstract landed in the Contributing note; typical Internet-Draft deadline day botch.)

This is a widely implemented specification that has been around for more than a decade; now may be a good opportunity to finally go ahead and turn it into a proper Internet standards document.  The immediate cause for writing this up now is that some IoT discovery work (some of which happens in W3C) can make good use of JSONPath.  Clearly, we already have JSON Pointer (RFC 6901) for a more limited set of applications; the specification would do good in defining how these two fit together.

There is no active WG that immediately fits this work.

Eventually CDDL may pick JSONPath up in the form of a predicate operator; this might make the CBOR WG the right group (which probably would then go ahead and write up another specification that makes JSONPath useful for querying CBOR instances that go beyond the JSON generic data model).

Reopening the JSON WG may be another approach, as may be creating a short-lived targeted WG.

Please discuss!

Grüße, Carsten



> Begin forwarded message:
>
> From: internet-drafts@ietf.org
> Subject: New Version Notification for draft-goessner-dispatch-jsonpath-00.txt
> Date: 2020-07-13 at 22:08:50 CEST
> To: "Stefan Gössner" <stefan.goessner@fh-dortmund.de>, "Stefan Gossner" <stefan.goessner@fh-dortmund.de>, "Carsten Bormann" <cabo@tzi.org>
>
>
> A new version of I-D, draft-goessner-dispatch-jsonpath-00.txt
> has been successfully submitted by Carsten Bormann and posted to the
> IETF repository.
>
> Name:         draft-goessner-dispatch-jsonpath
> Revision:     00
> Title:                JSONPath -- XPath for JSON
> Document date:        2020-07-12
> Group:                Individual Submission
> Pages:                14
> URL:            https://www.ietf.org/internet-drafts/draft-goessner-dispatch-jsonpath-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-goessner-dispatch-jsonpath/
> Htmlized:       https://tools.ietf.org/html/draft-goessner-dispatch-jsonpath-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-goessner-dispatch-jsonpath
>
>
> Abstract:
>   insert abstract here
>
>
>
>
> 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
>
>

_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json

_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json
-- 
Dr. Mario Loffredo
Systems and Technological Development Unit
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Mobile: +39.3462122240
Web: http://www.iit.cnr.it/mario.loffredo
--------------884645419007A2EC64A0E4E8-- From nobody Tue Jul 14 05:25:34 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25D13A0B80 for ; Tue, 14 Jul 2020 05:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 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, T_SPF_PERMERROR=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=brianrosen-net.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 RPxJFhm98kyQ for ; Tue, 14 Jul 2020 05:25:29 -0700 (PDT) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 2CFBA3A0B76 for ; Tue, 14 Jul 2020 05:25:29 -0700 (PDT) Received: by mail-il1-x132.google.com with SMTP id t27so13981820ill.9 for ; Tue, 14 Jul 2020 05:25:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=WgjgtHl/eLx4zF0CS7LWDxZwlRutT1zcU1sMJ25QQ2U=; b=1o+b3cwsFQPji2bHWdmDtkVToehwhMN7KxyKudWHUh1qswVFzYV8RkEXb3/6hx0wsg CNKfjRON+gFIglR5IaC9JRgfuxzKdPNDK1gPwoBvrW5AS0TynHLyrvdeyN+vBOczEnZp EUb6dy8d74ndBYsEwisVzRFduZ0Vm4dbEQAR2vcuaU/jEMUjjCMATIKwc6y5FIIeYuqX YFc7HKrma4KwQ0nvt+thps2T9sin5hXCOiO/1Onx66f2btmbxK+weInd89HBu7od252N lTufby4sm5P14KBpi9d+HtvSZpmHwi249sJ/WvaSw1Qb+Ezt4izIvz+xWCbyaMxloe7M 6t+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=WgjgtHl/eLx4zF0CS7LWDxZwlRutT1zcU1sMJ25QQ2U=; b=hE0MVV+M20McId0iu9MEqyDO0j0j2k4nC/1QeqnVo5LDhEACcVzH9FThfBMDPtzVzB 2El+cPgyPVEqz8qONx+RxtfF/MC+io2ja8rUS7kLe+Up4R/ZmTvUTPjk/EbpT2x2EMtK 8r0jAgO6JmBq7XV29K6hBr5FVv/fM1H1FPq57H8fKgOzp+DjI39sr0XkeMZ+ZeJ4ddh/ zmvtFByQIuK1leNHPTUibPTILro0aWSHVXXd7/PBWd0nO1gDbHpWADXyI+Xr2qjm8jvw /Z0VtAfblRfRyrG1CicVhjHzolew7COkywHVmh8bxurCgCoVG7GnxSS14hvJH3Ca/zFr AY9w== X-Gm-Message-State: AOAM530K0+M6CTN4widd3aDC+4/kivvh7ZZ1yJ1zlP6Hswl/ftKovoKA xfIPWhsrPYR3plPXD+FkwRB0XA== X-Google-Smtp-Source: ABdhPJytzImwYzrtgVlfv2t55uA2xDv/tS68xjbYS5Oi8c7p5Yt5kcu5O0Rx2V2XtBdlnm70kP4wFA== X-Received: by 2002:a92:aad6:: with SMTP id p83mr4160833ill.65.1594729528286; Tue, 14 Jul 2020 05:25:28 -0700 (PDT) Received: from brians-mbp-2871.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id f18sm9068754ion.47.2020.07.14.05.25.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Jul 2020 05:25:27 -0700 (PDT) From: Brian Rosen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9FCF87D4-63FA-423B-80C1-DF79640D5764" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 14 Jul 2020 08:25:24 -0400 In-Reply-To: <467d225e-6dcf-4e5f-1101-27e4c074c6af@iit.cnr.it> Cc: Tim Bray , dispatch@ietf.org, cbor@ietf.org, JSON WG To: Mario Loffredo References: <159467093010.19477.7181341398452455173@ietfa.amsl.com> <77B617C1-2148-4AE6-8428-DAD43D01FBC5@tzi.org> <467d225e-6dcf-4e5f-1101-27e4c074c6af@iit.cnr.it> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [dispatch] [Json] draft-goessner-dispatch-jsonpath-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2020 12:25:32 -0000 --Apple-Mail=_9FCF87D4-63FA-423B-80C1-DF79640D5764 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 And I note the discussion of an HTTP API working group, to which this = work would fit in. I=E2=80=99m currently working on a spec for emergency services that uses = jsonpath, and the lack of a referenceable spec was a big concern. =20 Brian > On Jul 14, 2020, at 3:33 AM, Mario Loffredo = wrote: >=20 >=20 >=20 > Il 14/07/2020 07:31, Tim Bray ha scritto: >> During my time at AWS I worked very heavily with JSONPath and = lamented a useful referenceable spec. I would be happy to invest cycles = into this work. There currently isn't a JSON working group but I suppose = it wouldn't be too hard to reconstitute it for this purpose. =20 > +1 >=20 > Mario >=20 >>=20 >> On Mon, Jul 13, 2020 at 10:14 PM Carsten Bormann > wrote: >> (Reply-To set to dispatch@ietf.org ) >>=20 >> I would like to initiate discussion for = draft-goessner-dispatch-jsonpath: >>=20 >> https://www.ietf.org/id/draft-goessner-dispatch-jsonpath-00.html = >>=20 >> It says: >>=20 >> > This document picks up the popular JSONPath specification dated >> > 2007-02-21 and provides a more normative definition for it. >> > It is intended as a submission to the IETF DISPATCH WG, in order to >> > find the right way to complete standardization of this = specification. >> > In its current state, it is a strawman document showing what needs = to >> > be covered. >>=20 >> (For some reason the abstract landed in the Contributing note; = typical Internet-Draft deadline day botch.) >>=20 >> This is a widely implemented specification that has been around for = more than a decade; now may be a good opportunity to finally go ahead = and turn it into a proper Internet standards document. The immediate = cause for writing this up now is that some IoT discovery work (some of = which happens in W3C) can make good use of JSONPath. Clearly, we = already have JSON Pointer (RFC 6901) for a more limited set of = applications; the specification would do good in defining how these two = fit together. >>=20 >> There is no active WG that immediately fits this work. >>=20 >> Eventually CDDL may pick JSONPath up in the form of a predicate = operator; this might make the CBOR WG the right group (which probably = would then go ahead and write up another specification that makes = JSONPath useful for querying CBOR instances that go beyond the JSON = generic data model). >>=20 >> Reopening the JSON WG may be another approach, as may be creating a = short-lived targeted WG. >>=20 >> Please discuss! >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >>=20 >>=20 >> > Begin forwarded message: >> >=20 >> > From: internet-drafts@ietf.org >> > Subject: New Version Notification for = draft-goessner-dispatch-jsonpath-00.txt >> > Date: 2020-07-13 at 22:08:50 CEST >> > To: "Stefan G=C3=B6ssner" >, "Stefan Gossner" = >, "Carsten Bormann" = > >> >=20 >> >=20 >> > A new version of I-D, draft-goessner-dispatch-jsonpath-00.txt >> > has been successfully submitted by Carsten Bormann and posted to = the >> > IETF repository. >> >=20 >> > Name: draft-goessner-dispatch-jsonpath >> > Revision: 00 >> > Title: JSONPath -- XPath for JSON >> > Document date: 2020-07-12 >> > Group: Individual Submission >> > Pages: 14 >> > URL: = https://www.ietf.org/internet-drafts/draft-goessner-dispatch-jsonpath-00.t= xt = >> > Status: = https://datatracker.ietf.org/doc/draft-goessner-dispatch-jsonpath/ = >> > Htmlized: = https://tools.ietf.org/html/draft-goessner-dispatch-jsonpath-00 = >> > Htmlized: = https://datatracker.ietf.org/doc/html/draft-goessner-dispatch-jsonpath = >> >=20 >> >=20 >> > Abstract: >> > insert abstract here >> >=20 >> >=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 >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json = >>=20 >>=20 >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json = > --=20 > Dr. Mario Loffredo > Systems and Technological Development Unit > Institute of Informatics and Telematics (IIT) > National Research Council (CNR) > via G. Moruzzi 1, I-56124 PISA, Italy > Phone: +39.0503153497 > Mobile: +39.3462122240 > Web: http://www.iit.cnr.it/mario.loffredo = ____________________________________= ___________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail=_9FCF87D4-63FA-423B-80C1-DF79640D5764 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1

And I = note the discussion of an HTTP API working group, to which this work = would fit in.

I=E2=80=99m currently working on a spec for emergency = services that uses jsonpath, and the lack of a referenceable spec was a = big concern.  

Brian

On Jul 14, 2020, at 3:33 AM, = Mario Loffredo <mario.loffredo@iit.cnr.it> wrote:

=20 =20


Il 14/07/2020 07:31, Tim Bray ha scritto:
During my time at AWS I worked very heavily with JSONPath and lamented a useful referenceable spec. I would be happy to invest cycles into this work. There currently isn't a JSON working group but I suppose it wouldn't be too hard to reconstitute it for this purpose. 

+1

Mario


On Mon, Jul 13, 2020 at = 10:14 PM Carsten Bormann <cabo@tzi.org> wrote:
(Reply-To set to dispatch@ietf.org)

I would like to initiate discussion for draft-goessner-dispatch-jsonpath:

https://www.ietf.org/id/draft-goessner-dispatch-jsonpath-00.htm= l

It says:

> This document picks up the popular JSONPath specification dated
> 2007-02-21 and provides a more normative definition for it.
> It is intended as a submission to the IETF DISPATCH WG, in order to
> find the right way to complete standardization of this specification.
> In its current state, it is a strawman document showing what needs to
> be covered.

(For some reason the abstract landed in the Contributing note; typical Internet-Draft deadline day botch.)

This is a widely implemented specification that has been around for more than a decade; now may be a good opportunity to finally go ahead and turn it into a proper Internet standards document.  The immediate cause for writing this = up now is that some IoT discovery work (some of which happens in W3C) can make good use of JSONPath.  Clearly, we already = have JSON Pointer (RFC 6901) for a more limited set of applications; the specification would do good in defining how these two fit together.

There is no active WG that immediately fits this work.

Eventually CDDL may pick JSONPath up in the form of a predicate operator; this might make the CBOR WG the right group (which probably would then go ahead and write up another specification that makes JSONPath useful for querying CBOR instances that go beyond the JSON generic data model).

Reopening the JSON WG may be another approach, as may be creating a short-lived targeted WG.

Please discuss!

Gr=C3=BC=C3=9Fe, Carsten



> Begin forwarded message:
>
> From: internet-drafts@ietf.org
> Subject: New Version Notification for draft-goessner-dispatch-jsonpath-00.txt
> Date: 2020-07-13 at 22:08:50 CEST
> To: "Stefan G=C3=B6ssner" <stefan.goessner@fh-dortmund.de>, "Stefan Gossner" <stefan.goessner@fh-dortmund.de>, "Carsten Bormann" <cabo@tzi.org>
>
>
> A new version of I-D, draft-goessner-dispatch-jsonpath-00.txt
> has been successfully submitted by Carsten Bormann and posted to the
> IETF repository.
>
> Name:        =  draft-goessner-dispatch-jsonpath
> Revision:     00
> Title:              =   JSONPath -- XPath for JSON
> Document date:        2020-07-12
> Group:              =   Individual Submission
> Pages:              =   14
> URL:            https://www.ietf.org/internet-drafts/draft-goessner-dispatch-js= onpath-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-goessner-dispatch-jsonpa= th/
> Htmlized:       https://tools.ietf.org/html/draft-goessner-dispatch-jsonpath-00=
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-goessner-dispatch-j= sonpath
>
>
> Abstract:
>   insert abstract here
>
>
>
>
> 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
>
>

_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json

_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/m=
ailman/listinfo/json
--=20
Dr. Mario Loffredo
Systems and Technological Development Unit
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Mobile: +39.3462122240
Web: http://www.iit.cnr.it/mario.=
loffredo
_______________________________________________
dispatch = mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

= --Apple-Mail=_9FCF87D4-63FA-423B-80C1-DF79640D5764-- From nobody Tue Jul 14 10:41:51 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0523A0C55 for ; Tue, 14 Jul 2020 10:41:50 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 oFFBsyXHyM3G for ; Tue, 14 Jul 2020 10:41:48 -0700 (PDT) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (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 87F793A0C4D for ; Tue, 14 Jul 2020 10:41:48 -0700 (PDT) Received: by mail-pf1-x433.google.com with SMTP id j20so7884958pfe.5 for ; Tue, 14 Jul 2020 10:41:48 -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=8R6IlSEtZKzxtngd/B17o1G/PhL9CriG8M9nfVsrzsc=; b=I8SaP4p8rNb2YBwP77K2m6Ge/E9sNqb1uPqWdmn1l2zjpOVI/XJJEnJtwDSN682M2K o/PX/40vVzM7wbsA6pEbEz/C2kCkcR5LxRpnhnYOH+/SdmYRdBUNVajrYaAvJ5liGwxP ikOilsMJjTUCkEFYzo7h2SzA2ioXu8RI0IWY4KMGy4PepaawKma2Oz3r719BtVNSfqr7 e+c3Wyaz85AlHzFDW5OOCDH3rvE/qBiZHNVl6H/jRVTkX07fuTuzqMjYyiYVh0Exg/Ly Z/nC6/08NHaL/2Bta4A5S0b9tL1ZPNKKsa+jD6jgn0MPLNVT4WmtwuV0lCslvakVprqi Uyaw== 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=8R6IlSEtZKzxtngd/B17o1G/PhL9CriG8M9nfVsrzsc=; b=OpT2XipPZRUhv+SLCoAc04PFoDHzQ0ceJG2pndy54oBfOafiKSjzzv/U7dwiVaCmpa 6t5Kc0KSOLzhsFHeA8l5iU4Tf33u52AAs4DK8jVcf/hz95+BLNmjKWbfAQF6h9S1tYCn gGmBsClaLnUQD/q6CSL8efgSWU77nY9GX+XJ99Y/+rYzOwVuI73pt/VEBK1R7qdFQe2h QgogTe+7XkkbZx8TZ1OXGVg4yPDeKoYExMEi/16H409K2ghYYC4tklg3j8NehYiQjcae wuDIlXXZA/jfloOOoNB1vuPsOSBGBYjdOwFkqr4X33FPVMHXF10Xnwmco2szdmJ+RgBG eLjA== X-Gm-Message-State: AOAM530bIT8j3dw5z/hqpoj4wSDUlD+RY6elpEPHMdoIvCbw6v4XYmGS ZVEDqbLrpNhj517ZGs0IEVNvkTFbRzwiNbKEEM0OyQ== X-Google-Smtp-Source: ABdhPJx9rUMrq/Z8INkQLQauF/YDSoz459oYA4cipnO0WeUmTwtVU3mwIuptOp7twiWf8/HLosm/3z8p+dzJCbEo4c0= X-Received: by 2002:a62:be06:: with SMTP id l6mr5382144pff.310.1594748508054; Tue, 14 Jul 2020 10:41:48 -0700 (PDT) MIME-Version: 1.0 References: <111A89F4-CBD6-4C63-A45A-C7458E7413FF@mnot.net> In-Reply-To: <111A89F4-CBD6-4C63-A45A-C7458E7413FF@mnot.net> From: Mary Barnes Date: Tue, 14 Jul 2020 12:41:36 -0500 Message-ID: To: Mark Nottingham Cc: DISPATCH WG Content-Type: multipart/alternative; boundary="00000000000054292305aa6a52d2" Archived-At: Subject: Re: [dispatch] A WG for HTTP API Building Blocks X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2020 17:41:50 -0000 --00000000000054292305aa6a52d2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think it's a great idea and yes on [1] - the vast majority don't understand REST. And, not all HTTPS APIs that are called RESTful (or even worse "REST API"s) actually follow the REST model - i.e., folks are using it as a generic term for any API using HTTPS. Regards, Mary. On Mon, Jul 13, 2020 at 8:36 PM Mark Nottingham wrote: > I've been chatting with folks in the background for a while about startin= g > a WG to take on specs to help folks building HTTP APIs.[1] > > HTTP has been used for machine-to-machine communication for most of its > lifetime, there are a number of functions that are designed and implement= ed > in an ad hoc fashion, or with several competing approaches. Establishing = a > WG to standardise some common functions might help, both by documenting > some common building blocks, and serving as a locus for a new community -= - > one that's related to but distinct from the HTTP WG. > > For example, these specifications were either AD-sponsored or on the > Independent stream, but could have been in-scope for such a WG: > - rfc6570 URI Template > - rfc6892 The 'describes' Link Relation Type > - rfc6901 JSON Pointer > - rfc6902 JSON Patch > - rfc7807 Problem Details for HTTP APIs > - rfc8288 Web Linking > - rfc8594 The Sunset HTTP Header Field > - rfc8631 Link Relation Types for Web Services > > ... and there are also a number of current drafts that such a WG might > consider, e.g.: > - draft-wilde-linkset > - draft-nottingham-link-hint > - draft-dalal-deprecation-header > - draft-polli-ratelimit-headers > > This is the proposed charter: > ~~~ > HTTP APIs Working Group (HTTPAPI) > > HTTP is often for not only Web browsing, but also machine-to-machine > communication, often called '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: > =E2=80=A2 Specifications for new HTTP header and/or trailer field= s > =E2=80=A2 Specifications for new message body formats, or convent= ions for > use in them (e.g., patterns of JSON objects) > =E2=80=A2 Proposals for new HTTP status codes, methods, or other = generic > extensions, to be considered by the HTTP Working Group > =E2=80=A2 Best practices and other documentation for HTTP API des= igners, > consumers, implementers, operators, etc. > > Other items are out of scope. In particular, this WG will not take on wor= k > items for APIs for specific use cases, and it will not define new HTTP > extension points, or new extensions that are likely to be used by Web > browsers. > > New work items can be added after a Call for Adoption on the working grou= p > mailing list and consultation with the Area Director. > > 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. > > This Working Group will need to coordinate closely with the HTTP Working > Group. > ~~~ > > Because a large part of the task here is building a representative > community, I think this group should be chartered without specific > documents; it can deliberate on what's appropriate to start with once > constituted. It should also be periodically evaluated to make sure that > it's functioning well and representative of the greater community, with t= he > assumption that if it isn't, it would be closed (I'd hope that ADs do tha= t > for every WG anyway, but since this is trying to establish a new venue, i= t > should be considered on probation). > > The ADs have responded positively, and asked me to bring this to DISPATCH > for wider review. I'm happy to talk about it in the meeting if there's ti= me. > > Cheers, > > > 1. a.k.a. "RESTful APIs", although that's a misunderstanding of what REST > is. > > -- > Mark Nottingham https://www.mnot.net/ > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --00000000000054292305aa6a52d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think it's a great idea and yes on [1] - the vast ma= jority don't understand REST.=C2=A0 =C2=A0 And, not all HTTPS APIs that= are called RESTful (or even worse "REST API"s) actually follow t= he REST model - i.e., folks are using it as a generic term for any API usin= g HTTPS.=C2=A0

Regards,
Mary.=C2=A0

On Mo= n, Jul 13, 2020 at 8:36 PM Mark Nottingham <mnot@mnot.net> wrote:
I've been chatting with folks in the background for a= while about starting a WG to take on specs to help folks building HTTP API= s.[1]

HTTP has been used for machine-to-machine communication for most of its lif= etime, there are a number of functions that are designed and implemented in= an ad hoc fashion, or with several competing approaches. Establishing a WG= to standardise some common functions might help, both by documenting some = common building blocks, and serving as a locus for a new community -- one t= hat's related to but distinct from the HTTP WG.

For example, these specifications were either AD-sponsored or on the Indepe= ndent stream, but could have been in-scope for such a WG:
=C2=A0- rfc6570 URI Template
=C2=A0- rfc6892 The 'describes' Link Relation Type
=C2=A0- rfc6901 JSON Pointer
=C2=A0- rfc6902 JSON Patch
=C2=A0- rfc7807 Problem Details for HTTP APIs
=C2=A0- rfc8288 Web Linking
=C2=A0- rfc8594 The Sunset HTTP Header Field
=C2=A0- rfc8631 Link Relation Types for Web Services

... and there are also a number of current drafts that such a WG might cons= ider, e.g.:
=C2=A0- draft-wilde-linkset
=C2=A0- draft-nottingham-link-hint
=C2=A0- draft-dalal-deprecation-header
=C2=A0- draft-polli-ratelimit-headers

This is the proposed charter:
~~~
HTTP APIs Working Group (HTTPAPI)

HTTP is often for not only Web browsing, but also machine-to-machine commun= ication, often called 'HTTP APIs'. This Working Group will standard= ise HTTP protocol extensions for use in such cases, with a focus on buildin= g blocks for separate or combined use.

Its output can include:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 Specifications for new HTTP header an= d/or trailer fields
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 Specifications for new message body f= ormats, or conventions for use in them (e.g., patterns of JSON objects)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 Proposals for new HTTP status codes, = methods, or other generic extensions, to be considered by the HTTP Working = Group
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 Best practices and other documentatio= n 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 APIs for specific use cases, and it will not define new HTTP exte= nsion points, or new extensions that are likely to be used by Web browsers.=

New work items can be added after a Call for Adoption on the working group = mailing list and consultation with the Area Director.

To be successful, this Working Group will need to have active and broad rep= resentation from across the industry -- e.g., API gateway vendors (and othe= r intermediaries), API consultants, API tool vendors, in-house API teams. T= herefore, adopted proposals should have public support from multiple implem= enters and/or deployments before being sent to the IESG.

This Working Group will need to coordinate closely with the HTTP Working Gr= oup.
~~~

Because a large part of the task here is building a representative communit= y, I think this group should be chartered without specific documents; it ca= n deliberate on what's appropriate to start with once constituted. It s= hould also be periodically evaluated to make sure that it's functioning= well and representative of the greater community, with the assumption that= if it isn't, it would be closed (I'd hope that ADs do that for eve= ry WG anyway, but since this is trying to establish a new venue, it should = be considered on probation).

The ADs have responded positively, and asked me to bring this to DISPATCH f= or wider review. I'm happy to talk about it in the meeting if there'= ;s time.

Cheers,


1. a.k.a. "RESTful APIs", although that's a misunderstanding = of what REST is.

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--00000000000054292305aa6a52d2-- From nobody Tue Jul 14 12:59:16 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC963A07D4 for ; Tue, 14 Jul 2020 12:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 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, T_SPF_PERMERROR=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=brianrosen-net.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 7e_KIY99hKpQ for ; Tue, 14 Jul 2020 12:59:12 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 5F2883A0A8B for ; Tue, 14 Jul 2020 12:59:12 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id y2so18647150ioy.3 for ; Tue, 14 Jul 2020 12:59:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ewdPoAQLa51MWmvH1CRZffCkQxQQzP384b3nRyO7UKw=; b=MHG0MmRFhb8sMWWnkGHX/0YFyFTbREFjAHt7Ek7q91dSkL5pMFcC2Y3zq7QNT/wejw mf+Rc5nnGIeZ9aH7Utr8qmSl0m8UnO89Efso7CgPK8WGVkyR7u1aTLT9c0Eso+A2q56I cBpa0JlrsqLI+mezOlpo06HFxYedj/VxmG8/Hns7qZlCiuIDD7n9WUwdn6V5nuRdaBQA x4s6nGck73TsXqcEPGqT/uB4GuNe5/DFnpAQ86FecyLACP2jcSHU4LKSJaU8ejkwYAJe 1dvmCE3j3uHUfoRbA/w8xjaBg5PrJFW5Td4eLVcDrk1x35XgZQey3BSs9hJOB7noK6tc B7MA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ewdPoAQLa51MWmvH1CRZffCkQxQQzP384b3nRyO7UKw=; b=cANh29lBfEZiQPE74SPbwphRSwEQkjn4zHAdv5tKWVpJFgSF0URSRUjeJzXV34HkWc EEeIvkHd9PBN0KKHn7haaP1xNAK8gC1+yOhraEQOOeoKMF4ChpnCLwlUWlJNHMLjqDXX bt5FRE0rl27Qg0IZypu9hh7NjhTcg1ACjQ0NrYA3eouP9JBsAoBD3cRAMHDUYLRUWMC3 IdrWp+IYkLcoYY0qA2epP6Fx+ivdvouYZuJ3ut8URs6JH2CqwG4Xnch3/xZFeP8kWQln FBbPUoVT3/xgt3jNOuZmJ+vTpTUp69WOb9um49Nc/bNY9daUAp5MY8//cFjAjmhwRUE5 W11g== X-Gm-Message-State: AOAM530kUsodTW7uVH2eGQX3Pe3XVDdGwuCuraLwnQTgUZlkx/HsrArr 7BVOoKjUjiFKkVCFj2iHSE6teA== X-Google-Smtp-Source: ABdhPJzgOEsEQTgMp24adh808ns7Cv3I13Bjp8x54FI3iCWm0xq9nuEmOd6REDTGo8gD7LvxaHXeWQ== X-Received: by 2002:a05:6638:2482:: with SMTP id x2mr7605261jat.55.1594756751581; Tue, 14 Jul 2020 12:59:11 -0700 (PDT) Received: from brians-mbp-2871.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id t6sm14448ioi.20.2020.07.14.12.59.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Jul 2020 12:59:11 -0700 (PDT) From: Brian Rosen Message-Id: <7414026C-4726-4C8E-8C9C-60A81F5456B5@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_C8B9BE24-EC0D-4001-A9C3-E2FE93916FD1" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 14 Jul 2020 15:59:09 -0400 In-Reply-To: Cc: Mark Nottingham , DISPATCH WG To: Mary Barnes References: <111A89F4-CBD6-4C63-A45A-C7458E7413FF@mnot.net> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [dispatch] A WG for HTTP API Building Blocks X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2020 19:59:16 -0000 --Apple-Mail=_C8B9BE24-EC0D-4001-A9C3-E2FE93916FD1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Don=E2=80=99t get me started on what is and isn=E2=80=99t RESTful. = There is NO definition, no generally accepted standard, and not even = commonly agreed principals. It=E2=80=99s a wild, Wild West and anyone = that claims to know what is and isn=E2=80=99t RESTful is, IMHO, = mistaken. Fortunately, we don=E2=80=99t need to have such a definition = to do all these good things. In fact, it's good that the charter avoids saying REST. I=E2=80=99d = like to keep it that way. One question about the charter: We=E2=80=99re going to see an = increasing incidence of defining protocols using json and HTTP in our = work. It would be good if the IETF had some common way these interfaces = were defined: not just the schemas but the operations. This is the = domain of OpenAPI, for example, which could be a candidate for what = I=E2=80=99m asking about. Is that something that would be a chartered = item? I=E2=80=99d be willing to work on that. Not proscriptive, just = advisory =E2=80=94 there are going to be plenty of interfaces that = wouldn=E2=80=99t fit, but things that use an HTTP verb, take some = parameters in, possibly including json objects, and return some json = response could benefit from some common defined way to describe them. Brian > On Jul 14, 2020, at 1:41 PM, Mary Barnes = wrote: >=20 > I think it's a great idea and yes on [1] - the vast majority don't = understand REST. And, not all HTTPS APIs that are called RESTful (or = even worse "REST API"s) actually follow the REST model - i.e., folks are = using it as a generic term for any API using HTTPS.=20 >=20 > Regards, > Mary.=20 >=20 > On Mon, Jul 13, 2020 at 8:36 PM Mark Nottingham > wrote: > I've been chatting with folks in the background for a while about = starting a WG to take on specs to help folks building HTTP APIs.[1] >=20 > HTTP has been used for machine-to-machine communication for most of = its lifetime, there are a number of functions that are designed and = implemented in an ad hoc fashion, or with several competing approaches. = Establishing a WG to standardise some common functions might help, both = by documenting some common building blocks, and serving as a locus for a = new community -- one that's related to but distinct from the HTTP WG. >=20 > For example, these specifications were either AD-sponsored or on the = Independent stream, but could have been in-scope for such a WG: > - rfc6570 URI Template > - rfc6892 The 'describes' Link Relation Type > - rfc6901 JSON Pointer > - rfc6902 JSON Patch > - rfc7807 Problem Details for HTTP APIs > - rfc8288 Web Linking > - rfc8594 The Sunset HTTP Header Field > - rfc8631 Link Relation Types for Web Services >=20 > .... and there are also a number of current drafts that such a WG = might consider, e.g.: > - draft-wilde-linkset > - draft-nottingham-link-hint > - draft-dalal-deprecation-header > - draft-polli-ratelimit-headers >=20 > This is the proposed charter: > ~~~ > HTTP APIs Working Group (HTTPAPI) >=20 > HTTP is often for not only Web browsing, but also machine-to-machine = communication, often called '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. >=20 > Its output can include: > =E2=80=A2 Specifications for new HTTP header and/or trailer = fields > =E2=80=A2 Specifications for new message body formats, or = conventions for use in them (e.g., patterns of JSON objects) > =E2=80=A2 Proposals for new HTTP status codes, methods, or = other generic extensions, to be considered by the HTTP Working Group > =E2=80=A2 Best practices and other documentation for HTTP API = designers, consumers, implementers, operators, etc. >=20 > Other items are out of scope. In particular, this WG will not take on = work items for APIs for specific use cases, and it will not define new = HTTP extension points, or new extensions that are likely to be used by = Web browsers. >=20 > New work items can be added after a Call for Adoption on the working = group mailing list and consultation with the Area Director. >=20 > 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. >=20 > This Working Group will need to coordinate closely with the HTTP = Working Group. > ~~~ >=20 > Because a large part of the task here is building a representative = community, I think this group should be chartered without specific = documents; it can deliberate on what's appropriate to start with once = constituted. It should also be periodically evaluated to make sure that = it's functioning well and representative of the greater community, with = the assumption that if it isn't, it would be closed (I'd hope that ADs = do that for every WG anyway, but since this is trying to establish a new = venue, it should be considered on probation). >=20 > The ADs have responded positively, and asked me to bring this to = DISPATCH for wider review. I'm happy to talk about it in the meeting if = there's time. >=20 > Cheers, >=20 >=20 > 1. a.k.a. "RESTful APIs", although that's a misunderstanding of what = REST is. >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch = > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail=_C8B9BE24-EC0D-4001-A9C3-E2FE93916FD1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Don=E2=80=99t get me started on what is and isn=E2=80=99t = RESTful.  There is NO definition, no generally accepted standard, = and not even commonly agreed principals.  It=E2=80=99s a wild, Wild = West and anyone that claims to know what is and isn=E2=80=99t RESTful = is, IMHO, mistaken.  Fortunately, we don=E2=80=99t need to have = such a definition to do all these good things.

In fact, it's good that the charter = avoids saying REST.  I=E2=80=99d like to keep it that = way.

One = question about the charter:  We=E2=80=99re going to see an = increasing incidence of defining protocols using json and HTTP in our = work.  It would be good if the IETF had some common way these = interfaces were defined: not just the schemas but the operations. =  This is the domain of OpenAPI, for example, which could be a = candidate for what I=E2=80=99m asking about.  Is that something = that would be a chartered item?  I=E2=80=99d be willing to work on = that.  Not proscriptive, just advisory =E2=80=94 there are going to = be plenty of interfaces that wouldn=E2=80=99t fit, but things that use = an HTTP verb, take some parameters in, possibly including json objects, = and return some json response could benefit from some common defined way = to describe them.

Brian

On Jul 14, 2020, at 1:41 PM, = Mary Barnes <mary.ietf.barnes@gmail.com> wrote:

I think it's a great idea and yes on [1] - the vast majority = don't understand REST.    And, not all HTTPS APIs that are = called RESTful (or even worse "REST API"s) actually follow the REST = model - i.e., folks are using it as a generic term for any API using = HTTPS. 

Regards,
Mary. 

On Mon, Jul 13, 2020 at 8:36 PM Mark Nottingham = <mnot@mnot.net> = wrote:
I've been chatting with folks in the = background for a while about starting a WG to take on specs to help = folks building HTTP APIs.[1]

HTTP has been used for machine-to-machine communication for most of its = lifetime, there are a number of functions that are designed and = implemented in an ad hoc fashion, or with several competing approaches. = Establishing a WG to standardise some common functions might help, both = by documenting some common building blocks, and serving as a locus for a = new community -- one that's related to but distinct from the HTTP WG.

For example, these specifications were either AD-sponsored or on the = Independent stream, but could have been in-scope for such a WG:
 - rfc6570 URI Template
 - rfc6892 The 'describes' Link Relation Type
 - rfc6901 JSON Pointer
 - rfc6902 JSON Patch
 - rfc7807 Problem Details for HTTP APIs
 - rfc8288 Web Linking
 - rfc8594 The Sunset HTTP Header Field
 - rfc8631 Link Relation Types for Web Services

.... and there are also a number of current drafts that such a WG might = consider, e.g.:
 - draft-wilde-linkset
 - draft-nottingham-link-hint
 - draft-dalal-deprecation-header
 - draft-polli-ratelimit-headers

This is the proposed charter:
~~~
HTTP APIs Working Group (HTTPAPI)

HTTP is often for not only Web browsing, but also machine-to-machine = communication, often called '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:
        =E2=80=A2 Specifications for new HTTP header = and/or trailer fields
        =E2=80=A2 Specifications for new message = body formats, or conventions for use in them (e.g., patterns of JSON = objects)
        =E2=80=A2 Proposals for new HTTP status = codes, methods, or other generic extensions, to be considered by the = HTTP Working Group
        =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 = work items for APIs for specific use cases, and it will not define new = HTTP extension points, or new extensions that are likely to be used by = Web browsers.

New work items can be added after a Call for Adoption on the working = group mailing list and consultation with the Area Director.
=
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.

This Working Group will need to coordinate closely with the HTTP Working = Group.
~~~

Because a large part of the task here is building a representative = community, I think this group should be chartered without specific = documents; it can deliberate on what's appropriate to start with once = constituted. It should also be periodically evaluated to make sure that = it's functioning well and representative of the greater community, with = the assumption that if it isn't, it would be closed (I'd hope that ADs = do that for every WG anyway, but since this is trying to establish a new = venue, it should be considered on probation).

The ADs have responded positively, and asked me to bring this to = DISPATCH for wider review. I'm happy to talk about it in the meeting if = there's time.

Cheers,


1. a.k.a. "RESTful APIs", although that's a misunderstanding of what = REST is.

--
Mark Nottingham   https://www.mnot.net/

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch = mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

= --Apple-Mail=_C8B9BE24-EC0D-4001-A9C3-E2FE93916FD1-- From nobody Tue Jul 14 13:32:19 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED1573A0B2A for ; Tue, 14 Jul 2020 13:32:17 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 8uEAqqTEvF7r for ; Tue, 14 Jul 2020 13:32:15 -0700 (PDT) Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (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 8308C3A082B for ; Tue, 14 Jul 2020 13:32:15 -0700 (PDT) Received: by mail-pj1-x1034.google.com with SMTP id t15so2128398pjq.5 for ; Tue, 14 Jul 2020 13:32:15 -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=Ieb/kohMwIKL7kkQOGYUHCBhG10x/ptUreZBZY0TkLc=; b=X/cGaJYf1tAYXWnnpsmD+g2fMz1ZgeCnitBl4a6l79IT8r/oeDU6QJfRvDHdS9vz+D fWIW/LEdhvrIePNEQkJBZWl29EZnoJgytEGgLfO5bas+gAq+NBZHU0J1DSCT3Cw4hLEa xJbSMg2RZG4LhOP/6tI6C7ZuAKU41P/qfwB4ouwaNki8/QT0hVOrjQL5bJBVgipae2hT fJ/nqz8VtLkT2Afr1DMw2sS4SAGjLS2F781+ne0ymU0YI6v5ABL1rIXcFM+bzLBzA/iW JkZSZKMd7m07fqRQbxIGixuoBudd9NYFtUAt2VHylVMcJqso8ZsMkjMuSSJDLw63H0wF SPdw== 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=Ieb/kohMwIKL7kkQOGYUHCBhG10x/ptUreZBZY0TkLc=; b=US45WBoftmupnkDWvwNhbNWIx8AYCHT3pk8fMEngqJRUx4U5elz91IxexBuIEl3I4D XPv0pn0v2V92XzfQn5B7LFHjIb2xCHcAHylZVst6zlfbFFuSx0crq07HaKFu46tC9rSf LIaNVbsIMOoG2XrrKDgf4nQokYlDm5BLsOr7smyhnl+wacmphsE6nrdtFdeLZd3eF8Bo IryKoPoS4pNJmd0nzrOwA5AGCljMnbGd0yAO4Dxfr28b5i8noNiyfGb+tBybij3JrhPz y/wUOBPYpc5kiIacHyYSRPbLwteQ2M6gMArFApmPS3yfEm3RqOpkQWh//5AOOgw5kxg4 ZgZA== X-Gm-Message-State: AOAM533HM8IN0NKwNhEudqPXlmRREEMmslD2DRtlx5W/djwZZJzJieS/ r9Q1ko5F8UXZuVZUkmDotWl1HKgaTZSaMOkz6xXryg== X-Google-Smtp-Source: ABdhPJyk1bAj99TaBrlYg6xj+N35nv3JdFn6ETUUPn3B9vqm/u0xVcftzGtiGfUbTqF7fRO9pcUrq5W9Tn1OuX8ByQU= X-Received: by 2002:a17:902:103:: with SMTP id 3mr5437447plb.195.1594758734850; Tue, 14 Jul 2020 13:32:14 -0700 (PDT) MIME-Version: 1.0 References: <111A89F4-CBD6-4C63-A45A-C7458E7413FF@mnot.net> <7414026C-4726-4C8E-8C9C-60A81F5456B5@brianrosen.net> In-Reply-To: <7414026C-4726-4C8E-8C9C-60A81F5456B5@brianrosen.net> From: Mary Barnes Date: Tue, 14 Jul 2020 15:32:03 -0500 Message-ID: To: Brian Rosen Cc: Mark Nottingham , DISPATCH WG Content-Type: multipart/alternative; boundary="000000000000e4aee705aa6cb3e2" Archived-At: Subject: Re: [dispatch] A WG for HTTP API Building Blocks X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2020 20:32:18 -0000 --000000000000e4aee705aa6cb3e2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I would be very, very happy to avoid the term REST altogether as well. And, I'll be very happy if this work moves forward and I can point folks to this when they try to tell me they're developing or have defined a REST/ful API. On Tue, Jul 14, 2020 at 2:59 PM Brian Rosen wrote: > Don=E2=80=99t get me started on what is and isn=E2=80=99t RESTful. There= is NO > definition, no generally accepted standard, and not even commonly agreed > principals. It=E2=80=99s a wild, Wild West and anyone that claims to kno= w what is > and isn=E2=80=99t RESTful is, IMHO, mistaken. Fortunately, we don=E2=80= =99t need to have > such a definition to do all these good things. > > In fact, it's good that the charter avoids saying REST. I=E2=80=99d like= to keep > it that way. > > One question about the charter: We=E2=80=99re going to see an increasing > incidence of defining protocols using json and HTTP in our work. It woul= d > be good if the IETF had some common way these interfaces were defined: no= t > just the schemas but the operations. This is the domain of OpenAPI, for > example, which could be a candidate for what I=E2=80=99m asking about. I= s that > something that would be a chartered item? I=E2=80=99d be willing to work= on that. > Not proscriptive, just advisory =E2=80=94 there are going to be plenty of > interfaces that wouldn=E2=80=99t fit, but things that use an HTTP verb, t= ake some > parameters in, possibly including json objects, and return some json > response could benefit from some common defined way to describe them. > > Brian > > On Jul 14, 2020, at 1:41 PM, Mary Barnes > wrote: > > I think it's a great idea and yes on [1] - the vast majority don't > understand REST. And, not all HTTPS APIs that are called RESTful (or > even worse "REST API"s) actually follow the REST model - i.e., folks are > using it as a generic term for any API using HTTPS. > > Regards, > Mary. > > On Mon, Jul 13, 2020 at 8:36 PM Mark Nottingham wrote: > >> I've been chatting with folks in the background for a while about >> starting a WG to take on specs to help folks building HTTP APIs.[1] >> >> HTTP has been used for machine-to-machine communication for most of its >> lifetime, there are a number of functions that are designed and implemen= ted >> in an ad hoc fashion, or with several competing approaches. Establishing= a >> WG to standardise some common functions might help, both by documenting >> some common building blocks, and serving as a locus for a new community = -- >> one that's related to but distinct from the HTTP WG. >> >> For example, these specifications were either AD-sponsored or on the >> Independent stream, but could have been in-scope for such a WG: >> - rfc6570 URI Template >> - rfc6892 The 'describes' Link Relation Type >> - rfc6901 JSON Pointer >> - rfc6902 JSON Patch >> - rfc7807 Problem Details for HTTP APIs >> - rfc8288 Web Linking >> - rfc8594 The Sunset HTTP Header Field >> - rfc8631 Link Relation Types for Web Services >> >> .... and there are also a number of current drafts that such a WG might >> consider, e.g.: >> - draft-wilde-linkset >> - draft-nottingham-link-hint >> - draft-dalal-deprecation-header >> - draft-polli-ratelimit-headers >> >> This is the proposed charter: >> ~~~ >> HTTP APIs Working Group (HTTPAPI) >> >> HTTP is often for not only Web browsing, but also machine-to-machine >> communication, often called '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: >> =E2=80=A2 Specifications for new HTTP header and/or trailer fiel= ds >> =E2=80=A2 Specifications for new message body formats, or conven= tions for >> use in them (e.g., patterns of JSON objects) >> =E2=80=A2 Proposals for new HTTP status codes, methods, or other= generic >> extensions, to be considered by the HTTP Working Group >> =E2=80=A2 Best practices and other documentation for HTTP API de= signers, >> consumers, implementers, operators, etc. >> >> Other items are out of scope. In particular, this WG will not take on >> work items for APIs for specific use cases, and it will not define new H= TTP >> extension points, or new extensions that are likely to be used by Web >> browsers. >> >> New work items can be added after a Call for Adoption on the working >> group mailing list and consultation with the Area Director. >> >> To be successful, this Working Group will need to have active and broad >> representation from across the industry -- e.g., API gateway vendors (an= d >> 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. >> >> This Working Group will need to coordinate closely with the HTTP Working >> Group. >> ~~~ >> >> Because a large part of the task here is building a representative >> community, I think this group should be chartered without specific >> documents; it can deliberate on what's appropriate to start with once >> constituted. It should also be periodically evaluated to make sure that >> it's functioning well and representative of the greater community, with = the >> assumption that if it isn't, it would be closed (I'd hope that ADs do th= at >> for every WG anyway, but since this is trying to establish a new venue, = it >> should be considered on probation). >> >> The ADs have responded positively, and asked me to bring this to DISPATC= H >> for wider review. I'm happy to talk about it in the meeting if there's t= ime. >> >> Cheers, >> >> >> 1. a.k.a. "RESTful APIs", although that's a misunderstanding of what RES= T >> is. >> >> -- >> Mark Nottingham https://www.mnot.net/ >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > --000000000000e4aee705aa6cb3e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would be very, very happy to avoid the term REST altoget= her as well.=C2=A0 =C2=A0And, I'll be very happy if this work moves for= ward and I can point folks to this when they try to tell me they're dev= eloping or have defined a REST/ful API.=C2=A0

On Tue, Jul 14, 2020 at 2:59 P= M Brian Rosen <br@brianrosen.net> wrote:
Don=E2=80=99t get me started on what= is and isn=E2=80=99t RESTful.=C2=A0 There is NO definition, no generally a= ccepted standard, and not even commonly agreed principals.=C2=A0 It=E2=80= =99s a wild, Wild West and anyone that claims to know what is and isn=E2=80= =99t RESTful is, IMHO, mistaken.=C2=A0 Fortunately, we don=E2=80=99t need t= o have such a definition to do all these good things.

In= fact, it's good that the charter avoids saying REST.=C2=A0 I=E2=80=99d= like to keep it that way.

One question about the = charter: =C2=A0We=E2=80=99re going to see an increasing incidence of defini= ng protocols using json and HTTP in our work.=C2=A0 It would be good if the= IETF had some common way these interfaces were defined: not just the schem= as but the operations.=C2=A0 This is the domain of OpenAPI, for example, wh= ich could be a candidate for what I=E2=80=99m asking about.=C2=A0 Is that s= omething that would be a chartered item?=C2=A0 I=E2=80=99d be willing to wo= rk on that.=C2=A0 Not proscriptive, just advisory =E2=80=94 there are going= to be plenty of interfaces that wouldn=E2=80=99t fit, but things that use = an HTTP verb, take some parameters in, possibly including json objects, and= return some json response could benefit from some common defined way to de= scribe them.

Brian


I think it's a great idea a= nd yes on [1] - the vast majority don't understand REST.=C2=A0 =C2=A0 A= nd, not all HTTPS APIs that are called RESTful (or even worse "REST AP= I"s) actually follow the REST model - i.e., folks are using it as a ge= neric term for any API using HTTPS.=C2=A0

Regards,
=
Mary.=C2=A0

I've bee= n chatting with folks in the background for a while about starting a WG to = take on specs to help folks building HTTP APIs.[1]

HTTP has been used for machine-to-machine communication for most of its lif= etime, there are a number of functions that are designed and implemented in= an ad hoc fashion, or with several competing approaches. Establishing a WG= to standardise some common functions might help, both by documenting some = common building blocks, and serving as a locus for a new community -- one t= hat's related to but distinct from the HTTP WG.

For example, these specifications were either AD-sponsored or on the Indepe= ndent stream, but could have been in-scope for such a WG:
=C2=A0- rfc6570 URI Template
=C2=A0- rfc6892 The 'describes' Link Relation Type
=C2=A0- rfc6901 JSON Pointer
=C2=A0- rfc6902 JSON Patch
=C2=A0- rfc7807 Problem Details for HTTP APIs
=C2=A0- rfc8288 Web Linking
=C2=A0- rfc8594 The Sunset HTTP Header Field
=C2=A0- rfc8631 Link Relation Types for Web Services

.... and there are also a number of current drafts that such a WG might con= sider, e.g.:
=C2=A0- draft-wilde-linkset
=C2=A0- draft-nottingham-link-hint
=C2=A0- draft-dalal-deprecation-header
=C2=A0- draft-polli-ratelimit-headers

This is the proposed charter:
~~~
HTTP APIs Working Group (HTTPAPI)

HTTP is often for not only Web browsing, but also machine-to-machine commun= ication, often called 'HTTP APIs'. This Working Group will standard= ise HTTP protocol extensions for use in such cases, with a focus on buildin= g blocks for separate or combined use.

Its output can include:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 Specifications for new HTTP header an= d/or trailer fields
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 Specifications for new message body f= ormats, or conventions for use in them (e.g., patterns of JSON objects)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 Proposals for new HTTP status codes, = methods, or other generic extensions, to be considered by the HTTP Working = Group
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 Best practices and other documentatio= n 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 APIs for specific use cases, and it will not define new HTTP exte= nsion points, or new extensions that are likely to be used by Web browsers.=

New work items can be added after a Call for Adoption on the working group = mailing list and consultation with the Area Director.

To be successful, this Working Group will need to have active and broad rep= resentation from across the industry -- e.g., API gateway vendors (and othe= r intermediaries), API consultants, API tool vendors, in-house API teams. T= herefore, adopted proposals should have public support from multiple implem= enters and/or deployments before being sent to the IESG.

This Working Group will need to coordinate closely with the HTTP Working Gr= oup.
~~~

Because a large part of the task here is building a representative communit= y, I think this group should be chartered without specific documents; it ca= n deliberate on what's appropriate to start with once constituted. It s= hould also be periodically evaluated to make sure that it's functioning= well and representative of the greater community, with the assumption that= if it isn't, it would be closed (I'd hope that ADs do that for eve= ry WG anyway, but since this is trying to establish a new venue, it should = be considered on probation).

The ADs have responded positively, and asked me to bring this to DISPATCH f= or wider review. I'm happy to talk about it in the meeting if there'= ;s time.

Cheers,


1. a.k.a. "RESTful APIs", although that's a misunderstanding = of what REST is.

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing listdispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--000000000000e4aee705aa6cb3e2-- From nobody Tue Jul 14 16:25:53 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDA53A078E for ; Tue, 14 Jul 2020 16:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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=mnot.net header.b=Bh6bOUKs; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=YE8JK8an 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 qTnDuzXrmjNb for ; Tue, 14 Jul 2020 16:25:49 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 505913A0C20 for ; Tue, 14 Jul 2020 16:25:15 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id AAEBD5C0113; Tue, 14 Jul 2020 19:25:14 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 14 Jul 2020 19:25:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=k zZRygR2/qF1zqJy3JSrwVFyclCQEG/TgEjjjXRs7n0=; b=Bh6bOUKsFrTScC7n8 F5rMBE13ZbqtXs+fGUxsnEyZYaXWIlJbONVg3QDnQPEMzy0Gq/jrN1hjFPxvAPzs leb6nzmn1vd2VhxvYKuUh78QicRn+u8zjMLGrrWDwROiAnnpL7ND1XHP+qYb59LF M9uNAe+fKPzE8TfYGQJA604k7SmCFGD2171hm88WT1avEHrk5wj/PvgifJVBnhLS FgqBDdm76eIREh1WgFKisjVcRQLZMvb7KZLRgRy8w2YMnv4HTONTy9JJEaXJsN/l AAEibZ6E7231eFr+cPnMwt3rsB/G0DWfWqE6b3M6P7g80oXQW2MiMyyvCRRYewhq 4pz4g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=fm3; bh=kzZRygR2/qF1zqJy3JSrwVFyclCQEG/TgEjjjXRs7 n0=; b=YE8JK8anT383tZGmiIV5wpgLq/WaMUNPFjXPJCjukdH1Na21lBxB0yPZE LJVuFscVDkK6CdJ4hVWHY/OCwBzXQ2/1uN6I2OtycCAA2xoeDn3UZRjX/70lPvlJ a/5ydxw3riHGzDXq7pMklOpWKjdSOfcdiM0GoMipz7WWhEhmhC87YW9C8xSYIuo5 hjDg7umzHXnpBmrRqL4mraBbZ+hF4cpNM6l3BtJKP9C59YltR6YJArVUUof4WCSq q+H++b2LNP6ALiOtcmHhcl4yuVRGKM9PV4WtnI7CqxnvmzpIvqymea9GoNuC63rj uyl+L7i7UoZHN7LXuplh4vqbQWZ4Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrfedugddvudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepkedvleehveeiudeihffhfefhvddtgeelhfevfefgjeduudevvdfftdfgudeufefh necuffhomhgrihhnpehhthhtphhinhhouhhrfihorhhkrdhithdpmhhnohhtrdhnvghtne cukfhppeduudelrddujedrudehkedrvdehudenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght X-ME-Proxy: Received: from marks-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 54A80328005E; Tue, 14 Jul 2020 19:25:12 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Mark Nottingham In-Reply-To: <7414026C-4726-4C8E-8C9C-60A81F5456B5@brianrosen.net> Date: Wed, 15 Jul 2020 09:25:08 +1000 Cc: Mary Barnes , DISPATCH WG Content-Transfer-Encoding: quoted-printable Message-Id: <506832AD-0C3C-43AA-B5A7-EB5E80A2A112@mnot.net> References: <111A89F4-CBD6-4C63-A45A-C7458E7413FF@mnot.net> <7414026C-4726-4C8E-8C9C-60A81F5456B5@brianrosen.net> To: Brian Rosen X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [dispatch] A WG for HTTP API Building Blocks X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2020 23:25:51 -0000 Hi Brian, > On 15 Jul 2020, at 5:59 am, Brian Rosen wrote: >=20 > One question about the charter: We=E2=80=99re going to see an = increasing incidence of defining protocols using json and HTTP in our = work. It would be good if the IETF had some common way these interfaces = were defined: not just the schemas but the operations. This is the = domain of OpenAPI, for example, which could be a candidate for what = I=E2=80=99m asking about. Is that something that would be a chartered = item? I=E2=80=99d be willing to work on that. Not proscriptive, just = advisory =E2=80=94 there are going to be plenty of interfaces that = wouldn=E2=80=99t fit, but things that use an HTTP verb, take some = parameters in, possibly including json objects, and return some json = response could benefit from some common defined way to describe them. My .02 - I think it might be eventually, but I'd like to see the WG = build some capacity and legitimacy first. I say that because there are = some issues (like interface description) that have multiple possible = solutions, and I don't think we should be in the business of 'picking = winners' unless we are able to demonstrate that we have engagement = broadly across the industry. Hence the focus on 'building blocks' rather = than complete solutions. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Tue Jul 14 17:33:04 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B89323A099C for ; Tue, 14 Jul 2020 17:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 880mwtT02pLK for ; Tue, 14 Jul 2020 17:33:01 -0700 (PDT) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 250C23A099A for ; Tue, 14 Jul 2020 17:33:01 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id q15so2299135wmj.2 for ; Tue, 14 Jul 2020 17:33:01 -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=/wUAVEktc2bD+L1ian2HxPkqTKFDYSe+NJTH7zP5Mx8=; b=Wjw6GsVrbbmlHgyCiPTGx06nmcaEi+rohYMEkcNVZDIAak+R6hA8mQSwFFQ3Q/W8be KKuAcHL3nxQd8szLtD9OosZFLxRbIvvQn1fy6s3tSeMsyb8D6Uw9HpMAflRLt7x5JyPa w4xv09yWzScZ1Gd4rRMQcy4mSnhQSvd0zwQPfK7i9i1zwG57G/CfRPmO/+DVyTzheoJx Zp6lMTOpBCivgvZbLKTgNFpEkFXx3mE3IcxzATqMF5ppJF4gqecYMHTnNxWIYq133hCc vLlWZu27tw8eIzlGBB+Vo60ffQqFss8sXGjVun8ERxgefPYXmP1tUtrAxQykQnY0NjfJ L69g== 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=/wUAVEktc2bD+L1ian2HxPkqTKFDYSe+NJTH7zP5Mx8=; b=Ui/PDL2cdv0MHj1cuSH0XHh2JV+fF0mQ/5PIFILRlkqkbOACpZ9YECu+e9aEP7l9yT Fq+fgh4aC23+yWfj0wkxPzj1y1pfiLWbMrvQz6hjkLprDJ2R/kXr/xaDgvMCtVA7rDbc opgeuJbteOo8R2QJ+o3cda7WIkMcMPWyOWX3oDRjYl/tmpFZSBgcdAlBWz+jsLjH+4zf jZZpTttejnGZEfvqKc8wMd7GQ0eCzR8qIVTXiZC109OGAqs9vZW4TSJNg3iW6dbPFdg+ g0HKg1Mv9tq/VXpraXgZVE1RXADir3kYBO7xZzLTVLugUsxCYGLCJZq9al/ZWDYJfJpP r3KQ== X-Gm-Message-State: AOAM532a4eW61hpkr4+h19yZuG99apBYE8NlI9IfSlN0UrIrbwaZ25lt EoWPjRkmxub5zKCd6ZvktvrXLCjA+fIuNexPfv1E5vwyP5A= X-Google-Smtp-Source: ABdhPJzlN4Bm1SXu5g+TcgyrKxD4DEJC71tt1jF8B9IoSBdXK+OXrec4KvfRu0WSkvQbFSWHxj4JHnFB9tyDIvLInKk= X-Received: by 2002:a1c:9914:: with SMTP id b20mr5841320wme.15.1594769801206; Tue, 14 Jul 2020 16:36:41 -0700 (PDT) MIME-Version: 1.0 References: <111A89F4-CBD6-4C63-A45A-C7458E7413FF@mnot.net> In-Reply-To: <111A89F4-CBD6-4C63-A45A-C7458E7413FF@mnot.net> From: Lucas Pardue Date: Wed, 15 Jul 2020 00:36:31 +0100 Message-ID: To: Mark Nottingham Cc: DISPATCH WG Content-Type: multipart/alternative; boundary="0000000000007fe0dd05aa6f47e2" Archived-At: Subject: Re: [dispatch] A WG for HTTP API Building Blocks X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 00:33:03 -0000 --0000000000007fe0dd05aa6f47e2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Mark, I think this is a good idea in general. On Tue, Jul 14, 2020 at 2:36 AM Mark Nottingham wrote: > This is the proposed charter: > ~~~ > HTTP APIs Working Group (HTTPAPI) > > HTTP is often for not only Web browsing, but also machine-to-machine > communication, often called '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: > =E2=80=A2 Specifications for new HTTP header and/or trailer field= s > =E2=80=A2 Specifications for new message body formats, or convent= ions for > use in them (e.g., patterns of JSON objects) > =E2=80=A2 Proposals for new HTTP status codes, methods, or other = generic > extensions, to be considered by the HTTP Working Group > =E2=80=A2 Best practices and other documentation for HTTP API des= igners, > consumers, implementers, operators, etc. > > Other items are out of scope. In particular, this WG will not take on wor= k > items for APIs for specific use cases, and it will not define new HTTP > extension points, or new extensions that are likely to be used by Web > browsers. > On a personal note, I struggle a bit to understand how some proposal "foo" would be demarcated as HTTP vs HTTP API. That is probably case in point for the need of a community that understands these things better than me. I suspect my problem is that the interpretation of browsing is a little open and the charter could benefit from being arbitrarily more explicit. For instance, one pattern that is emerging is building Internet applications around the Web Platform but otherwise not supporting the notion of "general purpose web browsing", examples I have in mind are Progressive Web Apps, applications built on top of Electron, or "TV apps" in media clients. Therefore, the statement "[will not define] new extensions that are likely to be used by Web browsers" seems to rule out technologies and that seems a bit unfair. Cheers, Lucas --0000000000007fe0dd05aa6f47e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Mark,

I= think this is a good idea in general.

On Tue, Jul 14, 2020 at 2:36 AM= Mark Nottingham <mno= t@mnot.net> wrote:
This is the proposed charter:
~~~
HTTP APIs Working Group (HTTPAPI)

HTTP is often for not only Web browsing, but also machine-to-machine commun= ication, often called 'HTTP APIs'. This Working Group will standard= ise HTTP protocol extensions for use in such cases, with a focus on buildin= g blocks for separate or combined use.

Its output can include:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 Specifications for new HTTP header an= d/or trailer fields
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 Specifications for new message body f= ormats, or conventions for use in them (e.g., patterns of JSON objects)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 Proposals for new HTTP status codes, = methods, or other generic extensions, to be considered by the HTTP Working = Group
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 Best practices and other documentatio= n 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 APIs for specific use cases, and it will not define new HTTP exte= nsion points, or new extensions that are likely to be used by Web browsers.=

On a personal note, I struggle a bit to understand how = some proposal "foo" would be demarcated as HTTP vs HTTP API. That= is probably case in point for the need of a community that understands the= se things better than me.
I suspect my problem is that the interpretation of browsing is a= little open and the charter could benefit from being arbitrarily more expl= icit. For instance, one pattern that is emerging is building Internet appli= cations around the Web Platform but otherwise not supporting the notion of = "general purpose web browsing", examples I have in mind are Progr= essive Web Apps, applications built on top of Electron, or "TV apps&qu= ot; in media clients. Therefore, the statement "[will not define] new = extensions that are likely to be used by Web browsers" seems to rule o= ut technologies and that seems a bit unfair.

Cheers= ,
Lucas
--0000000000007fe0dd05aa6f47e2-- From nobody Tue Jul 14 23:15:01 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62E163A093B for ; Tue, 14 Jul 2020 23:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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=mnot.net header.b=k2th/jtE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XBbzIrGq 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 LXUbtxvQZgiN for ; Tue, 14 Jul 2020 23:14:57 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8823A3A0936 for ; Tue, 14 Jul 2020 23:14:57 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 921F5AD8; Wed, 15 Jul 2020 02:14:56 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 15 Jul 2020 02:14:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=F rgdJCGB9djDXraUqY5D9n0nHI5BXcBHpNOFHrgIehs=; b=k2th/jtEbiHFZyrKY 8UkQ7EOj8nwX1LP3Elg35omWAN4Sfcei81KomI0wRlml8lHi4JLDDbTHltMMiAP4 YwlVPxTBiNYaSZZ6at/ip/X/oUjaB5+lV1/JDq1UiUBBf3ehvdLpFsi+bU1/i5oT mDcESnYeCWqdXcUIj8GH42zkvfmwYwcs3jwCkgnCDE1wZTL1PCa98IZ+hfzmTjNY P2BgYWzpeagn9tgXd2+Id7PONjxbuIGrdzhz6P9EP3XnIgDONUtUr+xM6VbIZ4GV KNb950C7KMJaTHTze/hdcaG4ioyEAmXDTomX8KUaX7puZ8dRAOZe1aXLyg+Vbl9P oyUxQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=fm3; bh=FrgdJCGB9djDXraUqY5D9n0nHI5BXcBHpNOFHrgIe hs=; b=XBbzIrGqvtqjWJet1x8IOhRZON+SYZrwgoEw3RU+tFS9nkNE907POvr3P HmrfUiysAtFhUZ7bsy/C6Yd1xTRNMxdcbxAURg8XY8y22DjwLHuXEwpz2zam1b/g qqZH1nmwUPM8w4ZGU8HdZvWnNpDYL5VFnEh9645z1geXijBPGUsP/6OBbwRXV0TY zBwCggukhB7GvQfADNveYdAYOpX+xT35LMYFgIKO4CUsscFFtrYVfc0XGNGdQxwv z/RbeCfpPbrM7Y4XFx1WDdn29bFtzX9vagWmgv2F1h2SPzbmhIafnl4jLM3K8znx eUx20MJa3bGGQn1TUkiOIyMyouLdQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrfedugddutdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeevffffhfduteevvefhueffieegtdeutdehffeltefffedttdeggeejheeiueet teenucffohhmrghinhepmhhnohhtrdhnvghtnecukfhppeduudelrddujedrudehkedrvd ehudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehm nhhothesmhhnohhtrdhnvght X-ME-Proxy: Received: from marks-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 6269E3280059; Wed, 15 Jul 2020 02:14:54 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Mark Nottingham In-Reply-To: Date: Wed, 15 Jul 2020 16:14:51 +1000 Cc: DISPATCH WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <111A89F4-CBD6-4C63-A45A-C7458E7413FF@mnot.net> To: Lucas Pardue X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [dispatch] A WG for HTTP API Building Blocks X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 06:14:59 -0000 Hi Lucas, > On 15 Jul 2020, at 9:36 am, Lucas Pardue = wrote: >=20 > On a personal note, I struggle a bit to understand how some proposal = "foo" would be demarcated as HTTP vs HTTP API. That is probably case in = point for the need of a community that understands these things better = than me.=20 There's definitely a grey area, and I suspect it will take communication = and negotiation -- which is often the case between WGs anyway (we've had = several of these kinds of interactions between HTTP and other groups = like QUIC, DISPATCH and SECDISPATCH). > I suspect my problem is that the interpretation of browsing is a = little open and the charter could benefit from being arbitrarily more = explicit. For instance, one pattern that is emerging is building = Internet applications around the Web Platform but otherwise not = supporting the notion of "general purpose web browsing", examples I have = in mind are Progressive Web Apps, applications built on top of Electron, = or "TV apps" in media clients. Therefore, the statement "[will not = define] new extensions that are likely to be used by Web browsers" seems = to rule out technologies and that seems a bit unfair. One differentiating factor is whether the new protocol element is likely = to be supported in the Web Platform itself (i.e., actually by the = browser), or by code that's running in the browser on behalf of the = origin. Would that help, if stated as general guidance (I don't think it = should be an inflexible rule)? Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Wed Jul 15 00:40:41 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E53823A08A6 for ; Wed, 15 Jul 2020 00:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEd0GbYXXz0h for ; Wed, 15 Jul 2020 00:40:40 -0700 (PDT) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 A9CD53A08A5 for ; Wed, 15 Jul 2020 00:40:39 -0700 (PDT) Received: by mail-wm1-x32f.google.com with SMTP id c80so4379552wme.0 for ; Wed, 15 Jul 2020 00:40:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=liHpaFPoJN5Y2pSnfZ3e/qnutuLJAMRHE7RUQQ1UedM=; b=dHEtXpLsoowfLTQvQ/w6Ep0u369asBZ7DmKBvTClU1vboh+tmU7pDwECm2FN+IYYY1 iVPQ0fakKglMwTAIhXnBmbFVKsJjVzKzq0uN7anaXLc5tWGbo1kbuTVXMwZLd4uRGqIb nRXm9kUcbf8Ht51nWa/kErKrNlfBH8igTN8F1qyU12vRgEQOPHmiibBXi/GEOloS5QPP i1NnE/uflzNgpdC+BsF3T9ekvGCqOkql/7LrDKnLuW9V6KS615xv71NrUXlbfytt5H3c cr3lBzdHNZ6rBXqSDuC+RchITJzpev3w/t1nEqr7eZfLezAF+wOy8+HKj0WIekGVI7IM Si0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=liHpaFPoJN5Y2pSnfZ3e/qnutuLJAMRHE7RUQQ1UedM=; b=eyvOLJAiXVjri6VetZvLpMqtDVl0WbtvcjcADwaoscvJF/+qDU2xJFgBL+n/Wn3MZv dDMve2gex52Enj9MYuATuZSfwldjqesSAvN7VGx7ZiCMJzKLBw5P1jIpTiE+oW/Nvsdj 25Uj/aDjHDD2ZLXoHukZVc+UZw8bcKYBFLTFwOuPs0qH2KF/xDFkYHYIPVw8uHVVwcym gS2/EB07idrLZtNQcbHAAZhoAJbfb0bZvTquBS4D+S2z2cfoJ3JUDtGU3M5Ff/w7hCQI /wk2vEjA1bqEdfq69DJGuvwzOP+vxRlq8rKuze3yNhs3xs48uGzJWKK0ST5muOb8KSZG w/+A== X-Gm-Message-State: AOAM531tMokAag6r+XIcukIGRJzfKz6d/HrMZGWFSQHUgh1nymWoPXhP i4vqBrTrlkVlp2mRzG5nAHE/QVA2nNk= X-Google-Smtp-Source: ABdhPJzIvEonNeWUJDGmGvXJPJEz7EfI13evTt+1/HAHWQVjnaL1kfH8+ilpEQqjflcqyT94rJMzXA== X-Received: by 2002:a05:600c:2285:: with SMTP id 5mr7670033wmf.78.1594798837831; Wed, 15 Jul 2020 00:40:37 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id p14sm2550357wrj.14.2020.07.15.00.40.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Jul 2020 00:40:36 -0700 (PDT) To: Mark Nottingham Cc: DISPATCH WG References: <111A89F4-CBD6-4C63-A45A-C7458E7413FF@mnot.net> <7414026C-4726-4C8E-8C9C-60A81F5456B5@brianrosen.net> <506832AD-0C3C-43AA-B5A7-EB5E80A2A112@mnot.net> From: Anders Rundgren Message-ID: <56558cd0-b1e1-9be1-a07e-c4d62c133de9@gmail.com> Date: Wed, 15 Jul 2020 09:40:34 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <506832AD-0C3C-43AA-B5A7-EB5E80A2A112@mnot.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dispatch] A WG for HTTP API Building Blocks X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 07:40:41 -0000 A long time source of frustration has been and still is the case of "Signed HTTP Requests". The limited progress in this space have forced other parties to step in, more recently including ETSI with Open Banking as initial target. FWIW, I'm personally working on such a scheme that facilitate serialization which in turn enables counter-signing. It is based on RFC 8785. thanx, Anders From nobody Wed Jul 15 02:40:27 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 015893A082F for ; Wed, 15 Jul 2020 02:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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=lowentropy.net header.b=BlnQJx0u; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RIh/Bzcf 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 fPiZBvMFauzA for ; Wed, 15 Jul 2020 02:40:25 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE0083A0101 for ; Wed, 15 Jul 2020 02:40:24 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 07B925C0172 for ; Wed, 15 Jul 2020 05:40:24 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Wed, 15 Jul 2020 05:40:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=DM5Su B9gcJhoiVD6RuDbD3rXa57jLEO2J3hxgWfmBec=; b=BlnQJx0u9MoV84Ih138h1 QmLomwyaKIokcB8bRcvANilqBXHIm/AgKywvr8y7XzqkmxiGbnDYbul9ssmyc8VQ 5Ww8ZLCixKMvA8YSA5QJXHXL3WbRhjeEAtJZrwC/3XAZJ+k9ZogFP8/b+uJQFFNl kajsaQN506lvN9AUs8U0Sg0xRLpy8gCDo8xWnPHcLUD6XyycDRQzI+N1S2zxCTtH xA2W9V+a0+hEDizItu37U2lEZZKqUUIFsfOJyYgYGgMdXJ+72dJYlEZ8Dd2koW/a tjrgzD95A1mCSqB6FxzI8B2fxfdO6dmF1nhP3yj3voV5jRgOZ08vrdguZCO6C35a Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding: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=fm3; bh=DM5SuB9gcJhoiVD6RuDbD3rXa57jLEO2J3hxgWfmB ec=; b=RIh/Bzcf2aCAunktx3vc/9ICfZ+RfeNy7B2N9F8gie4K/h4yDo9OzTLW0 RuTiLAHYJWt54kGPNtM/ttt/SFb6/nWlQYATrsQpFsGgX+z6+yU3L2/f/yqpoijv 7eD00fDDlt3mTAUewFu2X7fbEWTcbf4tMd+l/nbyivc9OadTyXwqUgW/W88Lu456 8v167+XNPXKmdy6SirKK40gJVCnhgFXjj2jdg30Uig0M3evYScC86+jClYUEifgb XVt2IlfCPkNMp6HPbnHDaktfl8wtDJgz/FX596M9RIrr08dRDb7SUBMT5x7di1Mi 5kcNy1m6UKYzK4iYZa/UmLn3VA9bg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrfedvgddvtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeekhefhjeevgfffkeelte elueegvefhvdfgjeekfeffkefgueehhefhfeefiedthfenucffohhmrghinhepjhhsohhn qdhstghhvghmrgdrohhrghdpihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B7C86E0117; Wed, 15 Jul 2020 05:40:23 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-613-g8a73ad6-fm-20200709.001-g8a73ad6e Mime-Version: 1.0 Message-Id: In-Reply-To: <77B617C1-2148-4AE6-8428-DAD43D01FBC5@tzi.org> References: <159467093010.19477.7181341398452455173@ietfa.amsl.com> <77B617C1-2148-4AE6-8428-DAD43D01FBC5@tzi.org> Date: Wed, 15 Jul 2020 19:40:03 +1000 From: "Martin Thomson" To: dispatch@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dispatch] draft-goessner-dispatch-jsonpath-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 09:40:27 -0000 I see three major differences here from JSON pointer: 1. this selects multiple values in the same way that XPath does, so this= includes // and * and other such things 2. predicates (the execution of script is a major concern and really beg= s for a security model), which is largely a consequence of having multip= le values but not strictly 3. syntax Of these, the syntax difference seems gratuitous. JSON pointer isn't ex= actly awesome~1but it has fewer variants and it isn't inclined toward im= plementation by eval(), which is an anti-feature. Personally, I would much rather see a new JSON pointer developed, which = would be evolutionary rather than revolutionary; more version 2 than com= petition. It would be relatively simple to add multi-value and relative= evaluation to JSON pointer if those are the key use cases. That said, = I don't have a lot of insight into what the implementation landscape is.= If JSON pointer is moribund, then we might want to acknowledge that. = My sense is that it has some relatively wide support, including modifica= tions for relative references (https://json-schema.org/draft/2019-09/rel= ative-json-pointer.html). Predicates are where this gets tricky, but I would suggest that you need= to decide the question of whether they are included from the outset. P= ersonally, these seem like they could be a big risk and I would defer th= eir addition if not cut them out, but I don't know what sort of use case= s are driving this. This seems big enough to be a working group (particularly if you put the= predicate stuff in scope). On Tue, Jul 14, 2020, at 15:14, Carsten Bormann wrote: > (Reply-To set to dispatch@ietf.org) >=20 > I would like to initiate discussion for draft-goessner-dispatch-jsonpa= th: >=20 > https://www.ietf.org/id/draft-goessner-dispatch-jsonpath-00.html >=20 > It says: >=20 > > This document picks up the popular JSONPath specification dated > > 2007-02-21 and provides a more normative definition for it. > > It is intended as a submission to the IETF DISPATCH WG, in order to > > find the right way to complete standardization of this specification= . > > In its current state, it is a strawman document showing what needs t= o > > be covered. >=20 > (For some reason the abstract landed in the Contributing note; typical= =20 > Internet-Draft deadline day botch.) >=20 > This is a widely implemented specification that has been around for=20= > more than a decade; now may be a good opportunity to finally go ahead=20= > and turn it into a proper Internet standards document. The immediate=20= > cause for writing this up now is that some IoT discovery work (some of= =20 > which happens in W3C) can make good use of JSONPath. Clearly, we=20 > already have JSON Pointer (RFC 6901) for a more limited set of=20 > applications; the specification would do good in defining how these tw= o=20 > fit together. >=20 > There is no active WG that immediately fits this work. >=20 > Eventually CDDL may pick JSONPath up in the form of a predicate=20 > operator; this might make the CBOR WG the right group (which probably=20= > would then go ahead and write up another specification that makes=20 > JSONPath useful for querying CBOR instances that go beyond the JSON=20= > generic data model). >=20 > Reopening the JSON WG may be another approach, as may be creating a=20= > short-lived targeted WG. >=20 > Please discuss! >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >=20 > > Begin forwarded message: > >=20 > > From: internet-drafts@ietf.org > > Subject: New Version Notification for draft-goessner-dispatch-jsonpa= th-00.txt > > Date: 2020-07-13 at 22:08:50 CEST > > To: "Stefan G=C3=B6ssner" , "Stefan = Gossner" , "Carsten Bormann" > >=20 > >=20 > > A new version of I-D, draft-goessner-dispatch-jsonpath-00.txt > > has been successfully submitted by Carsten Bormann and posted to the= > > IETF repository. > >=20 > > Name: draft-goessner-dispatch-jsonpath > > Revision: 00 > > Title: JSONPath -- XPath for JSON > > Document date: 2020-07-12 > > Group: Individual Submission > > Pages: 14 > > URL: https://www.ietf.org/internet-drafts/draft-goessner-= dispatch-jsonpath-00.txt > > Status: https://datatracker.ietf.org/doc/draft-goessner-disp= atch-jsonpath/ > > Htmlized: https://tools.ietf.org/html/draft-goessner-dispatch-= jsonpath-00 > > Htmlized: https://datatracker.ietf.org/doc/html/draft-goessner= -dispatch-jsonpath > >=20 > >=20 > > Abstract: > > insert abstract here > >=20 > >=20 > >=20 > >=20 > > Please note that it may take a couple of minutes from the time of su= bmission > > until the htmlized version and diff are available at tools.ietf.org.= > >=20 > > The IETF Secretariat > >=20 > >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Wed Jul 15 05:37:53 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD3C63A0779 for ; Wed, 15 Jul 2020 05:37:51 -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, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=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=brianrosen-net.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 dPI3wvzXFj0i for ; Wed, 15 Jul 2020 05:37:49 -0700 (PDT) Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 59C5A3A0778 for ; Wed, 15 Jul 2020 05:37:49 -0700 (PDT) Received: by mail-il1-x131.google.com with SMTP id t27so1785086ill.9 for ; Wed, 15 Jul 2020 05:37:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6e7BpCJeR8y4AzW4pxI3Bamq4vRsyvJmKuCrQMA5mtw=; b=nfeIInfovf0ZQXN5DK8XkbNNBqyN8TxzUGCvxEuRPS4Cl4sBKSpW+Miya+tUy/kRw3 Z8Kvv6bX8Z1UZrsOy1atQMkXwZrQ3qIEuTpq1ttfXY5mUyEqAQg9bNw87vaRsRtaA4zz Fosp2zHGFLFY0FytgZL+ftbQM0RUWMc0JkGdJG9RrK9O07Cb4lvAMEmsqELxwo1dJQCZ H4jHsAJ/NF6nVxx6/QfBRQlyq4Rx/2QCZuZILcMQhss9KQiG0Sz6E9DLBgdnsvinWcje lph+kucULRSkBIqq7vbl0afXHKPJTLgB7RQtkIOAUWF6CPISs94fA1WXHKA3bI2UgAkX xx0Q== 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=6e7BpCJeR8y4AzW4pxI3Bamq4vRsyvJmKuCrQMA5mtw=; b=si1wTwDu5N37yz/pnsT0xPYvN4ZbyRHmbzuJ3kmufQ+wSSsvoXfvmcDpT9KaAUti5A fniNXOz0ulW83idtgCQBKXO2ivRW89z6UHV8P4GxtMA49PHqz4ACynFzp2RFcCWHtNxK RJS0jMn1tIPX/uWgKuhKuHnXWJALs1Obsd0btHIb5sUxGnPDJo4VMMCiJzq3+ACjTPZI NeLUn/t+KvmIUr4+pbBkF9xkU0EaB81iiiQZcg7jCxcG918keqeifLyE/xZeaZQESc6N 0FW0cB7MS2Q+NAJRpPlhMiw63esEcpycpIClLmK7/vVCLYNjNxyWSnVWMqF19gFphvml d4HQ== X-Gm-Message-State: AOAM532HsfrV05aEvSvZ+mBeo7d0e5ZvRwJbHT0xr8T2XFKVuG9w540J 281fKFNXCgQXGOdSDzErrhd8y5iwfmE= X-Google-Smtp-Source: ABdhPJytf2/EQys64MMoypn1Xypwg036AJ3lFVLKDmBMoKxYRQYyAwU9EA6a1t7CtR4MWTkDR1LclQ== X-Received: by 2002:a92:aad6:: with SMTP id p83mr8958300ill.65.1594816668537; Wed, 15 Jul 2020 05:37:48 -0700 (PDT) Received: from brians-mbp-2871.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id 5sm1087569ion.7.2020.07.15.05.37.40 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Jul 2020 05:37:40 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Brian Rosen In-Reply-To: Date: Wed, 15 Jul 2020 08:37:39 -0400 Cc: dispatch@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1C9B201D-7DB6-4A8D-8750-475981DB5863@brianrosen.net> References: <159467093010.19477.7181341398452455173@ietfa.amsl.com> <77B617C1-2148-4AE6-8428-DAD43D01FBC5@tzi.org> To: Martin Thomson X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [dispatch] draft-goessner-dispatch-jsonpath-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 12:37:52 -0000 I haven=E2=80=99t seen json pointer in the wild, pretty much ever. = I=E2=80=99ve seen A LOT of jsonpath. =20 But I=E2=80=99m not exactly doing mainstream interfaces. Brian > On Jul 15, 2020, at 5:40 AM, Martin Thomson wrote: >=20 > I see three major differences here from JSON pointer: >=20 > 1. this selects multiple values in the same way that XPath does, so = this includes // and * and other such things > 2. predicates (the execution of script is a major concern and really = begs for a security model), which is largely a consequence of having = multiple values but not strictly > 3. syntax >=20 > Of these, the syntax difference seems gratuitous. JSON pointer isn't = exactly awesome~1but it has fewer variants and it isn't inclined toward = implementation by eval(), which is an anti-feature. >=20 > Personally, I would much rather see a new JSON pointer developed, = which would be evolutionary rather than revolutionary; more version 2 = than competition. It would be relatively simple to add multi-value and = relative evaluation to JSON pointer if those are the key use cases. = That said, I don't have a lot of insight into what the implementation = landscape is. If JSON pointer is moribund, then we might want to = acknowledge that. My sense is that it has some relatively wide support, = including modifications for relative references = (https://json-schema.org/draft/2019-09/relative-json-pointer.html). >=20 > Predicates are where this gets tricky, but I would suggest that you = need to decide the question of whether they are included from the = outset. Personally, these seem like they could be a big risk and I = would defer their addition if not cut them out, but I don't know what = sort of use cases are driving this. >=20 > This seems big enough to be a working group (particularly if you put = the predicate stuff in scope). >=20 >=20 > On Tue, Jul 14, 2020, at 15:14, Carsten Bormann wrote: >> (Reply-To set to dispatch@ietf.org) >>=20 >> I would like to initiate discussion for = draft-goessner-dispatch-jsonpath: >>=20 >> https://www.ietf.org/id/draft-goessner-dispatch-jsonpath-00.html >>=20 >> It says: >>=20 >>> This document picks up the popular JSONPath specification dated >>> 2007-02-21 and provides a more normative definition for it. >>> It is intended as a submission to the IETF DISPATCH WG, in order to >>> find the right way to complete standardization of this = specification. >>> In its current state, it is a strawman document showing what needs = to >>> be covered. >>=20 >> (For some reason the abstract landed in the Contributing note; = typical=20 >> Internet-Draft deadline day botch.) >>=20 >> This is a widely implemented specification that has been around for=20= >> more than a decade; now may be a good opportunity to finally go ahead=20= >> and turn it into a proper Internet standards document. The immediate=20= >> cause for writing this up now is that some IoT discovery work (some = of=20 >> which happens in W3C) can make good use of JSONPath. Clearly, we=20 >> already have JSON Pointer (RFC 6901) for a more limited set of=20 >> applications; the specification would do good in defining how these = two=20 >> fit together. >>=20 >> There is no active WG that immediately fits this work. >>=20 >> Eventually CDDL may pick JSONPath up in the form of a predicate=20 >> operator; this might make the CBOR WG the right group (which probably=20= >> would then go ahead and write up another specification that makes=20 >> JSONPath useful for querying CBOR instances that go beyond the JSON=20= >> generic data model). >>=20 >> Reopening the JSON WG may be another approach, as may be creating a=20= >> short-lived targeted WG. >>=20 >> Please discuss! >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >>=20 >>=20 >>> Begin forwarded message: >>>=20 >>> From: internet-drafts@ietf.org >>> Subject: New Version Notification for = draft-goessner-dispatch-jsonpath-00.txt >>> Date: 2020-07-13 at 22:08:50 CEST >>> To: "Stefan G=C3=B6ssner" , "Stefan = Gossner" , "Carsten Bormann" = >>>=20 >>>=20 >>> A new version of I-D, draft-goessner-dispatch-jsonpath-00.txt >>> has been successfully submitted by Carsten Bormann and posted to the >>> IETF repository. >>>=20 >>> Name: draft-goessner-dispatch-jsonpath >>> Revision: 00 >>> Title: JSONPath -- XPath for JSON >>> Document date: 2020-07-12 >>> Group: Individual Submission >>> Pages: 14 >>> URL: = https://www.ietf.org/internet-drafts/draft-goessner-dispatch-jsonpath-00.t= xt >>> Status: = https://datatracker.ietf.org/doc/draft-goessner-dispatch-jsonpath/ >>> Htmlized: = https://tools.ietf.org/html/draft-goessner-dispatch-jsonpath-00 >>> Htmlized: = https://datatracker.ietf.org/doc/html/draft-goessner-dispatch-jsonpath >>>=20 >>>=20 >>> Abstract: >>> insert abstract here >>>=20 >>>=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 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Wed Jul 15 06:32:55 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502EE3A087C for ; Wed, 15 Jul 2020 06:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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=mnot.net header.b=MlfHtDyM; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ikUGeNbK 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 hK1g6ppxAeOi for ; Wed, 15 Jul 2020 06:32:52 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B47C3A087B for ; Wed, 15 Jul 2020 06:32:52 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id B5CB25C0095; Wed, 15 Jul 2020 09:32:51 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 15 Jul 2020 09:32:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=V myv5B6Siao6g1XtpU/OiAUQ5Cw/8yeUPafGKmaW5BQ=; b=MlfHtDyMDwbgGe7qa hPlsu79bFmU1PC/qQiWtwCP7cV82j3G+st8OtSNKbGempVydlB+dqVzul4LFjAzF sxMoYy9elC2Ap5CDJPHjy8iPAuHhFaJMsokEe/eAJcz8264nD/zxJ54A1+Cz0DE3 Tp1eCYot5VV9YvdDsqTjtYtSNIkVW6gSeMo47kSQbuU5U0tTm4UPQol5uKhQR8qs 3Q3U58v6kIyzcMzaPj1wxnHOK3ggMF+1d1hPJGWgnaMYP5jFDbB1HZcUz0lCu1fu T/ZREmNlxtuso7pGCgitGVGqbSPnPIUrlp2hkDLBMarHCsfC3nZoKmXP8DitzYWM P0nBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=fm3; bh=Vmyv5B6Siao6g1XtpU/OiAUQ5Cw/8yeUPafGKmaW5 BQ=; b=ikUGeNbKBe5GWNDmTdW/kWJ7iJnkcjt7GqLvQLRBB5PJP4PwmNdrb0Sec v5+VuVVQp6gnW9Ax3IdBsT/sp5KpvdgyBnxZEze6btbXatrWcy5cjftOuzIdsYt2 kFQuR1ODNkz6m9gj58pIBJKtE0R5UdD5GfXwuVZUiAY+/L9/6l/AfQf/4+1QjbW7 +tYR6j9fGupuF5M82W8MhMXZ+fKJ0guCPIB+fE+dua9337akyaa6/0nGwUowck0d Bxb2IDwslUzMjfiKfNJ1DLX9MQoGPXnSEddBxfqVdzJjJ5Siy3qv9ztMeI4hmNaH L0cYlMwrNe0wVO0h16wIZZttBo8vw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrfedvgdejudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepkeduvdeljeegtefhveekhfdtveekleevkeefgeeludeihfdugedvieeuffdttdfh necuffhomhgrihhnpehivghtfhdrohhrghdpmhhnohhtrdhnvghtnecukfhppeduudelrd dujedrudehkedrvdehudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgr ihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght X-ME-Proxy: Received: from marks-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 907623280066; Wed, 15 Jul 2020 09:32:49 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Mark Nottingham In-Reply-To: <56558cd0-b1e1-9be1-a07e-c4d62c133de9@gmail.com> Date: Wed, 15 Jul 2020 23:32:45 +1000 Cc: DISPATCH WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <111A89F4-CBD6-4C63-A45A-C7458E7413FF@mnot.net> <7414026C-4726-4C8E-8C9C-60A81F5456B5@brianrosen.net> <506832AD-0C3C-43AA-B5A7-EB5E80A2A112@mnot.net> <56558cd0-b1e1-9be1-a07e-c4d62c133de9@gmail.com> To: Anders Rundgren X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [dispatch] A WG for HTTP API Building Blocks X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 13:32:54 -0000 FYI: https://tools.ietf.org/html/draft-ietf-httpbis-message-signatures-00 Cheers, > On 15 Jul 2020, at 5:40 pm, Anders Rundgren = wrote: >=20 > A long time source of frustration has been and still is the case of = "Signed HTTP Requests". > The limited progress in this space have forced other parties to step = in, more recently including ETSI with Open Banking as initial target. > FWIW, I'm personally working on such a scheme that facilitate = serialization which in turn enables counter-signing. It is based on RFC = 8785. >=20 > thanx, > Anders -- Mark Nottingham https://www.mnot.net/ From nobody Wed Jul 15 06:47:27 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC793A0AA2 for ; Wed, 15 Jul 2020 06:47:21 -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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-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 rGiTia3gQg0t for ; Wed, 15 Jul 2020 06:47:19 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 788883A099F for ; Wed, 15 Jul 2020 06:47:19 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id s10so2730687wrw.12 for ; Wed, 15 Jul 2020 06:47:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=vxXzFFnD6kJnymWc1zqOJw7V/h/3/jpeCO6azTCgKzc=; b=O/ZGTINSEPtdEDbzBCtRacM/h8YdA9r+OE9jjZY88VaAfF1Awgjm5rZKk2kxm+ucCH VMzC+iCYUMtZioS7mIoU8GY46FWgHZwsQFqZKbnYKWkUus7cwkKmPdA2Yd2WNsBQ59fQ TSZdqf91vzfM3cHVygqTxqPHecGBmV/9/Aee6XeaPGQh27SoxFjb36u9/K2HO+wYdQTG O0LEXXSRMNSAVThFJZpQS9/hUUOP3cFtvGIQIgimfjaVF/32biabwY9MPMgWt2fw1vTw pOo2geQmxOhbaw/YxM7KvKBvZneFsc6GRTn1/UpT4Rur1YmXiKEwzo4CNMfmK+aigXuw gBPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=vxXzFFnD6kJnymWc1zqOJw7V/h/3/jpeCO6azTCgKzc=; b=pM/UDLbma6smVU66spuAZoZbP1dbGCvcLPCi6sfN2/nzE0sp6JPWThMbMfvuVyKPOv lruREx4fIObUVFfulBEo7EwRg8KkhRT6R3teJFaUCcZJuO8QvqjbnLrpkbEefTHJ0cFZ MlLr/Z6FZKPX5+fLuW0y6qa3BE3ylQxoA37v8bPcoUeliRvOv/ftczEv9wG9C9IdOCjw qwMKShwChahUtcnHzj4XhRgsdoajJzB3TS8kgI+003nfZpdeMQr9LIM8S3U0WJ6AAMAX qrILRD1DbgXKGVrlJcBAzKZPczK/cwWGxHiy3gddUEgTWalorGvX96ly13GM3Xhs/nml /fTA== X-Gm-Message-State: AOAM5301/YUhYfrz+zd0T2osahfX5aRo9iMc8gsWCYznrOCGFnrhGOiz QBpD4Fw5YokW4fH0RQaC80CtGbucziU= X-Google-Smtp-Source: ABdhPJwSVB0dYUIdIYleMks2Zl17oyZzlIADEBbzllgJTXit3zw2Cmgqd3lw4pbASHioaGmv4DD9kw== X-Received: by 2002:adf:a3d0:: with SMTP id m16mr10930472wrb.232.1594820837618; Wed, 15 Jul 2020 06:47:17 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id j15sm3534635wrx.69.2020.07.15.06.47.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Jul 2020 06:47:16 -0700 (PDT) To: Mark Nottingham Cc: DISPATCH WG References: <111A89F4-CBD6-4C63-A45A-C7458E7413FF@mnot.net> <7414026C-4726-4C8E-8C9C-60A81F5456B5@brianrosen.net> <506832AD-0C3C-43AA-B5A7-EB5E80A2A112@mnot.net> <56558cd0-b1e1-9be1-a07e-c4d62c133de9@gmail.com> From: Anders Rundgren Message-ID: <7f79f4cf-dddc-48f5-355c-f4f1df157070@gmail.com> Date: Wed, 15 Jul 2020 15:47:15 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dispatch] A WG for HTTP API Building Blocks X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 13:47:26 -0000 On 2020-07-15 15:32, Mark Nottingham wrote: > FYI: > https://tools.ietf.org/html/draft-ietf-httpbis-message-signatures-00 Better late than never :) Anders > > Cheers, > > >> On 15 Jul 2020, at 5:40 pm, Anders Rundgren wrote: >> >> A long time source of frustration has been and still is the case of "Signed HTTP Requests". >> The limited progress in this space have forced other parties to step in, more recently including ETSI with Open Banking as initial target. >> FWIW, I'm personally working on such a scheme that facilitate serialization which in turn enables counter-signing. It is based on RFC 8785. >> >> thanx, >> Anders > > -- > Mark Nottingham https://www.mnot.net/ > From kevin@dunglas.fr Wed Jul 15 06:35:22 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37C23A088A for ; Wed, 15 Jul 2020 06:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 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_NONE=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=dunglas-fr.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 okzkGlD95xPi for ; Wed, 15 Jul 2020 06:35:19 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 823913A0888 for ; Wed, 15 Jul 2020 06:35:19 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id e64so2188881iof.12 for ; Wed, 15 Jul 2020 06:35:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dunglas-fr.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MUm7PB1iWyUOlop2AlYT9CyXVNRI3I6Ep75Vf1LA23E=; b=G03VgvRFAyGJjq+YJNIuzMfScETlTUAlmjZQECo40/3kHMiLbpqPZ4pGGK7XPN5Nm4 REIRnjjuLsDWmZWCCjKoVaThFjfhQFLPUBaOo+MW2DRt2rf20AbiP14Slz/EnJpHupp/ yyViROKpSC47RPZ9ufjqKT149ml7PotjX8K29OQ/XlJhbHTyul5QCEIquXiikodXlkof vkN4sXQmf/t206pZpAfWYUFInXgGLbjRH5lmfKiYdVZ7R2rqzPKJrTDrawndsKNZ3eT3 XCBN+Fs+cQqv4ebBTgfGSvSCF4IJ8S5ktf0YtiTC7BjE39NZRdsOV9Xbey6lCPwGc1hP GT9Q== 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=MUm7PB1iWyUOlop2AlYT9CyXVNRI3I6Ep75Vf1LA23E=; b=mvqRD5H95++49MMos/6b8ir/wWb81b5MygxOQ50e29VtQQ2PCl7he8ZWosnfjCwfKS rNYyuiAnNS5YNg2OZB1fGIlWCSyXUpeIjfcAyZPx23xp0eEoqL6y83wEgRScAhBC5kvf fP6W6YHHdQeT0wgvkR05aP3Vyg5rHqkkhyeiQH0M1NHr7WUALnMy65C5VaNKdPsNOmuT +fXJW3mCYlDdf1dw8PIAbrPFkOkY+u6s93DLP0FYjLxg9KqOcEaG4AWRCO3olUr8GPm1 NGu9er5LFkIq2rd31aUrCR0sN3R05EMPpEfGTYWOxW7dvIQ/xDvh0RAuWDuwl7gX1g/r gqUg== X-Gm-Message-State: AOAM531TJXXZ2El5yDMfFNipwEEB9keO8uGlB0rD23K3QydQaPMTHA7e rE2qb+JlsFEV/rMJ0XwMRglceF1/iMDSNl9/J9FojQ== X-Google-Smtp-Source: ABdhPJw3zhTK/gJdBCCQgykPWtp8ghRkFHLWFfQjwP4x3mM13P/f4masBWp4+GzX5eLddTx/bZHxIRZgVlgS+O0RY/Y= X-Received: by 2002:a6b:7210:: with SMTP id n16mr10170654ioc.177.1594820118604; Wed, 15 Jul 2020 06:35:18 -0700 (PDT) MIME-Version: 1.0 References: <159467093010.19477.7181341398452455173@ietfa.amsl.com> <77B617C1-2148-4AE6-8428-DAD43D01FBC5@tzi.org> <1C9B201D-7DB6-4A8D-8750-475981DB5863@brianrosen.net> In-Reply-To: <1C9B201D-7DB6-4A8D-8750-475981DB5863@brianrosen.net> From: =?UTF-8?Q?K=C3=A9vin_Dunglas?= Date: Wed, 15 Jul 2020 15:35:07 +0200 Message-ID: To: Brian Rosen Cc: Martin Thomson , dispatch@ietf.org Content-Type: multipart/alternative; boundary="000000000000a684aa05aa7afe46" Archived-At: Subject: Re: [dispatch] draft-goessner-dispatch-jsonpath-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 15:14:25 -0000 --000000000000a684aa05aa7afe46 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, In the Vulcain Internet-Draft we also have the need to select multiple values. To do so I proposed a very simple extension to JSON Pointer (by adding a new token: `*`): https://tools.ietf.org/html/draft-dunglas-vulcain-00#section-4.1 The Vulcain draft also allows the negotiation of the selector format to use. This feature has been added to support more document formats (such as XML using XPath), but also to allow the use of JSONPath which is indeed popular and more powerful. However we have voluntarily decided to not recommend JSONPath and to not implement it in the reference implementation because of the security considerations already pointed out by Martin and because it would allow (as GraphQL) a bad client to run easily very complex queries (which may be a DOS/DDOS attack vector). K=C3=A9vin, Le mer. 15 juil. 2020 =C3=A0 14:38, Brian Rosen a =C3= =A9crit : > I haven=E2=80=99t seen json pointer in the wild, pretty much ever. I=E2= =80=99ve seen A > LOT of jsonpath. > But I=E2=80=99m not exactly doing mainstream interfaces. > > Brian > > > On Jul 15, 2020, at 5:40 AM, Martin Thomson wrote: > > > > I see three major differences here from JSON pointer: > > > > 1. this selects multiple values in the same way that XPath does, so thi= s > includes // and * and other such things > > 2. predicates (the execution of script is a major concern and really > begs for a security model), which is largely a consequence of having > multiple values but not strictly > > 3. syntax > > > > Of these, the syntax difference seems gratuitous. JSON pointer isn't > exactly awesome~1but it has fewer variants and it isn't inclined toward > implementation by eval(), which is an anti-feature. > > > > Personally, I would much rather see a new JSON pointer developed, which > would be evolutionary rather than revolutionary; more version 2 than > competition. It would be relatively simple to add multi-value and relati= ve > evaluation to JSON pointer if those are the key use cases. That said, I > don't have a lot of insight into what the implementation landscape is. I= f > JSON pointer is moribund, then we might want to acknowledge that. My sen= se > is that it has some relatively wide support, including modifications for > relative references ( > https://json-schema.org/draft/2019-09/relative-json-pointer.html). > > > > Predicates are where this gets tricky, but I would suggest that you nee= d > to decide the question of whether they are included from the outset. > Personally, these seem like they could be a big risk and I would defer > their addition if not cut them out, but I don't know what sort of use cas= es > are driving this. > > > > This seems big enough to be a working group (particularly if you put th= e > predicate stuff in scope). > > > > > > On Tue, Jul 14, 2020, at 15:14, Carsten Bormann wrote: > >> (Reply-To set to dispatch@ietf.org) > >> > >> I would like to initiate discussion for > draft-goessner-dispatch-jsonpath: > >> > >> https://www.ietf.org/id/draft-goessner-dispatch-jsonpath-00.html > >> > >> It says: > >> > >>> This document picks up the popular JSONPath specification dated > >>> 2007-02-21 and provides a more normative definition for it. > >>> It is intended as a submission to the IETF DISPATCH WG, in order to > >>> find the right way to complete standardization of this specification. > >>> In its current state, it is a strawman document showing what needs to > >>> be covered. > >> > >> (For some reason the abstract landed in the Contributing note; typical > >> Internet-Draft deadline day botch.) > >> > >> This is a widely implemented specification that has been around for > >> more than a decade; now may be a good opportunity to finally go ahead > >> and turn it into a proper Internet standards document. The immediate > >> cause for writing this up now is that some IoT discovery work (some of > >> which happens in W3C) can make good use of JSONPath. Clearly, we > >> already have JSON Pointer (RFC 6901) for a more limited set of > >> applications; the specification would do good in defining how these tw= o > >> fit together. > >> > >> There is no active WG that immediately fits this work. > >> > >> Eventually CDDL may pick JSONPath up in the form of a predicate > >> operator; this might make the CBOR WG the right group (which probably > >> would then go ahead and write up another specification that makes > >> JSONPath useful for querying CBOR instances that go beyond the JSON > >> generic data model). > >> > >> Reopening the JSON WG may be another approach, as may be creating a > >> short-lived targeted WG. > >> > >> Please discuss! > >> > >> Gr=C3=BC=C3=9Fe, Carsten > >> > >> > >> > >>> Begin forwarded message: > >>> > >>> From: internet-drafts@ietf.org > >>> Subject: New Version Notification for > draft-goessner-dispatch-jsonpath-00.txt > >>> Date: 2020-07-13 at 22:08:50 CEST > >>> To: "Stefan G=C3=B6ssner" , "Stefan > Gossner" , "Carsten Bormann" > > >>> > >>> > >>> A new version of I-D, draft-goessner-dispatch-jsonpath-00.txt > >>> has been successfully submitted by Carsten Bormann and posted to the > >>> IETF repository. > >>> > >>> Name: draft-goessner-dispatch-jsonpath > >>> Revision: 00 > >>> Title: JSONPath -- XPath for JSON > >>> Document date: 2020-07-12 > >>> Group: Individual Submission > >>> Pages: 14 > >>> URL: > https://www.ietf.org/internet-drafts/draft-goessner-dispatch-jsonpath-00.= txt > >>> Status: > https://datatracker.ietf.org/doc/draft-goessner-dispatch-jsonpath/ > >>> Htmlized: > https://tools.ietf.org/html/draft-goessner-dispatch-jsonpath-00 > >>> Htmlized: > https://datatracker.ietf.org/doc/html/draft-goessner-dispatch-jsonpath > >>> > >>> > >>> Abstract: > >>> insert abstract here > >>> > >>> > >>> > >>> > >>> 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 > >>> > >>> > >> > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > >> > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --000000000000a684aa05aa7afe46 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

In the Vulcain Internet-= Draft we also have the need to select multiple values. To do so I proposed = a very simple extension to JSON Pointer (by adding a new token: `*`): htt= ps://tools.ietf.org/html/draft-dunglas-vulcain-00#section-4.1

The Vulcain draft also allows the negotiation of the select= or format to use. This feature has been added to support more document form= ats (such as XML using XPath), but also to allow the use of JSONPath which = is indeed popular and more powerful.
However we have voluntar= ily decided to not recommend JSONPath and to not implement it in the refere= nce implementation because of the security considerations already pointed o= ut by Martin and because it would allow (as GraphQL) a bad client to run ea= sily very complex queries (which may be a DOS/DDOS attack vector).

<= /div>
K=C3=A9vin,

Le=C2=A0mer. 15 juil. 2020 =C3=A0=C2=A014:38,= Brian Rosen <br@brianrosen.net= > a =C3=A9crit=C2=A0:
I haven= =E2=80=99t seen json pointer in the wild, pretty much ever.=C2=A0 I=E2=80= =99ve seen A LOT of jsonpath.=C2=A0
But I=E2=80=99m not exactly doing mainstream interfaces.

Brian

> On Jul 15, 2020, at 5:40 AM, Martin Thomson <mt@lowentropy.net> wrote:
>
> I see three major differences here from JSON pointer:
>
> 1. this selects multiple values in the same way that XPath does, so th= is includes // and * and other such things
> 2. predicates (the execution of script is a major concern and really b= egs for a security model), which is largely a consequence of having multipl= e values but not strictly
> 3. syntax
>
> Of these, the syntax difference seems gratuitous.=C2=A0 JSON pointer i= sn't exactly awesome~1but it has fewer variants and it isn't inclin= ed toward implementation by eval(), which is an anti-feature.
>
> Personally, I would much rather see a new JSON pointer developed, whic= h would be evolutionary rather than revolutionary; more version 2 than comp= etition.=C2=A0 It would be relatively simple to add multi-value and relativ= e evaluation to JSON pointer if those are the key use cases.=C2=A0 That sai= d, I don't have a lot of insight into what the implementation landscape= is.=C2=A0 If JSON pointer is moribund, then we might want to acknowledge t= hat.=C2=A0 My sense is that it has some relatively wide support, including = modifications for relative references (https://json-schema.org/draft/2019-09/relative-json-pointer.html). >
> Predicates are where this gets tricky, but I would suggest that you ne= ed to decide the question of whether they are included from the outset.=C2= =A0 Personally, these seem like they could be a big risk and I would defer = their addition if not cut them out, but I don't know what sort of use c= ases are driving this.
>
> This seems big enough to be a working group (particularly if you put t= he predicate stuff in scope).
>
>
> On Tue, Jul 14, 2020, at 15:14, Carsten Bormann wrote:
>> (Reply-To set to dispatch@ietf.org)
>>
>> I would like to initiate discussion for draft-goessner-dispatch-js= onpath:
>>
>> https://www.ietf.org/id/dra= ft-goessner-dispatch-jsonpath-00.html
>>
>> It says:
>>
>>> This document picks up the popular JSONPath specification date= d
>>> 2007-02-21 and provides a more normative definition for it. >>> It is intended as a submission to the IETF DISPATCH WG, in ord= er to
>>> find the right way to complete standardization of this specifi= cation.
>>> In its current state, it is a strawman document showing what n= eeds to
>>> be covered.
>>
>> (For some reason the abstract landed in the Contributing note; typ= ical
>> Internet-Draft deadline day botch.)
>>
>> This is a widely implemented specification that has been around fo= r
>> more than a decade; now may be a good opportunity to finally go ah= ead
>> and turn it into a proper Internet standards document.=C2=A0 The i= mmediate
>> cause for writing this up now is that some IoT discovery work (som= e of
>> which happens in W3C) can make good use of JSONPath.=C2=A0 Clearly= , we
>> already have JSON Pointer (RFC 6901) for a more limited set of >> applications; the specification would do good in defining how thes= e two
>> fit together.
>>
>> There is no active WG that immediately fits this work.
>>
>> Eventually CDDL may pick JSONPath up in the form of a predicate >> operator; this might make the CBOR WG the right group (which proba= bly
>> would then go ahead and write up another specification that makes =
>> JSONPath useful for querying CBOR instances that go beyond the JSO= N
>> generic data model).
>>
>> Reopening the JSON WG may be another approach, as may be creating = a
>> short-lived targeted WG.
>>
>> Please discuss!
>>
>> Gr=C3=BC=C3=9Fe, Carsten
>>
>>
>>
>>> Begin forwarded message:
>>>
>>> From: internet-drafts@ietf.org
>>> Subject: New Version Notification for draft-goessner-dispatch-= jsonpath-00.txt
>>> Date: 2020-07-13 at 22:08:50 CEST
>>> To: "Stefan G=C3=B6ssner" <stefan.goessner@fh-dortmund.d= e>, "Stefan Gossner" <stefan.goessner@fh-dortmund.de>, = "Carsten Bormann" <cabo@tzi.org>
>>>
>>>
>>> A new version of I-D, draft-goessner-dispatch-jsonpath-00.txt<= br> >>> has been successfully submitted by Carsten Bormann and posted = to the
>>> IETF repository.
>>>
>>> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dr= aft-goessner-dispatch-jsonpath
>>> Revision:=C2=A0 =C2=A000
>>> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 JSONPat= h -- XPath for JSON
>>> Document date:=C2=A0 =C2=A0 =C2=A0 2020-07-12
>>> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individ= ual Submission
>>> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 14
>>> URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/dra= ft-goessner-dispatch-jsonpath-00.txt
>>> Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-goessner-dispatc= h-jsonpath/
>>> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-goessner-dispatch-jsonpath-00=
>>> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-goessner-dis= patch-jsonpath
>>>
>>>
>>> Abstract:
>>>=C2=A0 insert abstract here
>>>
>>>
>>>
>>>
>>> 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
>>>
>>>
>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ie= tf.org
>> https://www.ietf.org/mailman/listinfo/dispatc= h
>>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/dispatch

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--000000000000a684aa05aa7afe46-- From nobody Wed Jul 15 11:56:44 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 759B13A0E87 for ; Wed, 15 Jul 2020 11:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 FLRhfFv3hicC for ; Wed, 15 Jul 2020 11:56:40 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ED2D3A0E79 for ; Wed, 15 Jul 2020 11:56:40 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4B6RSQ4z7ZzyVk; Wed, 15 Jul 2020 20:56:38 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Wed, 15 Jul 2020 20:56:38 +0200 Cc: Brian Rosen , Martin Thomson , dispatch@ietf.org X-Mao-Original-Outgoing-Id: 616532197.887617-cd2480fd3bea6634c01ce09dcead3894 Content-Transfer-Encoding: quoted-printable Message-Id: <8108D98C-7627-4A3E-A7A8-7183F8A1EA71@tzi.org> References: <159467093010.19477.7181341398452455173@ietfa.amsl.com> <77B617C1-2148-4AE6-8428-DAD43D01FBC5@tzi.org> <1C9B201D-7DB6-4A8D-8750-475981DB5863@brianrosen.net> To: =?utf-8?Q?K=C3=A9vin_Dunglas?= X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [dispatch] draft-goessner-dispatch-jsonpath-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 18:56:43 -0000 On 2020-07-15, at 15:35, K=C3=A9vin Dunglas wrote: >=20 > However we have voluntarily decided to not recommend JSONPath and to = not implement it in the reference implementation because of the security = considerations already pointed out by Martin and because it would allow = (as GraphQL) a bad client to run easily very complex queries (which may = be a DOS/DDOS attack vector). Security considerations are an important point in the definition of = JSONPath. Instead of other formats adopting varying subsets of JSONPath that they = happen to deem secure, I think it would be better to have a =E2=80=9Csecur= e=E2=80=9D profile of JSONPath. Note that this isn=E2=80=99t XPath (which is Turing equivalent=E2=80=A6). Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jul 15 13:19:17 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE63D3A0A83 for ; Wed, 15 Jul 2020 13:19:15 -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, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=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=brianrosen-net.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 v3re-i-XrFBl for ; Wed, 15 Jul 2020 13:19:14 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 3D05A3A0832 for ; Wed, 15 Jul 2020 13:19:14 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id y2so3661406ioy.3 for ; Wed, 15 Jul 2020 13:19:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+woUB781jWGEAPF784/sesTfuRGvIWl6c1k1R4vVJrg=; b=ea7b0JR0y0R5p6uxGIvK3xqadP0JkE6ErfflT85M7G/HsktF8vfJcDqu9595OJny3A o8c1NWFw4Da5Q2i46+HFw3belvS7l/eW42tH3bEBx5Gjo9MhA4sS1RGzZUk34FxIqGRP c8yrLaDCkF0Rtc9eRKctL5dHQcF39iFhkEEXvr/0qYT5uDpv2qNEeNbLGeWXdJa36kqt wO0HTbAfkA+Kgor/leoSx5ixyuFiKVmpksTF9D7Ey86102PAGmzlNMmcJyMTQtyuPxog 4ylquBsOhtklogN8iPHwf+zlqayNEzFHhKvFWfXb0Xx4MUokjZtLD+mpCZb6HTb3f8rm McwQ== 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=+woUB781jWGEAPF784/sesTfuRGvIWl6c1k1R4vVJrg=; b=lR0pkVM9zhwAh3OctLs5qtTZO1rlBDdBzNOHcAV1gemeKd0NXorqu+JYe3sAGIZGXp tHyWB6ni0R5tOUqZAhj3X7nFLplHodTgz9VnEfRV94dBI58oIgMZ2HeGJez2rLyl8xmz eYBtVTN4JMjuRvJ8KVOQskrfn9IaHGsI/dGzH/toXL7JqRM/apjvXjeSPNbGao9TqnuS gz4vdEOqiLLfOSnIuLgBxmW6SS5+YiOQV77CSpoBKSHQ5n7mxkzVaYkwXSqYveNcF/RF KN24Xv2uhvIcpbk7Vkv6BEe5XE7bm1yK305ogZs6cK00myY27EDP56NovNZnZuulOaIX E2mw== X-Gm-Message-State: AOAM533G/uWQYQLlyhtkilF/gTKG70ptqqD9QMXmnrtPFe4t3ifHveUU wr0pBTcYKmFSU32ZM4lcDox01A== X-Google-Smtp-Source: ABdhPJxD8lNocb8WQ0ZGiRDCfvjDTAKjT/NtB0L4k1asSkkpaHgl1sToOAGAW8JiCXHJpCeNLJIsgQ== X-Received: by 2002:a02:9642:: with SMTP id c60mr1200646jai.71.1594844353472; Wed, 15 Jul 2020 13:19:13 -0700 (PDT) Received: from brians-mbp-2871.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id s18sm1538069ilj.63.2020.07.15.13.19.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Jul 2020 13:19:12 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Brian Rosen In-Reply-To: <8108D98C-7627-4A3E-A7A8-7183F8A1EA71@tzi.org> Date: Wed, 15 Jul 2020 16:19:10 -0400 Cc: =?utf-8?Q?K=C3=A9vin_Dunglas?= , Martin Thomson , dispatch@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <77B387C5-1AF1-41A7-B3A7-870D4BC357A1@brianrosen.net> References: <159467093010.19477.7181341398452455173@ietfa.amsl.com> <77B617C1-2148-4AE6-8428-DAD43D01FBC5@tzi.org> <1C9B201D-7DB6-4A8D-8750-475981DB5863@brianrosen.net> <8108D98C-7627-4A3E-A7A8-7183F8A1EA71@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [dispatch] draft-goessner-dispatch-jsonpath-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 20:19:16 -0000 +1 > On Jul 15, 2020, at 2:56 PM, Carsten Bormann wrote: >=20 > On 2020-07-15, at 15:35, K=C3=A9vin Dunglas wrote: >>=20 >> However we have voluntarily decided to not recommend JSONPath and to = not implement it in the reference implementation because of the security = considerations already pointed out by Martin and because it would allow = (as GraphQL) a bad client to run easily very complex queries (which may = be a DOS/DDOS attack vector). >=20 > Security considerations are an important point in the definition of = JSONPath. > Instead of other formats adopting varying subsets of JSONPath that = they happen to deem secure, I think it would be better to have a = =E2=80=9Csecure=E2=80=9D profile of JSONPath. > Note that this isn=E2=80=99t XPath (which is Turing equivalent=E2=80=A6)= . >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 From nobody Wed Jul 15 14:09:41 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B891E3A0843; Wed, 15 Jul 2020 14:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.411 X-Spam-Level: X-Spam-Status: No, score=-0.411 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.267, MAY_BE_FORGED=1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 l6K1ZvT5krbM; Wed, 15 Jul 2020 14:09:37 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 1276B3A0832; Wed, 15 Jul 2020 14:09:37 -0700 (PDT) Received: from bens-macbook.lan (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 06FL9RNR042608 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 15 Jul 2020 16:09:28 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1594847369; bh=ziuW0Vf2Wd9Ai3uRV+sidglc4FvN5+Sb6cEPrshvsmc=; h=From:Subject:Date:Cc:To; b=hWrEeMILzCduNcKeHYMCLWkurGS/rj3H7QtVtL1UJj6PFG/IlSj2pIWbWzF1RZN+K 1+2W5lz+HB1U3n3YMJqAxKL0OJsqqQNneJB1JuI3xZigkKGyt27vJmwGxp9rOZZfqP T+ooCbK/7Uz/oAiB2xDvlkANZCAwDcOfGL9oEycc= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be bens-macbook.lan From: Ben Campbell Content-Type: multipart/alternative; boundary="Apple-Mail=_064B900F-4C12-4E67-88C0-C08781838A4D" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: <04FF34F7-0E17-43E6-9885-08959C0BE50A@nostrum.com> Date: Wed, 15 Jul 2020 16:09:22 -0500 Cc: Patrick McManus , ART ADs To: DISPATCH WG X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [dispatch] Agenda for DISPATCH at IETF108 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 21:09:40 -0000 --Apple-Mail=_064B900F-4C12-4E67-88C0-C08781838A4D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, A _draft_ agenda for the IETF108 DISPATCH meeting is available at = https://datatracker.ietf.org/meeting/108/materials/agenda-108-dispatch-01 = . (Copied below for your convenience.). Please send any bashes, = omissions, or other comments to the chairs and list as soon as possible. Thanks! Ben. =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 # DISPATCH Virtual Meeting @IETF-108=20 Monday, July 27, 2020 11:00-12:40 UTC [MeetEcho](http://www.meetecho.com/ietf108/dispatch/) [Notes](https://codimd.ietf.org/notes-ietf-108-dispatch) [Jabber](xmpp:dispatch@jabber.ietf.org?join) DISPATCH Meeting=20 ---------------- ### Status and Agenda Bash - Chairs and ADs (10 min) ### RFC 3405 Update - Ted Hardy(15 min) = [Draft](https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-upd= ate/) ### Proposed HTTP API Buiding Blocks WG - Mark Nottingham (20 min) [Proposed = Charter](https://mailarchive.ietf.org/arch/msg/dispatch/pWx1SgjZS4R3nzXEK-= jE6xqOqUc) ### JSON Path - Carsten Borman (20 min) Discussion: Should this be a candidate for the proposed HTTP API WG? = [Draft](https://datatracker.ietf.org/doc/draft-goessner-dispatch-jsonpath/= ) ### SFrame - TBD (20 min) [Draft](https://datatracker.ietf.org/doc/draft-omara-sframe/) ART AREA Meeting=20 ---------------- ### BoFs and meetings of interest - ADs (10 min) ### AOB --Apple-Mail=_064B900F-4C12-4E67-88C0-C08781838A4D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

A = _draft_ agenda for the IETF108 DISPATCH meeting is available at https://datatracker.ietf.org/meeting/108/materials/agenda-108-d= ispatch-01 . (Copied below for your convenience.). Please send = any bashes, omissions, or other comments to the chairs and list as soon = as possible.

Thanks!

Ben.

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94
# DISPATCH Virtual Meeting = @IETF-108 

Monday, July 27, 2020
11:00-12:40 = UTC




DISPATCH = Meeting 
----------------

### Status and Agenda = Bash - Chairs and ADs (10 min)

### RFC 3405 Update - Ted Hardy(15 = min)


###= Proposed HTTP API Buiding Blocks WG - Mark Nottingham (20 = min)


### JSON Path - Carsten Borman (20 min)

Discussion: Should this = be a candidate for the proposed HTTP API WG?


### = SFrame - TBD (20 min)

=


ART AREA Meeting 
----------------

### BoFs and meetings of interest - ADs (10 min)

### AOB

= --Apple-Mail=_064B900F-4C12-4E67-88C0-C08781838A4D-- From nobody Wed Jul 15 16:14:45 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 156F63A0976; Wed, 15 Jul 2020 16:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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 Xeh7i6KKEunQ; Wed, 15 Jul 2020 16:14:41 -0700 (PDT) Received: from mail-il1-f170.google.com (mail-il1-f170.google.com [209.85.166.170]) (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 E62013A0ACE; Wed, 15 Jul 2020 16:14:31 -0700 (PDT) Received: by mail-il1-f170.google.com with SMTP id k6so3486628ili.6; Wed, 15 Jul 2020 16:14:31 -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=Raxr6GridiXJc+v4UZsojY64GVN/k7x9vjIVG3lscak=; b=XF4bVGsF6v4jjXLv/N/4uwzP0Eo7HaDC8LQ9ADBSv6vq/c4tqtbMypfHmfuqOixq9H NRr3M78/FLIYhU1CbnzDwImRCh44fttUaQz/rEJu8AACBbJgKA4mOEQY1blEWK6S1TIM 9MMrgB4G9wvgmvfsiilFfr1w5j7+1Yx8hIygRaHK8cjmn7mofalNPlcn6duUjFQ6itKS JVxMeqDlMxEoSWvLmp0Ul3CS+vCoJrWu0MfYwm5QHuEbJpycaCw7+dNAn46408TqHUbe OEm3hh/a+HtKzu7qi20SN7mAEPj4VFlTzwDCHvDYjLkH+R97LbFi4utq+RqcfA36X6t3 g+HA== X-Gm-Message-State: AOAM532JtuLNfmCUThdTEb7+l2FqTDVvBltclNsfayl4WOtcKtjgU/6T N6OZYs54uk2KhICj89A9xS0QdNfA7UDMfq9X56JfCQ== X-Google-Smtp-Source: ABdhPJyyJmPccN02Eyyk9X8LWGNe+1vH2RH94xudxDanFRXMoBJa2bTxj+5MV4FV5aHJ0S1wz8qITVvz2aK5T8l/dU4= X-Received: by 2002:a92:4983:: with SMTP id k3mr1785465ilg.275.1594854871024; Wed, 15 Jul 2020 16:14:31 -0700 (PDT) MIME-Version: 1.0 References: <04FF34F7-0E17-43E6-9885-08959C0BE50A@nostrum.com> In-Reply-To: <04FF34F7-0E17-43E6-9885-08959C0BE50A@nostrum.com> From: Barry Leiba Date: Wed, 15 Jul 2020 19:14:20 -0400 Message-ID: To: Ben Campbell Cc: ART ADs , DISPATCH WG , Patrick McManus Content-Type: multipart/alternative; boundary="0000000000000e484605aa83160b" Archived-At: Subject: Re: [dispatch] Agenda for DISPATCH at IETF108 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 23:14:43 -0000 --0000000000000e484605aa83160b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Nit: Ted Hardie (spelling) On Wed, Jul 15, 2020 at 5:10 PM Ben Campbell wrote: > Hi, > > A _draft_ agenda for the IETF108 DISPATCH meeting is available at > https://datatracker.ietf.org/meeting/108/materials/agenda-108-dispatch-01= . > (Copied below for your convenience.). Please send any bashes, omissions, = or > other comments to the chairs and list as soon as possible. > > Thanks! > > Ben. > > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 > # DISPATCH Virtual Meeting @IETF-108 > > Monday, July 27, 2020 > 11:00-12:40 UTC > > [MeetEcho](http://www.meetecho.com/ietf108/dispatch/) > > [Notes](https://codimd.ietf.org/notes-ietf-108-dispatch) > > [Jabber](xmpp:dispatch@jabber.ietf.org?join) > > DISPATCH Meeting > ---------------- > > ### Status and Agenda Bash - Chairs and ADs (10 min) > > ### RFC 3405 Update - Ted Hardy(15 min) > > [Draft]( > https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/) > > ### Proposed HTTP API Buiding Blocks WG - Mark Nottingham (20 min) > > [Proposed Charter]( > https://mailarchive.ietf.org/arch/msg/dispatch/pWx1SgjZS4R3nzXEK-jE6xqOqU= c > ) > > ### JSON Path - Carsten Borman (20 min) > > Discussion: Should this be a candidate for the proposed HTTP API WG? > > [Draft](https://datatracker.ietf.org/doc/draft-goessner-dispatch-jsonpath= / > ) > > ### SFrame - TBD (20 min) > > [Draft](https://datatracker.ietf.org/doc/draft-omara-sframe/) > > > ART AREA Meeting > ---------------- > > ### BoFs and meetings of interest - ADs (10 min) > > ### AOB > > --0000000000000e484605aa83160b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Nit: Ted Hardie (spelling)

On Wed, Jul 15,= 2020 at 5:10 PM Ben Campbell <ben@no= strum.com> wrote:
Hi,

=
A _draft_ agenda for the IETF108 DISPATCH meeting is available at=C2= =A0https://datatracker.ietf.org/meeting/108/ma= terials/agenda-108-dispatch-01=C2=A0. (Copied below for your convenienc= e.). Please send any bashes, omissions, or other comments to the chairs and= list as soon as possible.

Thanks!

<= /div>
Ben.

=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94
# DISPATCH Virtual Meeting @IETF-108=C2= =A0

Monday, July 27, 2020
11:00-12:40 UT= C




DISPATCH Meeting=C2=A0
----------------

### Status and Agenda Bash = - Chairs and ADs (10 min)

### RFC 3405 Update - Te= d Hardy(15 min)


### Proposed HTTP API Buiding Blocks WG - Mark No= ttingham (20 min)


### JSON Path - Carsten Borm= an (20 min)

Discussion: Should this be a candidate= for the proposed HTTP API WG?


### SFrame - TBD (20 min)

<= /div>


ART AREA Meeting=C2=A0
----------------

### BoFs and meetings of i= nterest - ADs (10 min)

### AOB
--0000000000000e484605aa83160b-- From nobody Wed Jul 15 16:27:48 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A953A0B51; Wed, 15 Jul 2020 16:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.411 X-Spam-Level: X-Spam-Status: No, score=-0.411 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.267, MAY_BE_FORGED=1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 8UZyLmpuvMdN; Wed, 15 Jul 2020 16:27:45 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 735D13A0B4F; Wed, 15 Jul 2020 16:27:45 -0700 (PDT) Received: from bens-macbook.lan (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 06FNRafX068431 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 15 Jul 2020 18:27:37 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1594855658; bh=2cA8t5soaeWlWNaAMLE5hbAnER51p8MBSm1TTWfVWw0=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=Qevkx9bIm4ODQK9Tlj7lNGL20dABehrmbQns8ODeB+vXNENJCCGTFHjblQb3uGaUZ I39lW6Oa3uk5P/LfzcJ5QE+NvzOb5CASuxNhSNv3B/lE+5XUXBGW1irea9k2ca6ZdP 4daULExTSlz0YCNsZr2JtypCFrKfKxESFQydp8IA= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be bens-macbook.lan From: Ben Campbell Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_1488FE6D-EF99-4192-AC30-95F470FC51E3" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 15 Jul 2020 18:27:29 -0500 In-Reply-To: Cc: ART ADs , DISPATCH WG , Patrick McManus To: Barry Leiba References: <04FF34F7-0E17-43E6-9885-08959C0BE50A@nostrum.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [dispatch] Agenda for DISPATCH at IETF108 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 23:27:47 -0000 --Apple-Mail=_1488FE6D-EF99-4192-AC30-95F470FC51E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Sigh. Of course I knew that. Fixed on the datatracker. Ben. > On Jul 15, 2020, at 6:14 PM, Barry Leiba = wrote: >=20 > Nit: Ted Hardie (spelling) >=20 > On Wed, Jul 15, 2020 at 5:10 PM Ben Campbell > wrote: > Hi, >=20 > A _draft_ agenda for the IETF108 DISPATCH meeting is available at = https://datatracker.ietf.org/meeting/108/materials/agenda-108-dispatch-01 = . (Copied below for your convenience.). Please send any bashes, = omissions, or other comments to the chairs and list as soon as possible. >=20 > Thanks! >=20 > Ben. >=20 > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 > # DISPATCH Virtual Meeting @IETF-108=20 >=20 > Monday, July 27, 2020 > 11:00-12:40 UTC >=20 > [MeetEcho](http://www.meetecho.com/ietf108/dispatch/ = ) >=20 > [Notes](https://codimd.ietf.org/notes-ietf-108-dispatch = ) >=20 > [Jabber](xmpp:dispatch@jabber.ietf.org?join <>) >=20 > DISPATCH Meeting=20 > ---------------- >=20 > ### Status and Agenda Bash - Chairs and ADs (10 min) >=20 > ### RFC 3405 Update - Ted Hardy(15 min) >=20 > = [Draft](https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-upd= ate/ = ) >=20 > ### Proposed HTTP API Buiding Blocks WG - Mark Nottingham (20 min) >=20 > [Proposed = Charter](https://mailarchive.ietf.org/arch/msg/dispatch/pWx1SgjZS4R3nzXEK-= jE6xqOqUc = ) >=20 > ### JSON Path - Carsten Borman (20 min) >=20 > Discussion: Should this be a candidate for the proposed HTTP API WG? >=20 > = [Draft](https://datatracker.ietf.org/doc/draft-goessner-dispatch-jsonpath/= ) >=20 > ### SFrame - TBD (20 min) >=20 > [Draft](https://datatracker.ietf.org/doc/draft-omara-sframe/ = ) >=20 >=20 > ART AREA Meeting=20 > ---------------- >=20 > ### BoFs and meetings of interest - ADs (10 min) >=20 > ### AOB >=20 --Apple-Mail=_1488FE6D-EF99-4192-AC30-95F470FC51E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Sigh.= Of course I knew that.

Fixed on the datatracker.

Ben.

On Jul = 15, 2020, at 6:14 PM, Barry Leiba <barryleiba@computer.org> wrote:

Nit: Ted Hardie (spelling)

On Wed, Jul 15, 2020 at 5:10 PM Ben Campbell <ben@nostrum.com> = wrote:
Hi,

A = _draft_ agenda for the IETF108 DISPATCH meeting is available at https://datatracker.ietf.org/meeting/108/materials/agenda-108-d= ispatch-01 . (Copied below for your convenience.). Please send = any bashes, omissions, or other comments to the chairs and list as soon = as possible.

Thanks!

Ben.

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94
# DISPATCH Virtual Meeting = @IETF-108 

Monday, July 27, 2020
11:00-12:40 = UTC




DISPATCH = Meeting 
----------------

### Status and Agenda = Bash - Chairs and ADs (10 min)

### RFC 3405 Update - Ted Hardy(15 = min)


###= Proposed HTTP API Buiding Blocks WG - Mark Nottingham (20 = min)


### JSON Path - Carsten Borman (20 min)

Discussion: Should this = be a candidate for the proposed HTTP API WG?


### = SFrame - TBD (20 min)

=


ART AREA Meeting 
----------------

### BoFs and meetings of interest - ADs (10 min)

### AOB


= --Apple-Mail=_1488FE6D-EF99-4192-AC30-95F470FC51E3-- From nobody Thu Jul 16 00:56:14 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9293A105C for ; Thu, 16 Jul 2020 00:56:13 -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, FREEMAIL_FROM=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 CLqexvXA1KCj for ; Thu, 16 Jul 2020 00:56:11 -0700 (PDT) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 AFFC33A0FA2 for ; Thu, 16 Jul 2020 00:56:11 -0700 (PDT) Received: by mail-pl1-x62b.google.com with SMTP id x8so3508410plm.10 for ; Thu, 16 Jul 2020 00:56:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fHV9Gp8jpZNTq+kBeSKCXi/JA9xHEiOs1hr2K8qYFYs=; b=duMsSA0D/BhXGsHCX4X9sWOCRNhd5A5Mv1j6RjmWqitGqYixBUQcTJ9YMnPnyjrAid hTEWbjhFS4hxkLTVkUfkeG9ZKouHimKdbO4I5k+DYczNrdP27+iEiNKUon+Jsc2EA+o8 xEmvO1ois+SHtpE+FVzdt7lLPf01wQ/WDAf+lYP2HF1268gKw+b2iPAMzsKLbHYrTqCZ rcp6ErCYkCmgJWFqrOMcPET545/sKw4bYA2Vr0zRL7R8wk2DXyFGB88D5cFr53C1x270 SclT6QonaTgLBw2DbZKDCPTNTHAKQkevje6UwhT/31B/KhYl45g+xjUvMHQRcy9LiyBK uvsQ== 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=fHV9Gp8jpZNTq+kBeSKCXi/JA9xHEiOs1hr2K8qYFYs=; b=PtjYpVa393coxfbtz6qhmQNHwSiv9/chRiFKro6den0Lohq9Ws9bVEnrZg7ulqh6gk dfGo9xIJ6ZrjobtfFSoI6VhkbjE/igR4U9hcGW5KIPO85Xjqf+PV9gqOTxm1X4dw40Fh IwIiUfG2dDg9iJb/zaYJ3zz8zn5E6m5OS6GRuc/N5OyQZUJPkCjFtyK3pdeVHpsPCW1Q Vy2iiIY+fdeoeWhH7zUx/uBxacH6B/YQpcqRmieay1D5CiPaNbPMti4uYQG7bJs4IF6g BlkKUK7UZkxQLOkbwQj2mKlPkh3ESvx3k6t6uS2ZCPOL55vOgIpyVFK5BBasUP0AA088 cZWA== X-Gm-Message-State: AOAM530dlrUTZj+jJ8h3yEo3YnlDF//AVH2Tmbo77kl1diHeLJsT5vAJ g7AkUNciv5Z/1rISZwCrmYxGK6xu X-Google-Smtp-Source: ABdhPJzMP/zqJMO1yvcI8NZdjVhxAPaBIsuO07DFvphr/SqML/6U2zH/Z1KrBWzVs3sj8zQko+wO7A== X-Received: by 2002:a17:90a:eac7:: with SMTP id ev7mr3320232pjb.21.1594886171043; Thu, 16 Jul 2020 00:56:11 -0700 (PDT) Received: from [192.168.42.5] (135-180-96-53.fiber.dynamic.sonic.net. [135.180.96.53]) by smtp.gmail.com with ESMTPSA id n63sm4167156pfd.209.2020.07.16.00.56.09 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Thu, 16 Jul 2020 00:56:10 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Toomim In-Reply-To: Date: Thu, 16 Jul 2020 00:56:09 -0700 Cc: Lucas Pardue , DISPATCH WG Content-Transfer-Encoding: quoted-printable Message-Id: <99642E4F-047C-4A2B-801C-E4E3FA3265E6@gmail.com> References: <111A89F4-CBD6-4C63-A45A-C7458E7413FF@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [dispatch] A WG for HTTP API Building Blocks X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 07:56:13 -0000 I also see value in recruiting API developers and consumers, but (like = Lucas) I struggle to distinguish whether a particular proposal "foo" = would be demarcated as HTTP vs. HTTP API. As a present example, how do we classify the Braid proposal? = https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-braid-http On the one hand, we could describe it as "push-update for REST APIs", = and then put it into the HTTP API bucket. But on the other, Braid also applies to browsers and proxies, where it = improves caching, reduces network traffic, and allows pages to update = automatically without a reload button. That sounds like core HTTP. Historical examples could also be interesting. How do we classify HTTP = Live Streaming? https://tools.ietf.org/html/rfc8216 This is an API standard, which does not need special browser support. = However, most mobile browsers (but not desktop) now have native = implementations for better performance. Does that make it HTTP core?= From nobody Thu Jul 16 01:10:10 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1253F3A10DC for ; Thu, 16 Jul 2020 01:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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=mnot.net header.b=leyLsY/w; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CvvcDv1P 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 YTgvzP6HazZx for ; Thu, 16 Jul 2020 01:10:05 -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 53CEF3A0838 for ; Thu, 16 Jul 2020 01:09:44 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 628D55C0170; Thu, 16 Jul 2020 04:09:43 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 16 Jul 2020 04:09:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=e Bu6jDFiJy4vwZ3wtYpHzhxC/9VO/klk585r37uYwX4=; b=leyLsY/w6Rj0alkGJ BR8ZRvwg7+OK/U0ZtjgZTtX6fWdl4yHQXshcZkTb6rcza9cbcnXBV+T2ntA5eD9b kBuW8iyqg31Es7jEqQfR7u8tEJBNoj763SfSNS8AU2Vk7rRKLIxTwFh98L0Hezg7 4YYBb7FjM/EelYuvdDbkS+zCBnKLv6Q5QLhC142dSiPSdjUemuy15KClwxEMC98J /zkexFsP2ALYnml3Fc4LiX3BtcoOSafhTIeSM4g+mzADic3GZB4tyGxijotVxNT2 7rVej57ni5Fh3IwSdN01hZ+YguGtdlvqTHB/YaQoFogB/KFciYPDcF51rDxLdNaF /rXBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=fm3; bh=eBu6jDFiJy4vwZ3wtYpHzhxC/9VO/klk585r37uYw X4=; b=CvvcDv1PRUaiji4bi7cO9jLjWxbtELHUL3GFS0MkpLimOJBw9WwlUQI7I JNFbCqPIJ0eg3O8v33XN4OYpdUgIin7FOJHRoNJT9zRdKHtCamBYaKPQzALdNCqi uoFC0WAkmev7mAB+GiOyOQve+QCfouAG1tSNKTC0xxU8FaGCX2GYiGr/pIRC+TPn 0Cam536DTqOUg7II7jpmN089b0JtB2rGnRvjIMUgIhMxXvtV1PMH478xzPT//Psg EX9tQFOJgAI12IGfJRBUziaAXyicc9WOIRcBofLSCcyrtQOdUuabUQnO3L0bO+Lk fAk+49WJu+y07MAUoeNI1k7pw4wsA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrfeeggddtudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepjeeigeekuefhhefgheetvddtlefhvdehhfelvdegleffhedvuddtueeguedukeeg necuffhomhgrihhnpehhthhtphgrphhirdgrshdpihgvthhfrdhorhhgpdhhihhsthhorh hitggrlhgvgigrmhhplhgvshgtohhulhgurghlshhosggvihhnthgvrhgvshhtihhnghdr hhhofidpmhhnohhtrdhnvghtnecukfhppeduudelrddujedrudehkedrvdehudenucevlh hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhn ohhtrdhnvght X-ME-Proxy: Received: from marks-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 73A8C3060067; Thu, 16 Jul 2020 04:09:41 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Mark Nottingham In-Reply-To: <99642E4F-047C-4A2B-801C-E4E3FA3265E6@gmail.com> Date: Thu, 16 Jul 2020 18:09:38 +1000 Cc: Lucas Pardue , DISPATCH WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <111A89F4-CBD6-4C63-A45A-C7458E7413FF@mnot.net> <99642E4F-047C-4A2B-801C-E4E3FA3265E6@gmail.com> To: Michael Toomim X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [dispatch] A WG for HTTP API Building Blocks X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 08:10:09 -0000 Great example.=20 I think that if you got HTTP WG folks excited about BRAID and some folks = putting their hands up to implement it there, it would take it on. So = far, the reaction has been of interest, but I'm not sure we're quite to = the point where we'll adopt it; personally I'm still looking for more = people to say 'yes, I want to implement that' and/or 'yes, I have a use = case for that.' That may still happen, in time. If not, and we had an HTTP APIs WG, you could take it there and see if = you could get traction with that community; since it's not defining new = methods or status codes, and it doesn't necessarily need browser = implementation to be useful, that should work. There's one proviso, however; if the HTTP WG thought it was a bad idea = (e.g., actively harmful, bad for HTTP, conflicting with other work, or = just a bad starting point for work) it wouldn't be good for the HTTP = APIs WG to take it on, because that would be 'venue shopping.' Does that help?=20 > On 16 Jul 2020, at 5:56 pm, Michael Toomim wrote: >=20 > I also see value in recruiting API developers and consumers, but (like = Lucas) I struggle to distinguish whether a particular proposal "foo" = would be demarcated as HTTP vs. HTTP API. >=20 > As a present example, how do we classify the Braid proposal? >=20 > = https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-braid-http >=20 > On the one hand, we could describe it as "push-update for REST APIs", = and then put it into the HTTP API bucket. >=20 > But on the other, Braid also applies to browsers and proxies, where it = improves caching, reduces network traffic, and allows pages to update = automatically without a reload button. That sounds like core HTTP. >=20 > Historical examples could also be interesting. How do we classify = HTTP Live Streaming? >=20 > https://tools.ietf.org/html/rfc8216 >=20 > This is an API standard, which does not need special browser support. = However, most mobile browsers (but not desktop) now have native = implementations for better performance. Does that make it HTTP core? -- Mark Nottingham https://www.mnot.net/ From nobody Thu Jul 16 02:00:08 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 997923A1215 for ; Thu, 16 Jul 2020 02:00:07 -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, FREEMAIL_FROM=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 asHPEKjiBvre for ; Thu, 16 Jul 2020 02:00:06 -0700 (PDT) Received: from mail-pl1-x641.google.com (mail-pl1-x641.google.com [IPv6:2607:f8b0:4864:20::641]) (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 3BA783A11FE for ; Thu, 16 Jul 2020 02:00:06 -0700 (PDT) Received: by mail-pl1-x641.google.com with SMTP id w17so3571193ply.11 for ; Thu, 16 Jul 2020 02:00:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=E3sdh1Fy7LsQL1z9GZC0ruUyOw9POEpTkluA4/z3f20=; b=Q72fIZOZR/xDGsQFRQT8+NT7/fJUunGUEtj0Gl02uycnNlOktcAPYnGXfLkCbH3kiM 1JFxTiidTTWCcJrTUl0mOkf4Hl/TgwyqZTN2nS9zMHfCCJL0/pZpgZR2NVcqS4DBOrec XojKkXS+hLnOSWvBPZ1TDZMWLxeltKsEfjXoNVDo/MBeiqGIkSHO5ecojX18dst6An9z QEuwQzcdsEIFMtSXrCfHyMc/MhTS/8MLj6JWYgwseYZg/jUBIws6vY6McU/KHWXgzkBH cZGzWGBvgIfu9tdRKq1b3cMFNnQ81aBmI8UW7rev1FkOunHN6ayyvvJo8DpJvsCrDx61 x2VQ== 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=E3sdh1Fy7LsQL1z9GZC0ruUyOw9POEpTkluA4/z3f20=; b=Ey9lVxezLngw1xgV6YM1KVqO4jeRgmFxhm0u4RpnRRwQAEawHIuWK5H0AoTB30/Civ IP2lU2tBS+KodniaFlhAuGHihR4XWmJ8hCNVqmLDO3b3hCJQbBIyp9fr/5MQFHcLulh7 kHQPnalE6KDQacglD4XZp23rdzYZkA+qbUXo74os0t/O9eEwhzjczjD5/wT9nsfDj3Mv OaR36LcdHlrj+PHAOkEWWQ9IyAlwDhwL8L2y1GhPH1diYI38/evtIrtivqZyrhnHJrW+ eyYABGHx/iIAm1LixFHhs+E9oXW0kdhESztPARQJwsFv2z4KYEvB4lYm8/3KkLJ75aAQ LiLg== X-Gm-Message-State: AOAM532nySGTpg8YnmkHR5f91iy9MFcyqsRx2lWPjXBDs2iEC96Lh90q DQkya2015/1R14ciwGPMycA4dnxd X-Google-Smtp-Source: ABdhPJzjUI2/1SbRmMcju6ObpGME/3jYClPThu8RZn5AOBT9Uo5ix7JkcQspVlwilHhIaUuMGpYeKA== X-Received: by 2002:a17:90a:368c:: with SMTP id t12mr3816651pjb.90.1594890005677; Thu, 16 Jul 2020 02:00:05 -0700 (PDT) Received: from [192.168.42.5] (135-180-96-53.fiber.dynamic.sonic.net. [135.180.96.53]) by smtp.gmail.com with ESMTPSA id r17sm4371451pfg.62.2020.07.16.02.00.04 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Thu, 16 Jul 2020 02:00:05 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Toomim In-Reply-To: Date: Thu, 16 Jul 2020 02:00:04 -0700 Cc: Lucas Pardue , DISPATCH WG Content-Transfer-Encoding: quoted-printable Message-Id: <79387279-56D6-495A-9C64-D2AD13F8D47C@gmail.com> References: <111A89F4-CBD6-4C63-A45A-C7458E7413FF@mnot.net> <99642E4F-047C-4A2B-801C-E4E3FA3265E6@gmail.com> To: Mark Nottingham X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [dispatch] A WG for HTTP API Building Blocks X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 09:00:08 -0000 Thanks Mark, but my question wasn't about how to get a particular = proposal adopted. I'm trying to find clarity on how we would = distinguish these two working groups. The purpose of these two examples (one current proposal, one historical) = is just to give us something concrete to deliberate. Are these examples = of HTTP work, or HTTP API work? Distinguishing these groups seems important because they are so similar. = If we have trouble identifying which group should take which work right = now, when nothing is at stake, I could imagine difficulties at scale. = I'd love to find some clear criteria. > On Jul 16, 2020, at 1:09 AM, Mark Nottingham wrote: >=20 > Great example.=20 >=20 > I think that if you got HTTP WG folks excited about BRAID and some = folks putting their hands up to implement it there, it would take it on. = So far, the reaction has been of interest, but I'm not sure we're quite = to the point where we'll adopt it; personally I'm still looking for more = people to say 'yes, I want to implement that' and/or 'yes, I have a use = case for that.' That may still happen, in time. >=20 > If not, and we had an HTTP APIs WG, you could take it there and see if = you could get traction with that community; since it's not defining new = methods or status codes, and it doesn't necessarily need browser = implementation to be useful, that should work. >=20 > There's one proviso, however; if the HTTP WG thought it was a bad idea = (e.g., actively harmful, bad for HTTP, conflicting with other work, or = just a bad starting point for work) it wouldn't be good for the HTTP = APIs WG to take it on, because that would be 'venue shopping.' >=20 > Does that help?=20 >=20 >=20 >=20 >> On 16 Jul 2020, at 5:56 pm, Michael Toomim wrote: >>=20 >> I also see value in recruiting API developers and consumers, but = (like Lucas) I struggle to distinguish whether a particular proposal = "foo" would be demarcated as HTTP vs. HTTP API. >>=20 >> As a present example, how do we classify the Braid proposal? >>=20 >> = https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-braid-http >>=20 >> On the one hand, we could describe it as "push-update for REST APIs", = and then put it into the HTTP API bucket. >>=20 >> But on the other, Braid also applies to browsers and proxies, where = it improves caching, reduces network traffic, and allows pages to update = automatically without a reload button. That sounds like core HTTP. >>=20 >> Historical examples could also be interesting. How do we classify = HTTP Live Streaming? >>=20 >> https://tools.ietf.org/html/rfc8216 >>=20 >> This is an API standard, which does not need special browser support. = However, most mobile browsers (but not desktop) now have native = implementations for better performance. Does that make it HTTP core? >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 From nobody Thu Jul 16 02:12:17 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16D9D3A123C for ; Thu, 16 Jul 2020 02:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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=mnot.net header.b=lXxFL4jF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=sW4mWbRf 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 OXY9Rcjk09Es for ; Thu, 16 Jul 2020 02:12:14 -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 52FFE3A1238 for ; Thu, 16 Jul 2020 02:12:14 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 7B6425C0113; Thu, 16 Jul 2020 05:12:13 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 16 Jul 2020 05:12:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=U 8rYPf2TSPH2Uic1H5jC7WPA90oCt6sxW5rQUuy16ds=; b=lXxFL4jF6vXv9RKAV ZdQBPpAblesxmUP84XnSRSQh5CVUodoBEj0H7YHJMP/Ezq5dDr3HLLDlnLDdlBmq +f7EuL6O7n9MmRHIeEj7TDMpYcCSDV+IiCWwA6HtPiwaytc8EH81b3+d73lJsbSp xErRB8byS9lQm7FM7YPDmgKDNLknOwMTK0bCgoHlnwjNinzOuftPddQ9DKmUm94e GqzVvT6KPRdpfQVjtcU+Q4TIPfUEV8H2rB1z9mVYMtgUySoqFLBaDyvoOUIhWztM ZqPbTD2/uiXoQ0kwt9fTkq4B1e7doK/Yn4Z2GBjiu3U4p3ZhgumCB8TmermR9Z1L ly7pg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=fm3; bh=U8rYPf2TSPH2Uic1H5jC7WPA90oCt6sxW5rQUuy16 ds=; b=sW4mWbRfAAl6a6z7gbNR8g1kgJe5ErD5tBBjSw2SPq2xBhzek6Hxl+sKH Q5J4wcOkmvagJ+gPuLMd0I/r9RXxtMX7utw/9bvu8pjDBfN0/lF5Mu7bH0WcTd6h 18SBunUdBw4lovO3wwJOFzF3xdNNYuj3h7i55RWgXcDKGvq7APuuDcQUf5jmCntG HKR9ld4Qko9hbJlMt6aNh8VXFcammgmKCwMuvoCyH0acsIbl/QK+0rLwkTe8HTzY mDYqUJU4e+YUo545+k4QHiroU27Iexpk2ZDNC1bq/gtzoZxP3gYkbvIRc7FDKem7 F1mK0KBYc34QupgUhzogKuImlPsWg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrfeeggddufecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepjeeigeekuefhhefgheetvddtlefhvdehhfelvdegleffhedvuddtueeguedukeeg necuffhomhgrihhnpehhthhtphgrphhirdgrshdpihgvthhfrdhorhhgpdhhihhsthhorh hitggrlhgvgigrmhhplhgvshgtohhulhgurghlshhosggvihhnthgvrhgvshhtihhnghdr hhhofidpmhhnohhtrdhnvghtnecukfhppeduudelrddujedrudehkedrvdehudenucevlh hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhn ohhtrdhnvght X-ME-Proxy: Received: from marks-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 8957030600B4; Thu, 16 Jul 2020 05:12:11 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Mark Nottingham In-Reply-To: <79387279-56D6-495A-9C64-D2AD13F8D47C@gmail.com> Date: Thu, 16 Jul 2020 19:12:07 +1000 Cc: Lucas Pardue , DISPATCH WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <111A89F4-CBD6-4C63-A45A-C7458E7413FF@mnot.net> <99642E4F-047C-4A2B-801C-E4E3FA3265E6@gmail.com> <79387279-56D6-495A-9C64-D2AD13F8D47C@gmail.com> To: Michael Toomim X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [dispatch] A WG for HTTP API Building Blocks X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 09:12:16 -0000 It's not necessary to have a mechanical process for determining what = group something best belongs in; it's negotiated between the various = stakeholders, following any guidance in the RFCs and charters as = appropriate. As I mentioned to Lucas, we already encounter this sort of = situation in other places (e.g., deciding whether a particular HTTP/3 = extension belongs in the QUIC WG, the HTTP WG, or another WG dedicated = to that extension's use case). Cheers, > On 16 Jul 2020, at 7:00 pm, Michael Toomim wrote: >=20 > Thanks Mark, but my question wasn't about how to get a particular = proposal adopted. I'm trying to find clarity on how we would = distinguish these two working groups. >=20 > The purpose of these two examples (one current proposal, one = historical) is just to give us something concrete to deliberate. Are = these examples of HTTP work, or HTTP API work? >=20 > Distinguishing these groups seems important because they are so = similar. If we have trouble identifying which group should take which = work right now, when nothing is at stake, I could imagine difficulties = at scale. I'd love to find some clear criteria. >=20 >> On Jul 16, 2020, at 1:09 AM, Mark Nottingham wrote: >>=20 >> Great example.=20 >>=20 >> I think that if you got HTTP WG folks excited about BRAID and some = folks putting their hands up to implement it there, it would take it on. = So far, the reaction has been of interest, but I'm not sure we're quite = to the point where we'll adopt it; personally I'm still looking for more = people to say 'yes, I want to implement that' and/or 'yes, I have a use = case for that.' That may still happen, in time. >>=20 >> If not, and we had an HTTP APIs WG, you could take it there and see = if you could get traction with that community; since it's not defining = new methods or status codes, and it doesn't necessarily need browser = implementation to be useful, that should work. >>=20 >> There's one proviso, however; if the HTTP WG thought it was a bad = idea (e.g., actively harmful, bad for HTTP, conflicting with other work, = or just a bad starting point for work) it wouldn't be good for the HTTP = APIs WG to take it on, because that would be 'venue shopping.' >>=20 >> Does that help?=20 >>=20 >>=20 >>=20 >>> On 16 Jul 2020, at 5:56 pm, Michael Toomim wrote: >>>=20 >>> I also see value in recruiting API developers and consumers, but = (like Lucas) I struggle to distinguish whether a particular proposal = "foo" would be demarcated as HTTP vs. HTTP API. >>>=20 >>> As a present example, how do we classify the Braid proposal? >>>=20 >>> = https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-braid-http >>>=20 >>> On the one hand, we could describe it as "push-update for REST = APIs", and then put it into the HTTP API bucket. >>>=20 >>> But on the other, Braid also applies to browsers and proxies, where = it improves caching, reduces network traffic, and allows pages to update = automatically without a reload button. That sounds like core HTTP. >>>=20 >>> Historical examples could also be interesting. How do we classify = HTTP Live Streaming? >>>=20 >>> https://tools.ietf.org/html/rfc8216 >>>=20 >>> This is an API standard, which does not need special browser = support. However, most mobile browsers (but not desktop) now have = native implementations for better performance. Does that make it HTTP = core? >>=20 >> -- >> Mark Nottingham https://www.mnot.net/ >>=20 >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Thu Jul 16 09:39:24 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A599F3A0C13 for ; Thu, 16 Jul 2020 09:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.279 X-Spam-Level: X-Spam-Status: No, score=0.279 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, 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=yandex.ru 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 EAq0C7IlCV24 for ; Thu, 16 Jul 2020 09:39:22 -0700 (PDT) Received: from forward105j.mail.yandex.net (forward105j.mail.yandex.net [IPv6:2a02:6b8:0:801:2::108]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8B2C3A0C15 for ; Thu, 16 Jul 2020 09:39:21 -0700 (PDT) Received: from forward102q.mail.yandex.net (forward102q.mail.yandex.net [IPv6:2a02:6b8:c0e:1ba:0:640:516:4e7d]) by forward105j.mail.yandex.net (Yandex) with ESMTP id 2A319B216A7 for ; Thu, 16 Jul 2020 19:32:16 +0300 (MSK) Received: from mxback3q.mail.yandex.net (mxback3q.mail.yandex.net [IPv6:2a02:6b8:c0e:39:0:640:4545:437c]) by forward102q.mail.yandex.net (Yandex) with ESMTP id 22A157F20025 for ; Thu, 16 Jul 2020 19:32:16 +0300 (MSK) Received: from localhost (localhost [::1]) by mxback3q.mail.yandex.net (mxback/Yandex) with ESMTP id IFFUDIP7f8-WFHKi5lW; Thu, 16 Jul 2020 19:32:15 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1594917135; bh=VPVa8hkdkQICV+z4fS6+9RfDdvbqcKfghWelQqmE4fw=; h=Message-Id:Date:Subject:To:From; b=d6UotrdE3Ahs1Y1FQryL8rLQf71LZkIqLvoZaJocqXxZIo1c6nB9Bo2RZkXbr0OKd /oD0cMVoxTi68W8Fs54iPUKD446G5wBIwgkVVJoxvElnMHKtmUmsawXipWYUJ2XbOc Mac7lTtl7c6uuuOmyj+gxEgZrUf7Lj7bC+XI9IvQ= Authentication-Results: mxback3q.mail.yandex.net; dkim=pass header.i=@yandex.ru Received: by vla5-b4d100574cfc.qloud-c.yandex.net with HTTP; Thu, 16 Jul 2020 19:32:15 +0300 From: Anton Tveretin To: DISPATCH list MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Thu, 16 Jul 2020 21:32:15 +0500 Message-Id: <5127121594916975@mail.yandex.ru> Content-Transfer-Encoding: 7bit Content-Type: text/html Archived-At: Subject: Re: [dispatch] A WG for HTTP API Building Blocks X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 16:39:24 -0000
Hello,
Of HTTP APIs, I know XMLHTTPRequest. Is it unsufficient?
And I think there are no common server-side APIs, only server (implementation) specific.
Sincerely yours.
From nobody Thu Jul 16 11:28:12 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7713A0891 for ; Thu, 16 Jul 2020 11:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 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_NONE=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=ipv-sx.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 E31C3H3162i9 for ; Thu, 16 Jul 2020 11:28:10 -0700 (PDT) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 184863A088C for ; Thu, 16 Jul 2020 11:28:09 -0700 (PDT) Received: by mail-qk1-x731.google.com with SMTP id c139so6436074qkg.12 for ; Thu, 16 Jul 2020 11:28:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mhofbXj/mIfDwt6qM22euUwUSm6J5S5I/36hXj2+md4=; b=ne3wAJwvI0euFBL/UsuV+6BH+1k7ezkYUXFvHu7349vazLdiUPLwZ+kafyfSNGYWEd wxvzyVfIu2EEXx8xLhmbNSCY06pH3ptg5dKCeIKpEJxrV3ftOY3kakfAADoLWAH5s85x ZVXCxyPdLWLL7WabsCFiAOURYTmJfJsFOHnk3EAoonewpacL5RYsBL66K8vVI2QmvjQp 6m2yokVqsxrPTSkr/IsjycFkatzxbzfTZfA+C3lI/dH0ONg5DkLhseO2JHL8vQQU1EXn H4wQQ+CFAoEFEUncVyyFzuNgrDVnjN/iqaNJ7flCd2xAUyy3V7kdqKiTaZU9rH/pXz2e A4+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:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mhofbXj/mIfDwt6qM22euUwUSm6J5S5I/36hXj2+md4=; b=dhGXyzmn3c5O81LQb9mcPaQFQrytwrCza8TkH+rG7502pKlUaQm7CxeIbsbeapLuhB 0qjqtkUgEJrb8EEz5cWVOETghOph6QyZWEFXP2jbfprzOakLKI3TJUFcEqj2PbJPs7sR ih9ZdZi+jfWb49n5bR+Ang+BK7+988BrX7DWIfL7aF07YGO4I2dRD2dH0gu7rk7hh6VJ ljefuppCnGKojLYaf4vTlqXwC/g1Ttz2yWvJntAuE+pMh7e3WytpXbEHnN4DLwga2z5J 8P8Ylt9fk65i12FuKy0QvElKMZjGcHpB4K0EDNdwVzYDlKNsUTX7ySBLSgOjlaFzwGKd QnhQ== X-Gm-Message-State: AOAM533OXtcwsOYXQdyloRgYDVj2LIB5QADDhGw3amRpfYwEKa8KBv1b xT9jZrIc5iABgktead6/0X9BOCLCXjd1JQS3yMWpdQ== X-Google-Smtp-Source: ABdhPJwEAm08lMCcYt4pYMYZr2MGo2POpmM8DNMiwJPYAVoeQ22fEcFaQAli1a6mi/zKxazGVXVrRUP9lEMKF+CCT/M= X-Received: by 2002:ae9:e517:: with SMTP id w23mr5134842qkf.159.1594924088867; Thu, 16 Jul 2020 11:28:08 -0700 (PDT) MIME-Version: 1.0 References: <5127121594916975@mail.yandex.ru> In-Reply-To: <5127121594916975@mail.yandex.ru> From: Richard Barnes Date: Thu, 16 Jul 2020 14:27:45 -0400 Message-ID: To: Anton Tveretin Cc: DISPATCH list Content-Type: multipart/alternative; boundary="000000000000c2d13605aa933326" Archived-At: Subject: Re: [dispatch] A WG for HTTP API Building Blocks X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 18:28:12 -0000 --000000000000c2d13605aa933326 Content-Type: text/plain; charset="UTF-8" On Thu, Jul 16, 2020 at 12:39 PM Anton Tveretin wrote: > Hello, > Of HTTP APIs, I know XMLHTTPRequest. Is it unsufficient? > You mean fetch()? :) Yes, the idea here is that raw XHR is insufficient. Saying "XHR is all you need" is like saying "TCP is all you need". > And I think there are no common server-side APIs, only server > (implementation) specific. > There are plenty of standardized things that are effectively HTTP APIs. See, for example: https://tools.ietf.org/html/rfc7030 https://tools.ietf.org/html/rfc8555 https://tools.ietf.org/html/rfc6749 https://tools.ietf.org/html/rfc8620 ... in addition to many examples outside the IETF. --RLB > Sincerely yours. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --000000000000c2d13605aa933326 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jul 16, 2020 at 12:39 PM Anton Tv= eretin <tveretinas@yandex.ru= > wrote:
Hello,
Of HTTP APIs, I know XMLHTTPRe= quest. Is it unsufficient?

You mean f= etch()?=C2=A0 :)=C2=A0 Yes, the idea here is that raw XHR is insufficient.= =C2=A0 Saying "XHR is all you need" is like saying "TCP is a= ll you need".
=C2=A0
And I think there are no common server-side APIs, = only server (implementation) specific.

There are plenty of standardized things that are effectively HTTP APIs.= =C2=A0 See, for example:

https://tools.ietf.org/html/r= fc8555

... in addition to many examples outside the IETF.

--RLB
=C2=A0
Sincerely yours.
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--000000000000c2d13605aa933326-- From nobody Thu Jul 16 11:40:51 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D223A09CF for ; Thu, 16 Jul 2020 11:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.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 rSZLRYOjjR1M for ; Thu, 16 Jul 2020 11:40:48 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 3AAD73A09A6 for ; Thu, 16 Jul 2020 11:40:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1594924845; bh=7IxU6VPbhEdn37BeGR8qDPpMAo+5BHb3C88hxNug3hA=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=BAgK7hLP0VLevm4vhWJ3Zgh8if8KAUXsk3bF0zdjAmNUV0uYUSp2fl59SKTsY4mUi 3eDceHpFaleW/Z0fyBWpg4hBzbOA4OdeamFJByxUx+22t3VyZOvgRYkfU4z+WQ3jWP Tq6TmkO+JfJl7BvleXr0XjZzrtf1XU0Mev8YPgVw= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.182] ([91.61.50.86]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MDhlf-1k6tNC0C87-00An8j; Thu, 16 Jul 2020 20:40:45 +0200 To: Anton Tveretin , DISPATCH list References: <5127121594916975@mail.yandex.ru> From: Julian Reschke Message-ID: <50e68abf-9c71-e7b6-7c38-de62e614646c@gmx.de> Date: Thu, 16 Jul 2020 20:40:40 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <5127121594916975@mail.yandex.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:kU0/F40qUaUajbDNerQo8otD1pi1Z+4nym9yVFFOUarKZ2qMIWJ surMfjLCpc/eOX5TgXfYU6pXDMMe3ZRkirxaSGEfbW+4Tt53Ti9QH38agTD7nCdDl+Wx5QX i2trdTkVAusf976X8WznXTIAUp3xN8xLVx20p/wsPOvrkZ3svy3UHM1o72cxZO58tNPyooI j8SnpF2dV7uBQw0Xa7H5w== X-UI-Out-Filterresults: notjunk:1;V03:K0:FWuAC6Jyo9E=:2AvvHKLIWxtwJCsuEQf1vh Ww3HompbICk7oETDt4ORjSW2K7/fNDd4P9aLYPMnu1DOhbIweYNZ27OeUk/cmIlxX6UdwhjbA h0v2o3ICXrlflv2pm1g6l1GCeh4A6F9VlSpKgvpgX+mrovLdY2urwDov89DtoJ+xFqH8+UpMI /dqH5XozIdHPXTu3TcSzR91VkWgrGHS73DQuuQdQg5SxhC+SQlVGAveCU71YwwZjrfrY0Z5+M O45OMaCUrBNs/5DaIxaFo2wyAW9S3su8ddvkZzSLf6QGA2B0kAT4/CBjsirNEO9n/9A9egONt fQAICOzvZllVU4d6wtB57EVFOx19VDkL+0PC2P9gFwiRcnesxXUg6o7FfddXI79kEsmxiHw3L AoWOS0jmlQNcugQ62fDt1VYNDHDxDvYiuY/g+hwbzyvvakOdDASolci4z9o7l0A/XH7CGarIO o9aTIaTD+X172HYNbexOoix/VwGB8V9Z/wU6ryVcHIdj+UwonHHlyC67pP2NIYRr2b550sRI4 lBK9naCeL8bIXf0A5hmtwhv9/MoWGs2XHgklUjS3IYM+mVADJIwQK8twDn5WEDuyxf/2tigCP T+nU70Jjm3eJcz3N9aWLGYgKjafM0apSCCYpTCHwcWSqFOdpUNImBKG4XshVVEW1MtEqRfktL FZPqUGs6mm39X+lS9/ecIzPd5ezIaCc7x0wFsmsJ0QXm5wjTZoKSPaOEGtt3kGrF88vM9M+9d qrr2mD44DRms3yQ0bX0zSJ7tnpF73YBa7GML33cJIY+yJE76lbshvwpE7PPEoeeX0RdCOP5xb OwJPryzYvQfXaVn2sNpgS0F7O9RjsPVJeR9TPAKXWQORLWdv3O8gAIg2H5VUHEJnRCv+ZcwK5 W+waw7SufY0xXkpqizCTkJY8WUYeaMiZdIVaTEO86XsXZTcdmYYCtVl44e2aomjV/mONIftoU tP3fszQmo1aVha7GpKpWDGeHtW2z26n53AmQxQCdYhyDYxe9AyDHmg0zXcKlf99LtvkGPvXyh DoTPBbnR5Y0hYSr/PLXlSm32u/V/95B/0yp78j60yctxOQHPFkpBGI0UfaucPPd09wy1agc+U 5fVdtjGEsIKB9KENjRAfn2jvmjWMloJ18+Cw9ki/BDYjiNq4XlZENEQrvgJpesoO2psEA6Sg/ BFZqxCYDGds0RHEoO56GUNOOBjW336IPx2nCt+GOrwwbaGBusaqwEQvOtF7sDHJRPe9wi7aOg ZnS2R3/XO6BXGNTxtoYfj0tXFcT5hy1cqnkHuqw== Archived-At: Subject: Re: [dispatch] A WG for HTTP API Building Blocks X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 18:40:50 -0000 On 16.07.2020 18:32, Anton Tveretin wrote: > Hello, > Of HTTP APIs, I know XMLHTTPRequest. Is it unsufficient? There are tons of APIs for clients. Not everything is a browser. > And I think there are no common server-side APIs, only server > (implementation) specific. There are many, for instance the Java Servlet API or JAX-RS for Java. I'm sure there are similar things for other languages. Best regards, Julian From nobody Thu Jul 16 11:55:06 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B25293A0ADC for ; Thu, 16 Jul 2020 11:55:00 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 5A_JI0ukgThD for ; Thu, 16 Jul 2020 11:54:59 -0700 (PDT) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 60BBB3A0B13 for ; Thu, 16 Jul 2020 11:54:59 -0700 (PDT) Received: by mail-pl1-x630.google.com with SMTP id 72so4268932ple.0 for ; Thu, 16 Jul 2020 11:54:59 -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=WhYcc/aDJpjPVciLszcc9hErVBEu1mD3FjhXMRhHa60=; b=schN2ClQxvZeFht3ow718VGi83WLXTnebhSaQ0Rya4EojQ5xREVuZQAZVG6h8YQcBc ULPs/yF+Zd+nwRrdtiwOoAqKGVcEwcuVl2BDi9t8Ds0yOSJdcPYf2W7FIbrYIaHhB9C+ ANwtRnDp+AOSvdXM1xtCaMQqVGh4jZegTo036FPYVO7oOZ7io4uHsfIZKbIATwOIOWug w9VpVx0CubCd5wMQZVF4GSblHWyY0XajUX3Ih9b2GCBCaoJpJ25MBvquNmJn3igWg3xE Nu0qcjuGQ8IMpB3Y2nmFQePSaY1pvai85fOo89VURU03HgnuBxf/ObJWUDGmhzRkQtRi /Q7w== 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=WhYcc/aDJpjPVciLszcc9hErVBEu1mD3FjhXMRhHa60=; b=F1sN/QfapdwcVKRPIVOkeiLz8Z0TfDAnqbYNvox71z37Ly0KbazqbQcOUq/hIoN5KH tG8Y4qA4oWa9t/n9EYE4VSQkSrBXrku3SxLMABDnTND1mieTthnAixtsRXPmF65+E5qC 3ZOTGdmqWl1GMbPYoGmoLjznYgd5sZKXXTHzJHbhHbBGA0946sq9dlzEqhzgLGLHdzmQ oBuXhFDIi6u81pGNROZfTRBJF4BBKke7DfPZivZaKAyjJJF/Abk5EzscCTLrDMTEQoPc 5uB8exUJIKjeVG2plXEtkZ2Q3UyGuu4PGEMWA7g7YIUjcQoSg8UsQQhFWlgGt5FKmNaR ptFw== X-Gm-Message-State: AOAM532nab1GasV/Z17VTUkxSbn2a+Rq71g9vSPY3tDGHXEcqdH7mxWB QqWAvq7b0ruS6tOAX7t9LE5j3pMmL9W3fmnxOSiyZeif X-Google-Smtp-Source: ABdhPJwGnxbS7ZHA7ZozxHxGBbLvj+QeXntmEMncSxG9m8eHHC5dtPvb5Q+Nj1HvnzuhKLEUP84U7i3z9zArKz+s+1E= X-Received: by 2002:a17:90a:3525:: with SMTP id q34mr6357591pjb.192.1594925698824; Thu, 16 Jul 2020 11:54:58 -0700 (PDT) MIME-Version: 1.0 References: <5127121594916975@mail.yandex.ru> In-Reply-To: From: Mary Barnes Date: Thu, 16 Jul 2020 13:54:47 -0500 Message-ID: To: Richard Barnes Cc: Anton Tveretin , DISPATCH list Content-Type: multipart/alternative; boundary="000000000000b8bcd405aa9393bc" Archived-At: Subject: Re: [dispatch] A WG for HTTP API Building Blocks X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 18:55:05 -0000 --000000000000b8bcd405aa9393bc Content-Type: text/plain; charset="UTF-8" And, just to add to the list: XCON CCMP: https://tools.ietf.org/html/rfc6503 HELD: https://tools.ietf.org/html/rfc5985 We've been doing a lot of this for a while. - MLB On Thu, Jul 16, 2020 at 1:28 PM Richard Barnes wrote: > On Thu, Jul 16, 2020 at 12:39 PM Anton Tveretin > wrote: > >> Hello, >> Of HTTP APIs, I know XMLHTTPRequest. Is it unsufficient? >> > > You mean fetch()? :) Yes, the idea here is that raw XHR is > insufficient. Saying "XHR is all you need" is like saying "TCP is all you > need". > > >> And I think there are no common server-side APIs, only server >> (implementation) specific. >> > > There are plenty of standardized things that are effectively HTTP APIs. > See, for example: > > https://tools.ietf.org/html/rfc7030 > https://tools.ietf.org/html/rfc8555 > https://tools.ietf.org/html/rfc6749 > https://tools.ietf.org/html/rfc8620 > > ... in addition to many examples outside the IETF. > > --RLB > > >> Sincerely yours. >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --000000000000b8bcd405aa9393bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
And, just to add to the list:
We've been doing a lot of this for a while.=C2=A0=C2= =A0

- MLB=C2=A0

On Thu, Jul 16, 2020 at 1:28 = PM Richard Barnes <rlb@ipv.sx> wrote:
On Thu, Jul 1= 6, 2020 at 12:39 PM Anton Tveretin <tveretinas@yandex.ru> wrote:
H= ello,
Of HTTP APIs, I know XMLHTTPRequest. Is it unsufficient?

You mean fetch()?=C2=A0 :)=C2=A0 Yes, t= he idea here is that raw XHR is insufficient.=C2=A0 Saying "XHR is all= you need" is like saying "TCP is all you need".
=C2=A0
And I= think there are no common server-side APIs, only server (implementation) s= pecific.

There are plenty of standard= ized things that are effectively HTTP APIs.=C2=A0 See, for example:


... in addition to many ex= amples outside the IETF.

--RLB
=C2= =A0
Sincerely y= ours.
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--000000000000b8bcd405aa9393bc-- From nobody Thu Jul 16 12:26:39 2020 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 045643A0B40; Thu, 16 Jul 2020 12:26:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: barryleiba@computer.org, dispatch@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.8.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159492757799.14301.6492544456813851775@ietfa.amsl.com> Date: Thu, 16 Jul 2020 12:26:18 -0700 Archived-At: Subject: [dispatch] dispatch - Requested session has been scheduled for IETF 108 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 19:26:18 -0000 Dear Patrick McManus, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dispatch Session 1 (1:40 requested) Monday, 27 July 2020, Session I 1100-1240 Room Name: Room 1 size: 1 --------------------------------------------- Special Note: Joint with ARTAREA iCalendar: https://datatracker.ietf.org/meeting/108/sessions/dispatch.ics Request Information: --------------------------------------------------------- Working Group Name: Dispatch Area Name: Applications and Real-Time Area Session Requester: Patrick McManus Number of Sessions: 1 Length of Session(s): 100 Minutes Number of Attendees: 90 Conflicts to Avoid: Chair Conflict: rum ice stir sipcore mmusic ecrit avtcore cfrg quic httpbis add Technology Overlap: perc cellar capport dmarc jmap uta rmcat extra core opsarea tsvarea tsvwg tram secdispatch Key Participant Conflict: acme cose dprive lamps tls mls People who must be present: Barry Leiba Ben Campbell Murray Kucherawy Patrick McManus Resources Requested: Special Requests: Please schedule in the 1st slot on Monday morning, list the meeting as coupled with ARTAREA. Please avoid conflicts with other ART area WGs and BoFs, other area meetings, and Bofs.. --------------------------------------------------------- From normingtong@vmware.com Fri Jul 17 03:56:26 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 712423A09C3 for ; Fri, 17 Jul 2020 03:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_TRY_3LD=1.999] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=vmware.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 c_zNUmfGAEFX for ; Fri, 17 Jul 2020 03:56:24 -0700 (PDT) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2060.outbound.protection.outlook.com [40.107.237.60]) (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 4535B3A09BE for ; Fri, 17 Jul 2020 03:56:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dpaLVzCL6wFp3hz0rV3+qOnlJRHsb+z1eF6xUBfSswfnHVroJKJQLGiyyF/YcWA4jDcMz2/ln2NFJbzNEjEXQIyZnLbi/4O47AkAvzI/91Imq3Ai24rWukjfUM6081y+FMblicqZWmKfXYxnjiAyoRNWZ13ITCzod3RsVcSqDQLvvRMIpHf4epUf3ktjHMcx5loy5w95ZG2m/z1z969+6sQM26coaai6vaGCUR+uLr/c+g5Z4LOYkGmFlEAaRhPv0I0oLgeLq+Fco9cLCedafgvLVyJFhMHhl0qZ2aBe9Hb6guYZJLv7UEkbMyxfZZMT10hSYFW8TsQfQmBopJ8/+g== 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=BxsVDz4nvvgadMueluH6Vye3Mo8nK+XDRR886T2AxM4=; b=XGIQ/IXLONWimd6ColO0iZ/kLoD4wh/BFJalfW+RpJ6kl3vu86wyin8sR05ymwdMe2ZmgGPNsXf8s3qfiMRyxmUlYYoPrzbE346co+LQ6BqvO5QRG0x4tUeN5+BH2X/JkKyvWImv/zMyPFfEnYJRm7hAsAz9NzynadfqPK6pphsXb134tH5NDUH9uXJnC0fwtjL3WIh29mPMXlpMHCQPAxJdOelp65DYvUsF4z+V5lbSOHsC3A6vNCXzcZxBPKPrulwLn6hN6LywpNWeIaH+PreJGTYhIig4ZdhUa3bKAaelSKTCAL7VfmUBTDokZ24OaOMaLShY/L/AQ9sLzFgWBA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=vmware.com; dmarc=pass action=none header.from=vmware.com; dkim=pass header.d=vmware.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vmware.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BxsVDz4nvvgadMueluH6Vye3Mo8nK+XDRR886T2AxM4=; b=Pv+m+Y4WncaOYiTnGcE1HJGZMmueDmf+z+DrljjTtQ7FRkXOMWj1uKrveCqM1j7K21iCFCS906cmexc4q30VoqEK5I4+3tHNf9G+iNNh4SgI4l6LKZaXwpcPx7Iq7LBBrnIDdktRBavdd4/mw+OIjyCc2SST2JTjp+c4z+Nrbxg= Received: from DM5PR0501MB3766.namprd05.prod.outlook.com (2603:10b6:4:7c::29) by DM5PR05MB3401.namprd05.prod.outlook.com (2603:10b6:4:3f::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.9; Fri, 17 Jul 2020 10:56:20 +0000 Received: from DM5PR0501MB3766.namprd05.prod.outlook.com ([fe80::e93d:dbc3:e9ce:7bc8]) by DM5PR0501MB3766.namprd05.prod.outlook.com ([fe80::e93d:dbc3:e9ce:7bc8%3]) with mapi id 15.20.3195.022; Fri, 17 Jul 2020 10:56:20 +0000 From: Glyn Normington To: "dispatch@ietf.org" Thread-Topic: [dispatch] draft-goessner-dispatch-jsonpath-00.txt Thread-Index: AQHWXCjnBJXyictxJEaIYbkD1NnV+g== Date: Fri, 17 Jul 2020 10:56:20 +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=vmware.com; x-originating-ip: [195.213.80.149] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3e8eebcd-8cc6-49be-28a1-08d82a400a1a x-ms-traffictypediagnostic: DM5PR05MB3401: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: yd1jJxbK5z1UToq019Gh8S4kyJGKB/uQEmnheO9iD6Mt1HwrknHLS1Dk1adyKErVfSMtHcD2FtqKCi/LcfB6JYW4/R/MEnrxzBSy/QIzUE5UT8gEFqv7aQyrUrij+jFAYZw7CiC+0jSDLujnRPeXXpr79yj3L3940GQVVK9khdaxj78uhf3mbr//evD7GU4hTvcpvQWwMSf2u9Fh3KoyP2A2gJsHASp2a7Mqu2QGujTujbXYsfdKSMcSqhXrY+kvPfQ6SNpLMTU21OFBTALDnnOgzlB+PQEo6v36aCiIw8MFilChMLRWir8M0ZEU2c3iCsJKQIZRYmojHYlGKRf3OAQENpIqrJNW5CTxitkKH4oy+3fCmsETz95tbkKfss8Nx8ruoRcCKErsc3ga6GyTkA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR0501MB3766.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(396003)(39860400002)(366004)(136003)(36756003)(64756008)(86362001)(76116006)(66946007)(83380400001)(2906002)(21615005)(66446008)(91956017)(6512007)(33656002)(83080400001)(6506007)(6486002)(166002)(2616005)(66476007)(316002)(8936002)(6916009)(66556008)(5660300002)(966005)(71200400001)(8676002)(478600001)(186003)(26005)(66574015); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: fXBKbly0Vo/sYpGBl5Cj+QhXIs2lVrIFhYzCcYOaEqz9s3utD5mH99FL03bpq1mz5j7C9fG/tOSRMGGo0t9nZkMTYCKsUwBlh6lHxSggRLYAf/DQ6D6IdYrdUOdJRtNGnNxMlHuHfAiuKHba+AgKd/dPGCnblMQPPwH0PcHmUhYCTajs4QCYX/EAd90hIsWcGLJCcLLABCKxbWs7GyOkmnYY3V9esOFxCEcYgc6PliQynNliQ/893YgO7AmgsLMhD9Rhn55H18uDIWNvI34xf3QJO6Yr48rWozreKzWWMiyEA0fbPEBh2x4+tT47psIet9h2GlPfF80YMk07M/LTj1g/bxqloDKzt6Gswb58zhRpWBKIuCSRAYfXdmBSO2sBKtUNHp15TN7gfrEnwCRP7inoD3G4xKB95DRLnmnkZfeoIuukfPgq4uD0gYLw6YqlaqLntSxjokh64n4T6aJMaq4ZR/b1sRgQxob+KbN5LoIp95/TYCBqm4gsX8t5YuOe x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_C157962012ED4BC09B1D9A2D0AB147F2vmwarecom_" MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM5PR0501MB3766.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3e8eebcd-8cc6-49be-28a1-08d82a400a1a X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2020 10:56:20.8005 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TcRED5spMj8xZfjpO/R7hvNYwu/lqZDb3badhebeyic74GHK+WBE+ItfEbozgv3Ntl4B0VmScw3ClFX0fkwcDg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3401 Archived-At: X-Mailman-Approved-At: Fri, 17 Jul 2020 09:18:58 -0700 Subject: Re: [dispatch] draft-goessner-dispatch-jsonpath-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 10:57:07 -0000 --_000_C157962012ED4BC09B1D9A2D0AB147F2vmwarecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2V2ZXJhbCBhdXRob3JzIGFuZCBtYWludGFpbmVycyBvZiBKU09OUGF0aCBpbXBsZW1lbnRhdGlv bnMsIGluY2x1ZGluZyBteXNlbGYsIHN0YXJ0ZWQgdG8gZ2F0aGVyIGluIEp1bmUgdGhpcyB5ZWFy IHRvIGNvbGxhYm9yYXRlIG9uIGFuIEludGVybmV0IERyYWZ0IGZvciBKU09OUGF0aCwgc28gSSBh bSBkZWxpZ2h0ZWQgdG8gc2VlIHRoZSBwb3N0IGJlbG93Lg0KDQpPdXIgYXBwcm9hY2ggc28gZmFy IGhhcyBiZWVuIGluZm9ybWVkIGJ5IENocmlzdG9waCBCZXJnbWVyJ3MgSlNPTlBhdGggaW1wbGVt ZW50YXRpb24gY29tcGFyaXNvbiBwcm9qZWN0IChbMV0pIGFuZCBpdHMgY29tcHV0ZWQgY29uc2Vu c3VzLiBXZSBhcmUgd29ya2luZyBpbiB0aGUgb3BlbiBpbiBhIEdpdEh1YiByZXBvc2l0b3J5IChb Ml0pLiBTZWUgdGhlIGxhdGVzdCBwdWxsIHJlcXVlc3QgdGV4dCAoWzNdKSB0byBnZXQgYW4gaWRl YSBvZiBvdXIgYXBwcm9hY2guIFdlIGFsc28gaGF2ZSBhIHNsYWNrIHdvcmtzcGFjZSB3aGljaCBh bnlvbmUgaXMgd2VsY29tZSB0byBqb2luIChbNF0pLg0KDQpJIGxvb2sgZm9yd2FyZCB0byBhIHN1 aXRhYmxlIFdHIGJlaW5nIGVzdGFibGlzaGVkIHNvIHRoYXQgd2UgY2FuIGNvbGxhYm9yYXRlIHRv Z2V0aGVyLg0KDQpSZWdhcmRzLA0KR2x5bg0KDQpbMV0gaHR0cHM6Ly9jYnVyZ21lci5naXRodWIu aW8vanNvbi1wYXRoLWNvbXBhcmlzb24vDQpbMl0gaHR0cHM6Ly9naXRodWIuY29tL2pzb25wYXRo LXN0YW5kYXJkL2ludGVybmV0LWRyYWZ0DQpbM10gaHR0cHM6Ly9nbHluLmdpdGh1Yi5pby9pbnRl cm5ldC1kcmFmdC8NCls0XSBodHRwczovL2pvaW4uc2xhY2suY29tL3QvanNvbnBhdGgtc3RhbmRh cmQvc2hhcmVkX2ludml0ZS96dC1mcDUyMWhwMC1EN2dtRGNtT01LNFVrclJSdWd+U1FRDQoNCi0t LQ0KSSB3b3VsZCBsaWtlIHRvIGluaXRpYXRlIGRpc2N1c3Npb24gZm9yIGRyYWZ0LWdvZXNzbmVy LWRpc3BhdGNoLWpzb25wYXRoOg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1nb2Vz c25lci1kaXNwYXRjaC1qc29ucGF0aC0wMC5odG1sDQoNCkl0IHNheXM6DQoNCj4gVGhpcyBkb2N1 bWVudCBwaWNrcyB1cCB0aGUgcG9wdWxhciBKU09OUGF0aCBzcGVjaWZpY2F0aW9uIGRhdGVkDQo+ IDIwMDctMDItMjEgYW5kIHByb3ZpZGVzIGEgbW9yZSBub3JtYXRpdmUgZGVmaW5pdGlvbiBmb3Ig aXQuDQo+IEl0IGlzIGludGVuZGVkIGFzIGEgc3VibWlzc2lvbiB0byB0aGUgSUVURiBESVNQQVRD SCBXRywgaW4gb3JkZXIgdG8NCj4gZmluZCB0aGUgcmlnaHQgd2F5IHRvIGNvbXBsZXRlIHN0YW5k YXJkaXphdGlvbiBvZiB0aGlzIHNwZWNpZmljYXRpb24uDQo+IEluIGl0cyBjdXJyZW50IHN0YXRl LCBpdCBpcyBhIHN0cmF3bWFuIGRvY3VtZW50IHNob3dpbmcgd2hhdCBuZWVkcyB0bw0KPiBiZSBj b3ZlcmVkLg0KDQooRm9yIHNvbWUgcmVhc29uIHRoZSBhYnN0cmFjdCBsYW5kZWQgaW4gdGhlIENv bnRyaWJ1dGluZyBub3RlOyB0eXBpY2FsIEludGVybmV0LURyYWZ0IGRlYWRsaW5lIGRheSBib3Rj aC4pDQoNClRoaXMgaXMgYSB3aWRlbHkgaW1wbGVtZW50ZWQgc3BlY2lmaWNhdGlvbiB0aGF0IGhh cyBiZWVuIGFyb3VuZCBmb3IgbW9yZSB0aGFuIGEgZGVjYWRlOyBub3cgbWF5IGJlIGEgZ29vZCBv cHBvcnR1bml0eSB0byBmaW5hbGx5IGdvIGFoZWFkIGFuZCB0dXJuIGl0IGludG8gYSBwcm9wZXIg SW50ZXJuZXQgc3RhbmRhcmRzIGRvY3VtZW50LiAgVGhlIGltbWVkaWF0ZSBjYXVzZSBmb3Igd3Jp dGluZyB0aGlzIHVwIG5vdyBpcyB0aGF0IHNvbWUgSW9UIGRpc2NvdmVyeSB3b3JrIChzb21lIG9m IHdoaWNoIGhhcHBlbnMgaW4gVzNDKSBjYW4gbWFrZSBnb29kIHVzZSBvZiBKU09OUGF0aC4gIENs ZWFybHksIHdlIGFscmVhZHkgaGF2ZSBKU09OIFBvaW50ZXIgKFJGQyA2OTAxKSBmb3IgYSBtb3Jl IGxpbWl0ZWQgc2V0IG9mIGFwcGxpY2F0aW9uczsgdGhlIHNwZWNpZmljYXRpb24gd291bGQgZG8g Z29vZCBpbiBkZWZpbmluZyBob3cgdGhlc2UgdHdvIGZpdCB0b2dldGhlci4NCg0KVGhlcmUgaXMg bm8gYWN0aXZlIFdHIHRoYXQgaW1tZWRpYXRlbHkgZml0cyB0aGlzIHdvcmsuDQoNCkV2ZW50dWFs bHkgQ0RETCBtYXkgcGljayBKU09OUGF0aCB1cCBpbiB0aGUgZm9ybSBvZiBhIHByZWRpY2F0ZSBv cGVyYXRvcjsgdGhpcyBtaWdodCBtYWtlIHRoZSBDQk9SIFdHIHRoZSByaWdodCBncm91cCAod2hp Y2ggcHJvYmFibHkgd291bGQgdGhlbiBnbyBhaGVhZCBhbmQgd3JpdGUgdXAgYW5vdGhlciBzcGVj aWZpY2F0aW9uIHRoYXQgbWFrZXMgSlNPTlBhdGggdXNlZnVsIGZvciBxdWVyeWluZyBDQk9SIGlu c3RhbmNlcyB0aGF0IGdvIGJleW9uZCB0aGUgSlNPTiBnZW5lcmljIGRhdGEgbW9kZWwpLg0KDQpS ZW9wZW5pbmcgdGhlIEpTT04gV0cgbWF5IGJlIGFub3RoZXIgYXBwcm9hY2gsIGFzIG1heSBiZSBj cmVhdGluZyBhIHNob3J0LWxpdmVkIHRhcmdldGVkIFdHLg0KDQpQbGVhc2UgZGlzY3VzcyENCg0K R3LDvMOfZSwgQ2Fyc3Rlbg0KDQoNCg0KPiBCZWdpbiBmb3J3YXJkZWQgbWVzc2FnZToNCj4NCj4g RnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmc+DQo+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZ29l c3NuZXItZGlzcGF0Y2gtanNvbnBhdGgtMDAudHh0DQo+IERhdGU6IDIwMjAtMDctMTMgYXQgMjI6 MDg6NTAgQ0VTVA0KPiBUbzogIlN0ZWZhbiBHw7Zzc25lciIgPHN0ZWZhbi5nb2Vzc25lckBmaC1k b3J0bXVuZC5kZTxtYWlsdG86c3RlZmFuLmdvZXNzbmVyQGZoLWRvcnRtdW5kLmRlPj5kZT4sICJT dGVmYW4gR29zc25lciIgPHN0ZWZhbi5nb2Vzc25lckBmaC1kb3J0bXVuZC5kZTxtYWlsdG86c3Rl ZmFuLmdvZXNzbmVyQGZoLWRvcnRtdW5kLmRlPj5kZT4sICJDYXJzdGVuIEJvcm1hbm4iIDxjYWJv QHR6aS5vcmc8bWFpbHRvOmNhYm9AdHppLm9yZz4+DQo+DQo+DQo+IEEgbmV3IHZlcnNpb24gb2Yg SS1ELCBkcmFmdC1nb2Vzc25lci1kaXNwYXRjaC1qc29ucGF0aC0wMC50eHQNCj4gaGFzIGJlZW4g c3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBDYXJzdGVuIEJvcm1hbm4gYW5kIHBvc3RlZCB0byB0 aGUNCj4gSUVURiByZXBvc2l0b3J5Lg0KPg0KPiBOYW1lOiBkcmFmdC1nb2Vzc25lci1kaXNwYXRj aC1qc29ucGF0aA0KPiBSZXZpc2lvbjogMDANCj4gVGl0bGU6IEpTT05QYXRoIC0tIFhQYXRoIGZv ciBKU09ODQo+IERvY3VtZW50IGRhdGU6IDIwMjAtMDctMTINCj4gR3JvdXA6IEluZGl2aWR1YWwg U3VibWlzc2lvbg0KPiBQYWdlczogMTQNCj4gVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1nb2Vzc25lci1kaXNwYXRjaC1qc29ucGF0aC0w MC50eHQNCj4gU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWdvZXNzbmVyLWRpc3BhdGNoLWpzb25wYXRoLw0KPiBIdG1saXplZDogICAgICAgaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdvZXNzbmVyLWRpc3BhdGNoLWpzb25wYXRo LTAwDQo+IEh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9o dG1sL2RyYWZ0LWdvZXNzbmVyLWRpc3BhdGNoLWpzb25wYXRoDQo+DQo+DQo+IEFic3RyYWN0Og0K PiAgIGluc2VydCBhYnN0cmFjdCBoZXJlDQo+DQo+DQo+DQo+DQo+IFBsZWFzZSBub3RlIHRoYXQg aXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Np b24NCj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBh dCB0b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmc+Lg0KPg0KPiBUaGUgSUVURiBT ZWNyZXRhcmlhdA0KPg0KPg0KDQo= --_000_C157962012ED4BC09B1D9A2D0AB147F2vmwarecom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+U2V2ZXJhbCBhdXRob3Jz IGFuZCBtYWludGFpbmVycyBvZiBKU09OUGF0aCBpbXBsZW1lbnRhdGlvbnMsIGluY2x1ZGluZyBt eXNlbGYsIHN0YXJ0ZWQgdG8gZ2F0aGVyIGluIEp1bmUgdGhpcyB5ZWFyIHRvIGNvbGxhYm9yYXRl IG9uIGFuIEludGVybmV0IERyYWZ0IGZvciBKU09OUGF0aCwgc28gSSBhbSBkZWxpZ2h0ZWQgdG8g c2VlIHRoZSBwb3N0IGJlbG93LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+T3VyIGFwcHJvYWNoIHNvIGZhciBoYXMgYmVlbiBpbmZvcm1l ZCBieSBDaHJpc3RvcGggQmVyZ21lcidzIEpTT05QYXRoIGltcGxlbWVudGF0aW9uIGNvbXBhcmlz b24gcHJvamVjdCAoWzFdKSBhbmQgaXRzIGNvbXB1dGVkIGNvbnNlbnN1cy4gV2UgYXJlIHdvcmtp bmcgaW4gdGhlIG9wZW4gaW4gYSBHaXRIdWIgcmVwb3NpdG9yeSAoWzJdKS4gU2VlIHRoZSBsYXRl c3QgcHVsbCByZXF1ZXN0IHRleHQgKFszXSkgdG8gZ2V0IGFuDQogaWRlYSBvZiBvdXIgYXBwcm9h Y2guIFdlIGFsc28gaGF2ZSBhIHNsYWNrIHdvcmtzcGFjZSB3aGljaCBhbnlvbmUgaXMgd2VsY29t ZSB0byBqb2luIChbNF0pLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+SSBsb29rIGZvcndhcmQgdG8gYSBzdWl0YWJsZSBXRyBiZWluZyBl c3RhYmxpc2hlZCBzbyB0aGF0IHdlIGNhbiBjb2xsYWJvcmF0ZSB0b2dldGhlci48L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlJlZ2FyZHMs PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkdseW48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlsxXSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vY2J1 cmdtZXIuZ2l0aHViLmlvL2pzb24tcGF0aC1jb21wYXJpc29uLyIgY2xhc3M9IiI+aHR0cHM6Ly9j YnVyZ21lci5naXRodWIuaW8vanNvbi1wYXRoLWNvbXBhcmlzb24vPC9hPjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5bMl0mbmJzcDs8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vanNvbnBhdGgtc3Rh bmRhcmQvaW50ZXJuZXQtZHJhZnQiIGNsYXNzPSIiPmh0dHBzOi8vZ2l0aHViLmNvbS9qc29ucGF0 aC1zdGFuZGFyZC9pbnRlcm5ldC1kcmFmdDwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+WzNdJm5i c3A7PGEgaHJlZj0iaHR0cHM6Ly9nbHluLmdpdGh1Yi5pby9pbnRlcm5ldC1kcmFmdC8iIGNsYXNz PSIiPmh0dHBzOi8vZ2x5bi5naXRodWIuaW8vaW50ZXJuZXQtZHJhZnQvPC9hPjwvZGl2Pg0KPGRp diBjbGFzcz0iIj5bNF0mbmJzcDs8YSBocmVmPSJodHRwczovL2pvaW4uc2xhY2suY29tL3QvanNv bnBhdGgtc3RhbmRhcmQvc2hhcmVkX2ludml0ZS96dC1mcDUyMWhwMC1EN2dtRGNtT01LNFVrclJS dWd+U1FRIiBjbGFzcz0iIj5odHRwczovL2pvaW4uc2xhY2suY29tL3QvanNvbnBhdGgtc3RhbmRh cmQvc2hhcmVkX2ludml0ZS96dC1mcDUyMWhwMC1EN2dtRGNtT01LNFVrclJSdWd+U1FRPC9hPjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCi0tLQ0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+SSB3b3VsZCBsaWtlIHRvIGluaXRpYXRlIGRpc2N1c3Npb24g Zm9yIGRyYWZ0LWdvZXNzbmVyLWRpc3BhdGNoLWpzb25wYXRoOjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvaWQvZHJhZnQtZ29lc3NuZXItZGlzcGF0Y2gtanNvbnBhdGgtMDAuaHRtbCIg Y2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtZ29lc3NuZXItZGlzcGF0Y2gt anNvbnBhdGgtMDAuaHRtbDwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkl0IHNheXM6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mZ3Q7IFRoaXMgZG9jdW1lbnQgcGlja3Mg dXAgdGhlIHBvcHVsYXIgSlNPTlBhdGggc3BlY2lmaWNhdGlvbiBkYXRlZDwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4mZ3Q7IDIwMDctMDItMjEgYW5kIHByb3ZpZGVzIGEgbW9yZSBub3JtYXRpdmUgZGVm aW5pdGlvbiBmb3IgaXQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZndDsgSXQgaXMgaW50ZW5kZWQg YXMgYSBzdWJtaXNzaW9uIHRvIHRoZSBJRVRGIERJU1BBVENIIFdHLCBpbiBvcmRlciB0bzwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4mZ3Q7IGZpbmQgdGhlIHJpZ2h0IHdheSB0byBjb21wbGV0ZSBzdGFu ZGFyZGl6YXRpb24gb2YgdGhpcyBzcGVjaWZpY2F0aW9uLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4m Z3Q7IEluIGl0cyBjdXJyZW50IHN0YXRlLCBpdCBpcyBhIHN0cmF3bWFuIGRvY3VtZW50IHNob3dp bmcgd2hhdCBuZWVkcyB0bzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mZ3Q7IGJlIGNvdmVyZWQuPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4o Rm9yIHNvbWUgcmVhc29uIHRoZSBhYnN0cmFjdCBsYW5kZWQgaW4gdGhlIENvbnRyaWJ1dGluZyBu b3RlOyB0eXBpY2FsIEludGVybmV0LURyYWZ0IGRlYWRsaW5lIGRheSBib3RjaC4pPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGlzIGlz IGEgd2lkZWx5IGltcGxlbWVudGVkIHNwZWNpZmljYXRpb24gdGhhdCBoYXMgYmVlbiBhcm91bmQg Zm9yIG1vcmUgdGhhbiBhIGRlY2FkZTsgbm93IG1heSBiZSBhIGdvb2Qgb3Bwb3J0dW5pdHkgdG8g ZmluYWxseSBnbyBhaGVhZCBhbmQgdHVybiBpdCBpbnRvIGEgcHJvcGVyIEludGVybmV0IHN0YW5k YXJkcyBkb2N1bWVudC4gJm5ic3A7VGhlIGltbWVkaWF0ZSBjYXVzZSBmb3Igd3JpdGluZyB0aGlz IHVwIG5vdyBpcyB0aGF0DQogc29tZSBJb1QgZGlzY292ZXJ5IHdvcmsgKHNvbWUgb2Ygd2hpY2gg aGFwcGVucyBpbiBXM0MpIGNhbiBtYWtlIGdvb2QgdXNlIG9mIEpTT05QYXRoLiAmbmJzcDtDbGVh cmx5LCB3ZSBhbHJlYWR5IGhhdmUgSlNPTiBQb2ludGVyIChSRkMgNjkwMSkgZm9yIGEgbW9yZSBs aW1pdGVkIHNldCBvZiBhcHBsaWNhdGlvbnM7IHRoZSBzcGVjaWZpY2F0aW9uIHdvdWxkIGRvIGdv b2QgaW4gZGVmaW5pbmcgaG93IHRoZXNlIHR3byBmaXQgdG9nZXRoZXIuPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGVyZSBpcyBubyBh Y3RpdmUgV0cgdGhhdCBpbW1lZGlhdGVseSBmaXRzIHRoaXMgd29yay48L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkV2ZW50dWFsbHkgQ0RE TCBtYXkgcGljayBKU09OUGF0aCB1cCBpbiB0aGUgZm9ybSBvZiBhIHByZWRpY2F0ZSBvcGVyYXRv cjsgdGhpcyBtaWdodCBtYWtlIHRoZSBDQk9SIFdHIHRoZSByaWdodCBncm91cCAod2hpY2ggcHJv YmFibHkgd291bGQgdGhlbiBnbyBhaGVhZCBhbmQgd3JpdGUgdXAgYW5vdGhlciBzcGVjaWZpY2F0 aW9uIHRoYXQgbWFrZXMgSlNPTlBhdGggdXNlZnVsIGZvciBxdWVyeWluZyBDQk9SIGluc3RhbmNl cw0KIHRoYXQgZ28gYmV5b25kIHRoZSBKU09OIGdlbmVyaWMgZGF0YSBtb2RlbCkuPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5SZW9wZW5p bmcgdGhlIEpTT04gV0cgbWF5IGJlIGFub3RoZXIgYXBwcm9hY2gsIGFzIG1heSBiZSBjcmVhdGlu ZyBhIHNob3J0LWxpdmVkIHRhcmdldGVkIFdHLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+UGxlYXNlIGRpc2N1c3MhPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5HcsO8w59lLCBD YXJzdGVuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZndDsgQmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6PC9k aXY+DQo8ZGl2IGNsYXNzPSIiPiZndDsmbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jmd0OyBG cm9tOiA8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiBjbGFzcz0iIj5p bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZndDsgU3Vi amVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1nb2Vzc25lci1kaXNwYXRj aC1qc29ucGF0aC0wMC50eHQ8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jmd0OyBEYXRlOiAyMDIwLTA3 LTEzIGF0IDIyOjA4OjUwIENFU1Q8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jmd0OyBUbzogJnF1b3Q7 U3RlZmFuIEfDtnNzbmVyJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c3RlZmFuLmdvZXNzbmVy QGZoLWRvcnRtdW5kLmRlIiBjbGFzcz0iIj5zdGVmYW4uZ29lc3NuZXJAZmgtZG9ydG11bmQuZGU8 L2E+Jmd0O2RlJmd0OywgJnF1b3Q7U3RlZmFuIEdvc3NuZXImcXVvdDsgJmx0OzxhIGhyZWY9Im1h aWx0bzpzdGVmYW4uZ29lc3NuZXJAZmgtZG9ydG11bmQuZGUiIGNsYXNzPSIiPnN0ZWZhbi5nb2Vz c25lckBmaC1kb3J0bXVuZC5kZTwvYT4mZ3Q7ZGUmZ3Q7LCAmcXVvdDtDYXJzdGVuDQogQm9ybWFu biZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNhYm9AdHppLm9yZyIgY2xhc3M9IiI+Y2Fib0B0 emkub3JnPC9hPiZndDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jmd0OyZuYnNwOzwvZGl2Pg0KPGRp diBjbGFzcz0iIj4mZ3Q7Jm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZndDsgQSBuZXcgdmVy c2lvbiBvZiBJLUQsIGRyYWZ0LWdvZXNzbmVyLWRpc3BhdGNoLWpzb25wYXRoLTAwLnR4dDwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4mZ3Q7IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkg Q2Fyc3RlbiBCb3JtYW5uIGFuZCBwb3N0ZWQgdG8gdGhlPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZn dDsgSUVURiByZXBvc2l0b3J5LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mZ3Q7Jm5ic3A7PC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPiZndDsgTmFtZTo8c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0 eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPiA8L3NwYW4+DQpkcmFmdC1nb2Vzc25lci1kaXNwYXRjaC1q c29ucGF0aDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mZ3Q7IFJldmlzaW9uOjxzcGFuIGNsYXNzPSJB cHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+IDwvc3Bhbj4NCjAwPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPiZndDsgVGl0bGU6PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBz dHlsZT0id2hpdGUtc3BhY2U6cHJlIj4gPC9zcGFuPg0KSlNPTlBhdGggLS0gWFBhdGggZm9yIEpT T048L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jmd0OyBEb2N1bWVudCBkYXRlOjxzcGFuIGNsYXNzPSJB cHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+DQo8L3NwYW4+MjAyMC0wNy0x MjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mZ3Q7IEdyb3VwOjxzcGFuIGNsYXNzPSJBcHBsZS10YWIt c3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+IDwvc3Bhbj4NCkluZGl2aWR1YWwgU3VibWlz c2lvbjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mZ3Q7IFBhZ2VzOjxzcGFuIGNsYXNzPSJBcHBsZS10 YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+IDwvc3Bhbj4NCjE0PC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPiZndDsgVVJMOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1n b2Vzc25lci1kaXNwYXRjaC1qc29ucGF0aC0wMC50eHQiIGNsYXNzPSIiPmh0dHBzOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1nb2Vzc25lci1kaXNwYXRjaC1qc29ucGF0aC0w MC50eHQ8L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZndDsgU3RhdHVzOiAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtZ29lc3NuZXItZGlzcGF0Y2gtanNvbnBhdGgvIiBjbGFzcz0iIj4NCmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWdvZXNzbmVyLWRpc3BhdGNoLWpzb25wYXRoLzwv YT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jmd0OyBIdG1saXplZDogJm5ic3A7ICZuYnNwOyAmbmJz cDsgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdvZXNzbmVyLWRp c3BhdGNoLWpzb25wYXRoLTAwIiBjbGFzcz0iIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1nb2Vzc25lci1kaXNwYXRjaC1qc29ucGF0aC0wMDwvYT48L2Rpdj4NCjxkaXYgY2xh c3M9IiI+Jmd0OyBIdG1saXplZDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1nb2Vzc25lci1kaXNwYXRjaC1q c29ucGF0aCIgY2xhc3M9IiI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1s L2RyYWZ0LWdvZXNzbmVyLWRpc3BhdGNoLWpzb25wYXRoPC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4mZ3Q7Jm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZndDsmbmJzcDs8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+Jmd0OyBBYnN0cmFjdDo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jmd0OyAmbmJzcDsg aW5zZXJ0IGFic3RyYWN0IGhlcmU8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jmd0OyZuYnNwOzwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4mZ3Q7Jm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZndDsmbmJz cDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jmd0OyZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4m Z3Q7IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9t IHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jmd0OyB1bnRpbCB0 aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0 dHA6Ly90b29scy5pZXRmLm9yZyIgY2xhc3M9IiI+DQp0b29scy5pZXRmLm9yZzwvYT4uPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPiZndDsmbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jmd0OyBUaGUg SUVURiBTZWNyZXRhcmlhdDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mZ3Q7Jm5ic3A7PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPiZndDsmbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_C157962012ED4BC09B1D9A2D0AB147F2vmwarecom_-- From nobody Tue Jul 21 02:08:13 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D3D3A171D for ; Tue, 21 Jul 2020 02:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=vmware.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 eEllYI2-KmHE for ; Tue, 21 Jul 2020 02:08:10 -0700 (PDT) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2088.outbound.protection.outlook.com [40.107.93.88]) (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 A12623A171B for ; Tue, 21 Jul 2020 02:08:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hflFsJix5D0xlNqHIQk0r4qa9XbhQUdx6XolW1MbjWiZGqviV8coqttA0W4RvnU8cGK5hJM5PYNq2mHetOEIjwO9xknCzbSjMEqwmNqaJGahLsJcXjK3fVYFn4szpcwe6M6yAHMf8PLFreXY6ob99oriEWB77LbPnt4lKOP89Q02X79xQfHgZYpFY2bKbqVoAl87tcRu2aaPGfBxaUs/ddmPcxxEFRB7TvfmWJFHRzbbm3b5NPZRVvA3yIDPo9AOY8SShi4O99DO8XfjgqcIqzSjbqtb1oODFSL/nUOu4SC3/Ljd/QFdVlXeHsxjILxZUkOJrPKSHFraQWukyAmTbw== 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=r92vsacUH7I/TxBiP7kg4BESke+1EaWFgU9ezYuNl0c=; b=YieZ0UznBvEE2+EYtBF3OB+OpPJO77CjQpaInRddCYrVyW/9gapUF6SYcd6Jl4tHPJ80KsksuuVMT3KYqblNeWYm7ALVl7gAL94zDKXNAPu4q9DGQ97phycb2ynxE9Clu3/3RM1i5Qf1mhtNE7fHVEsyuVoFutNr46pJx/qDp9beNyhFRFjw32ya5JU0Z2KZbHJhWi906zENGbXTHnZ09Q3BJBRbj2mkp5oZzh6OTRENeDdHcyQ0k+OeiKrXWtg3cK9ENeMJLwBudqGinXS+F1tO6Ab3dVNHah+oX1J1dGTafmn2u4RNmfRoXbPsAtCnItgNAe70VhDgvpE0fnOtmQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=vmware.com; dmarc=pass action=none header.from=vmware.com; dkim=pass header.d=vmware.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vmware.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=r92vsacUH7I/TxBiP7kg4BESke+1EaWFgU9ezYuNl0c=; b=O0Q/y+5AofKPOzz0m6oRa9cL4zsFsFvSe/95w5SA3qpHfmyznTaIg6evWRqHk3Xb5qf9xjAyIk6Fx4TOXZpVIIYVnWDQJE9xQT6oNCBjc0w+hO4EjJ3l0l/IGo1kYpiR2/r2WXExBWvBUqom5Oh+EloHYwjfCA4jNDdcWqMWhuw= Received: from DM5PR0501MB3766.namprd05.prod.outlook.com (2603:10b6:4:7c::29) by DM5PR05MB3033.namprd05.prod.outlook.com (2603:10b6:3:56::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.14; Tue, 21 Jul 2020 09:08:08 +0000 Received: from DM5PR0501MB3766.namprd05.prod.outlook.com ([fe80::e93d:dbc3:e9ce:7bc8]) by DM5PR0501MB3766.namprd05.prod.outlook.com ([fe80::e93d:dbc3:e9ce:7bc8%3]) with mapi id 15.20.3216.015; Tue, 21 Jul 2020 09:08:08 +0000 From: Glyn Normington To: "dispatch@ietf.org" Thread-Topic: [dispatch] dispatch - Requested session has been scheduled for IETF 108 Thread-Index: AQHWXz5z9ZnriELJiki4S9Ik3XFDoQ== Date: Tue, 21 Jul 2020 09:08:07 +0000 Message-ID: <5F56AAF1-A347-4CDD-A913-F948EB1DF6EB@vmware.com> 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=vmware.com; x-originating-ip: [146.199.144.111] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 14cf3f88-2b6f-4e36-6b43-08d82d5595c2 x-ms-traffictypediagnostic: DM5PR05MB3033: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: OG8CB3nRtUH+/Sr3dICv+W9hxC9KVmIjJSsi33hazSxKUBedhD1NpDbsg6vGVZv0Em7ASHHLweLttq4ulBOWJzkgHHNsvBkA8q3X79QFdO50ADJbXVfK65gz8+XWxIzMtbsW1xzLkWwlpkSxpV3o05j+fGgnUk5AKssXHbcYelm/twV+pWSxoZxW6BoTwhvTknPi3hYuz54vXQeAghjhVOJWc8qZmqn9eSQz/OXhDBYlaVMvO05C6D87pTDJfrMkvcZF83C4Ke6I809ojXWr/jd7YJ9nTaQ8toVug1OnAxgNkcnxuAsams9pCzvevjVf/N9xaI9fVhrCVJZ2YqSrbLP5E9RLKrlIpqH1H/1/VTOForfkEs+XwrSrFagDqMINVqBYWpyU587PhmhgiYfJHQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR0501MB3766.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(346002)(376002)(39860400002)(366004)(76116006)(91956017)(83380400001)(6916009)(71200400001)(86362001)(26005)(66556008)(66446008)(5660300002)(36756003)(2616005)(478600001)(166002)(966005)(8936002)(6506007)(6486002)(2906002)(66476007)(33656002)(186003)(64756008)(6512007)(8676002)(66946007)(316002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: E8LQgMfmFAb4coP+tEXJ4RNZRZW83uXL6iMSn9Gg2qW8iBFVJHWPY5s/UE9jYg/fYQsL3UiOQ+HNK7FPJQ8G0E2QA7H1mFScvh6tCeWTtpfkt/Bj4TbRSm+fFZrszwdTMwoIKXlfqcIncBRn9boJuKTMGgps2cuOYh+roCBfFu3U+wTqrtcg7YRDweECautuAJ8i80CI+duodrJATWd6Wm1xxpYIFnjKBcyE8FWnHxvOz+aMIEs+OrUCTzzwXWOCOJ8hR2lacA9GQWTfR7gMRRhY9eXCdTGJ171GOfiw8kyBPmZOacr7/z6RDd8ZdjSxPvSfHeNq42jVOrrWY3TTmkwxbnjnN0h+glkv3liYxPml50NrYG45I65edgaMXo8NYyYUpPsUlKFJ6W5NdiwVdsdYRloko47C/Pv4dL3jVGakPYsmglDX7fzKtoH12SlgYNs+kWyUkqEH7kyXgkhY2csMkP4tGweUcEUsqLexGb7cje0SyIPq5vZ3wSyXZmiT x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_5F56AAF1A3474CDDA913F948EB1DF6EBvmwarecom_" MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM5PR0501MB3766.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 14cf3f88-2b6f-4e36-6b43-08d82d5595c2 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2020 09:08:07.9522 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 3E1XX4XcdiHnnkUi3PR0bANjKXfSaIuvt0MZ6DZ1S4o3SmktW6SoA2IGEOKnlJR1tkCHKTCAPxhHY08xGlDWbA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3033 Archived-At: Subject: Re: [dispatch] dispatch - Requested session has been scheduled for IETF 108 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 09:08:13 -0000 --_000_5F56AAF1A3474CDDA913F948EB1DF6EBvmwarecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBpbnRlcmVzdGVkIGluIGpvaW5pbmcgdGhlIHNlc3Npb24gYmVsb3csIGJ1dCBJ4oCZbSBu b3QgY2xlYXIgd2hldGhlciBpdCBpcyBvbiBqYWJiZXIgb25seSBvciB3aGV0aGVyIHRoZXJlIHdp bGwgYWxzbyBiZSBhIHZpZGVvL2F1ZGlvIG1lZXRpbmcgYW5kIGlmIHNvLCBob3cgdG8gb2J0YWlu IHRoZSBtZWV0aW5nIGxvZ2luIGluZm9ybWF0aW9uLiBQbGVhc2UgY291bGQgc29tZW9uZSBhZHZp c2UuDQoNClRoYW5rcywNCkdseW4NCg0K4oCUDQoNCkRlYXIgUGF0cmljayBNY01hbnVzLA0KDQpU aGUgc2Vzc2lvbihzKSB0aGF0IHlvdSBoYXZlIHJlcXVlc3RlZCBoYXZlIGJlZW4gc2NoZWR1bGVk Lg0KQmVsb3cgaXMgdGhlIHNjaGVkdWxlZCBzZXNzaW9uIGluZm9ybWF0aW9uIGZvbGxvd2VkIGJ5 DQp0aGUgb3JpZ2luYWwgcmVxdWVzdC4NCg0KDQogICAgZGlzcGF0Y2ggU2Vzc2lvbiAxICgxOjQw IHJlcXVlc3RlZCkNCiAgICBNb25kYXksIDI3IEp1bHkgMjAyMCwgU2Vzc2lvbiBJIDExMDAtMTI0 MA0KICAgIFJvb20gTmFtZTogUm9vbSAxIHNpemU6IDENCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KU3BlY2lhbCBOb3RlOiBKb2ludCB3aXRoIEFS VEFSRUENCg0KaUNhbGVuZGFyOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcv MTA4L3Nlc3Npb25zL2Rpc3BhdGNoLmljcw0KDQpSZXF1ZXN0IEluZm9ybWF0aW9uOg0KDQoNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K V29ya2luZyBHcm91cCBOYW1lOiBEaXNwYXRjaA0KQXJlYSBOYW1lOiBBcHBsaWNhdGlvbnMgYW5k IFJlYWwtVGltZSBBcmVhDQpTZXNzaW9uIFJlcXVlc3RlcjogUGF0cmljayBNY01hbnVzDQoNCg0K TnVtYmVyIG9mIFNlc3Npb25zOiAxDQpMZW5ndGggb2YgU2Vzc2lvbihzKTogIDEwMCBNaW51dGVz DQpOdW1iZXIgb2YgQXR0ZW5kZWVzOiA5MA0KQ29uZmxpY3RzIHRvIEF2b2lkOg0KIENoYWlyIENv bmZsaWN0OiBydW0gaWNlIHN0aXIgc2lwY29yZSBtbXVzaWMgZWNyaXQgYXZ0Y29yZSBjZnJnIHF1 aWMgaHR0cGJpcyBhZGQNCiBUZWNobm9sb2d5IE92ZXJsYXA6IHBlcmMgY2VsbGFyIGNhcHBvcnQg ZG1hcmMgam1hcCB1dGEgcm1jYXQgZXh0cmEgY29yZSBvcHNhcmVhIHRzdmFyZWEgdHN2d2cgdHJh bSBzZWNkaXNwYXRjaA0KIEtleSBQYXJ0aWNpcGFudCBDb25mbGljdDogYWNtZSBjb3NlIGRwcml2 ZSBsYW1wcyB0bHMgbWxzDQoNCg0KDQoNCg0KUGVvcGxlIHdobyBtdXN0IGJlIHByZXNlbnQ6DQog IEJhcnJ5IExlaWJhDQogIEJlbiBDYW1wYmVsbA0KICBNdXJyYXkgS3VjaGVyYXd5DQogIFBhdHJp Y2sgTWNNYW51cw0KDQpSZXNvdXJjZXMgUmVxdWVzdGVkOg0KDQpTcGVjaWFsIFJlcXVlc3RzOg0K ICBQbGVhc2Ugc2NoZWR1bGUgaW4gdGhlIDFzdCBzbG90IG9uIE1vbmRheSBtb3JuaW5nLCBsaXN0 IHRoZSBtZWV0aW5nIGFzIGNvdXBsZWQgd2l0aCBBUlRBUkVBLiBQbGVhc2UgYXZvaWQgY29uZmxp Y3RzIHdpdGggb3RoZXIgQVJUIGFyZWEgV0dzIGFuZCBCb0ZzLCBvdGhlciBhcmVhIG1lZXRpbmdz LCBhbmQgQm9mcy4uDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCg0K --_000_5F56AAF1A3474CDDA913F948EB1DF6EBvmwarecom_ Content-Type: text/html; charset="utf-8" Content-ID: <56460FC61294D54E9E77E031F2A43D9C@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkkgYW0gaW50ZXJlc3RlZCBpbiBqb2luaW5nIHRo ZSBzZXNzaW9uIGJlbG93LCBidXQgSeKAmW0gbm90IGNsZWFyIHdoZXRoZXIgaXQgaXMgb24gamFi YmVyIG9ubHkgb3Igd2hldGhlciB0aGVyZSB3aWxsIGFsc28gYmUgYSB2aWRlby9hdWRpbyBtZWV0 aW5nIGFuZCBpZiBzbywgaG93IHRvIG9idGFpbiB0aGUgbWVldGluZyBsb2dpbiBpbmZvcm1hdGlv bi4gUGxlYXNlIGNvdWxkIHNvbWVvbmUgYWR2aXNlLg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhhbmtzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5H bHluPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+4oCUPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHByZSBjbGFzcz0id29yZHdy YXAiIHN0eWxlPSJib3gtc2l6aW5nOiBib3JkZXItYm94OyBmb250LWZhbWlseTogU0ZNb25vLVJl Z3VsYXIsIE1lbmxvLCBNb25hY28sIENvbnNvbGFzLCAmcXVvdDtMaWJlcmF0aW9uIE1vbm8mcXVv dDssICZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCBtb25vc3BhY2U7IGZvbnQtc2l6ZTogMTIuMjVw eDsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAxcmVtOyBvdmVyZmxvdzogYXV0bzsg Y29sb3I6IHJnYigzMywgMzcsIDQxKTsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyBvdmVyZmxvdy13 cmFwOiBub3JtYWw7IHdvcmQtYnJlYWs6IG5vcm1hbDsgcGFkZGluZzogMHB4OyBmb250LXZhcmlh bnQtbGlnYXR1cmVzOiBub3JtYWw7IG9ycGhhbnM6IDI7IHdpZG93czogMjsgYmFja2dyb3VuZC1j b2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+RGVhciBQYXRyaWNrIE1jTWFudXMsDQoNClRoZSBz ZXNzaW9uKHMpIHRoYXQgeW91IGhhdmUgcmVxdWVzdGVkIGhhdmUgYmVlbiBzY2hlZHVsZWQuDQpC ZWxvdyBpcyB0aGUgc2NoZWR1bGVkIHNlc3Npb24gaW5mb3JtYXRpb24gZm9sbG93ZWQgYnkNCnRo ZSBvcmlnaW5hbCByZXF1ZXN0LiANCg0KDQogICAgZGlzcGF0Y2ggU2Vzc2lvbiAxICgxOjQwIHJl cXVlc3RlZCkNCiAgICBNb25kYXksIDI3IEp1bHkgMjAyMCwgU2Vzc2lvbiBJIDExMDAtMTI0MA0K ICAgIFJvb20gTmFtZTogUm9vbSAxIHNpemU6IDENCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KU3BlY2lhbCBOb3RlOiBKb2ludCB3aXRoIEFSVEFS RUENCg0KaUNhbGVuZGFyOiA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21l ZXRpbmcvMTA4L3Nlc3Npb25zL2Rpc3BhdGNoLmljcyIgcmVsPSJub2ZvbGxvdyIgc3R5bGU9ImJv eC1zaXppbmc6IGJvcmRlci1ib3g7IGNvbG9yOiByZ2IoNTEsIDEyMiwgMTgzKTsgdGV4dC1kZWNv cmF0aW9uOiBub25lOyBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsiIGNsYXNzPSIiPmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDgvc2Vzc2lvbnMvZGlzcGF0Y2gu aWNzPC9hPg0KDQpSZXF1ZXN0IEluZm9ybWF0aW9uOg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KV29ya2luZyBHcm91cCBOYW1l OiBEaXNwYXRjaA0KQXJlYSBOYW1lOiBBcHBsaWNhdGlvbnMgYW5kIFJlYWwtVGltZSBBcmVhDQpT ZXNzaW9uIFJlcXVlc3RlcjogUGF0cmljayBNY01hbnVzDQoNCg0KTnVtYmVyIG9mIFNlc3Npb25z OiAxDQpMZW5ndGggb2YgU2Vzc2lvbihzKTogIDEwMCBNaW51dGVzDQpOdW1iZXIgb2YgQXR0ZW5k ZWVzOiA5MA0KQ29uZmxpY3RzIHRvIEF2b2lkOiANCiBDaGFpciBDb25mbGljdDogcnVtIGljZSBz dGlyIHNpcGNvcmUgbW11c2ljIGVjcml0IGF2dGNvcmUgY2ZyZyBxdWljIGh0dHBiaXMgYWRkDQog VGVjaG5vbG9neSBPdmVybGFwOiBwZXJjIGNlbGxhciBjYXBwb3J0IGRtYXJjIGptYXAgdXRhIHJt Y2F0IGV4dHJhIGNvcmUgb3BzYXJlYSB0c3ZhcmVhIHRzdndnIHRyYW0gc2VjZGlzcGF0Y2gNCiBL ZXkgUGFydGljaXBhbnQgQ29uZmxpY3Q6IGFjbWUgY29zZSBkcHJpdmUgbGFtcHMgdGxzIG1scw0K DQoNCg0KDQoNClBlb3BsZSB3aG8gbXVzdCBiZSBwcmVzZW50Og0KICBCYXJyeSBMZWliYQ0KICBC ZW4gQ2FtcGJlbGwNCiAgTXVycmF5IEt1Y2hlcmF3eQ0KICBQYXRyaWNrIE1jTWFudXMNCg0KUmVz b3VyY2VzIFJlcXVlc3RlZDoNCg0KU3BlY2lhbCBSZXF1ZXN0czoNCiAgUGxlYXNlIHNjaGVkdWxl IGluIHRoZSAxc3Qgc2xvdCBvbiBNb25kYXkgbW9ybmluZywgbGlzdCB0aGUgbWVldGluZyBhcyBj b3VwbGVkIHdpdGggQVJUQVJFQS4gUGxlYXNlIGF2b2lkIGNvbmZsaWN0cyB3aXRoIG90aGVyIEFS VCBhcmVhIFdHcyBhbmQgQm9Gcywgb3RoZXIgYXJlYSBtZWV0aW5ncywgYW5kIEJvZnMuLg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9w cmU+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5F56AAF1A3474CDDA913F948EB1DF6EBvmwarecom_-- From nobody Tue Jul 21 02:58:32 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6133A07BB for ; Tue, 21 Jul 2020 02:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 AFBc0ALN5C0a for ; Tue, 21 Jul 2020 02:58:27 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5913B3A07B8 for ; Tue, 21 Jul 2020 02:58:27 -0700 (PDT) Received: from [172.16.42.100] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4B9vDd2nD6zyqk; Tue, 21 Jul 2020 11:58:25 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <5F56AAF1-A347-4CDD-A913-F948EB1DF6EB@vmware.com> Date: Tue, 21 Jul 2020 11:58:23 +0200 Cc: "dispatch@ietf.org" X-Mao-Original-Outgoing-Id: 617018303.8707809-a42fbf68da5c35313de2daa3ddc28bc4 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5F56AAF1-A347-4CDD-A913-F948EB1DF6EB@vmware.com> To: Glyn Normington X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [dispatch] dispatch - Requested session has been scheduled for IETF 108 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 09:58:30 -0000 Hi Glyn, The dispatch WG meeting is part of IETF108, for which you can find = details at: n https://www.ietf.org/how/meetings/108/ In short, full participation is possible (via the Web conferencing tool = meetecho) if you register. Registration fees apply (for a single day or = for the whole IETF); there is also a fee waiver program in case the fee = "represents a barrier to participation=E2=80=9D: https://www.ietf.org/how/meetings/108/108-registration-fee-waiver/ (There is also a need to obtain a freely available =E2=80=9Cdatatracker=E2= =80=9D account, which I would advise anyway if you want to track any = standardization activity resulting from the result of the dispatch WG = meeting.) IETF used to have a low-barrier remote participation concept to = complement the physical meetings; unfortunately as the latter became = impossible, we now need to put meeting fees on the remote participation = instead (but see also the fee waiver program linked above). In any case, recordings of the meeting will be up on YouTube typically = within less than a week, so if the hassle and the early time get in the = way of your participation, you can see there in detail what transpired. = Your contribution to the dispatch mailing list already was very useful = input, by the way. I=E2=80=99m really looking forward to your participation in JSONPath = standardization, and I hope the immense overhead for this 20-minute slot = will not be detracting from that. Gr=C3=BC=C3=9Fe, Carsten > On 2020-07-21, at 11:08, Glyn Normington = wrote: >=20 > I am interested in joining the session below, but I=E2=80=99m not = clear whether it is on jabber only or whether there will also be a = video/audio meeting and if so, how to obtain the meeting login = information. Please could someone advise. >=20 > Thanks, > Glyn >=20 > =E2=80=94 > Dear Patrick McManus, >=20 > The session(s) that you have requested have been scheduled. > Below is the scheduled session information followed by > the original request.=20 >=20 >=20 > dispatch Session 1 (1:40 requested) > Monday, 27 July 2020, Session I 1100-1240 > Room Name: Room 1 size: 1 > --------------------------------------------- >=20 > Special Note: Joint with ARTAREA >=20 > iCalendar:=20 > https://datatracker.ietf.org/meeting/108/sessions/dispatch.ics >=20 >=20 > Request Information: >=20 >=20 > --------------------------------------------------------- > Working Group Name: Dispatch > Area Name: Applications and Real-Time Area > Session Requester: Patrick McManus >=20 >=20 > Number of Sessions: 1 > Length of Session(s): 100 Minutes > Number of Attendees: 90 > Conflicts to Avoid:=20 > Chair Conflict: rum ice stir sipcore mmusic ecrit avtcore cfrg quic = httpbis add > Technology Overlap: perc cellar capport dmarc jmap uta rmcat extra = core opsarea tsvarea tsvwg tram secdispatch > Key Participant Conflict: acme cose dprive lamps tls mls >=20 >=20 >=20 >=20 >=20 > People who must be present: > Barry Leiba > Ben Campbell > Murray Kucherawy > Patrick McManus >=20 > Resources Requested: >=20 > Special Requests: > Please schedule in the 1st slot on Monday morning, list the meeting = as coupled with ARTAREA. Please avoid conflicts with other ART area WGs = and BoFs, other area meetings, and Bofs.. > --------------------------------------------------------- >=20 >=20 From nobody Tue Jul 21 08:17:37 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C093A0A4A for ; Tue, 21 Jul 2020 08:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_TRY_3LD=1.999] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ispirata.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 c2a9ek21UPAA for ; Tue, 21 Jul 2020 08:17:33 -0700 (PDT) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 3D8FF3A0A3F for ; Tue, 21 Jul 2020 08:17:33 -0700 (PDT) Received: by mail-wm1-x332.google.com with SMTP id 22so3217840wmg.1 for ; Tue, 21 Jul 2020 08:17:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ispirata.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=NkqBT5ddPkOmnmAzL/fvj6t+kj2dQvBSD6gHHsFXMVU=; b=n3tvNVv7nbY6N6LPWVjVbqFCXQ3Tfhom4krEF6NWz7w9GgRkjtHYJirnqa8doda0BN G8ZVTyOppWzLesNJVPgFvAJFkToCo/t8LHI15QZhcA6l06kLKfFuM2bxz8mp0h0I9PPU c3Ke4xl2iW++6fTs/yHTu71eQL9WEIX6dmZ3bffKPMwTEyWFkvVIUwrZsa72mGkuQvh0 WqehkwLghPMItSuPNTnRWYG5tTykvCsiFstNbk+ARa3+LIPHpUzJu+bb/Ni3wMnsirvO SPsT8HSnxPBEEPImWsEe0VHRMjeoBQhYQNJj5AfRhKyUWw8+GOY+H4svY12At3/SCqW+ KhyQ== 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=NkqBT5ddPkOmnmAzL/fvj6t+kj2dQvBSD6gHHsFXMVU=; b=mPioF8xP36STMo/oP1K5TG6hKRg1KMitq6QjNtZb8q2ThmaMjN5fhVPlMRELmugdsf zhC3BqVrjqYdhRAMb/Nvq7qd2JmhBv0KBP7NriS7tJhntPJu5XQKsuq2VF6M5P4Nr5ro lcLHyxW+l/0Kg1Cr7l5OEji9uspCRX9Iy3/lr2LDyJccAjrFlXYN70O0fNNAb3jJsYWb UG8MDvTsH5h11I77lX5LYfBRjIVHn4vLojJMt3DBwj9jBEGrX/r3Rwlmju9fNGYonk1W kXaNI1+wASyoCAoVsDgft2G0R+XxCBIDSpUJ0kT/geXatfHeS/FbJ6zuSlmahwCQjg+V hQWQ== X-Gm-Message-State: AOAM531wLsOq2Uv5LpS9sfYFuaQ/dcHaks6ULBxMnkduYZn7/2Y7Fbcx f3qfFqkrOxSXEKA+azsnw1HP1KFL0bWAW8K8CzVr60hsPz30vQ== X-Google-Smtp-Source: ABdhPJxwTCJhmqqQ+ubyWm9Mwn36mIzkl4le1KmVuvR+FkKgzoyGlqk2e+1/7CH2WWWEeG2YAMCsem4PLXK3Gz/idyg= X-Received: by 2002:a7b:c7d2:: with SMTP id z18mr4590054wmk.149.1595344651336; Tue, 21 Jul 2020 08:17:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Davide Bettio Date: Tue, 21 Jul 2020 17:17:00 +0200 Message-ID: To: "dispatch@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dispatch] draft-goessner-dispatch-jsonpath-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 15:17:35 -0000 Hello, I am the author of a JSONPath implementation [0], and I am participating in the community effort [1] that Glyn mentioned. I really appreciate the clarity of G=C3=B6ssner's article [2] (and that was really useful in understanding JSONPath), however it quickly turned into a nightmare when I started to work on an implementation, therefore I would love to raise some points that I believe they should be properly addressed. 1. There are > 35 implementations out there that are used by a huge number of users (e.g. Kubernetes, Oracle Database, etc...). A standard should take account of this and it should be as compatible as possible with them, otherwise we would get a standard with no users. Moreover there is a lot of fragmentation, so a consensus oriented approach should be taken [3]. 2. Most implementations are supersets of G=C3=B6ssner's original article, e.g. `key` instead of `$.key` is widely accepted (even by G=C3=B6ssner's implementations), but it is not part of the original article. In my opinion, I think we should support them since they are de facto supported [4]. 3. G=C3=B6ssner's article lacks a lot of detail useful for an unambiguous specification, for instance the following are some of the unspecified points: a) negative subscript operator indices are widely supported but there is no explicit mention for them in G=C3=B6ssner's article b) negative integers in slice operator are not explicitly mentioned c) there is no specification for valid dot notation identifiers, therefore some implementations accept `$.foo-bar`, while others do not (same thing for `$.65`, `$.42foo`, $.=E5=B1=AC=E6=80=A7, `$.-foo` or `$.foo-`). d) It is not clear if `$` is a valid path or not. e) It is not clear how to handle `$.foo[010]`. There are many other similar open issues. 4. There is a huge lack of information about supported filtering boolean expressions. e.g. which of the following is supported: `$.store.book[?(@.price < 10)].title`, `$.store.book[?(@.price < @.foo)].title`, `$.store.book[?(@.price / 10 < @.foo)].title`? Are regexps supported? etc... 5. G=C3=B6ssner's article mentions support for scripting, however this feature might be bad from a security point of view, it is not portable across different implementations and there isn't any set of minimum supported features. Furthermore `$[(@.length-1)]` is required if `$.foo[-1]` is not accepted as a valid path. (Opinion: I believe that only a limited set of scripting expressions, such as length, should be supported for backward compatibility). 6. Opinion: I think that any JSONPath implementation should also support JSONPointer, since it is trivial to implement. At our company (Ispirata) we are writing software that allows users to use JSONPath in their data processing pipelines, therefore long term stability is a fundamental requirement for us. I think that with a reasonable amount of work it will be possible to write a standard that takes in account existing implementations, and I would like to be involved in the discussion / review / writing. Regards, Davide Bettio. [0]: https://github.com/ispirata/exjsonpath [1]: https://github.com/jsonpath-standard/internet-draft [2]: https://goessner.net/articles/JsonPath/ [3]: https://cburgmer.github.io/json-path-comparison/ [4]: https://cburgmer.github.io/json-path-comparison/results/dot_notation_w= ithout_root.html Il giorno ven 17 lug 2020 alle ore 18:19 Glyn Normington ha scritto: > > Several authors and maintainers of JSONPath implementations, including my= self, started to gather in June this year to collaborate on an Internet Dra= ft for JSONPath, so I am delighted to see the post below. > > Our approach so far has been informed by Christoph Bergmer's JSONPath imp= lementation comparison project ([1]) and its computed consensus. We are wor= king in the open in a GitHub repository ([2]). See the latest pull request = text ([3]) to get an idea of our approach. We also have a slack workspace w= hich anyone is welcome to join ([4]). > > I look forward to a suitable WG being established so that we can collabor= ate together. > > Regards, > Glyn > > [1] https://cburgmer.github.io/json-path-comparison/ > [2] https://github.com/jsonpath-standard/internet-draft > [3] https://glyn.github.io/internet-draft/ > [4] https://join.slack.com/t/jsonpath-standard/shared_invite/zt-fp521hp0-= D7gmDcmOMK4UkrRRug~SQQ > > --- > I would like to initiate discussion for draft-goessner-dispatch-jsonpath: > > https://www.ietf.org/id/draft-goessner-dispatch-jsonpath-00.html > > It says: > > > This document picks up the popular JSONPath specification dated > > 2007-02-21 and provides a more normative definition for it. > > It is intended as a submission to the IETF DISPATCH WG, in order to > > find the right way to complete standardization of this specification. > > In its current state, it is a strawman document showing what needs to > > be covered. > > (For some reason the abstract landed in the Contributing note; typical In= ternet-Draft deadline day botch.) > > This is a widely implemented specification that has been around for more = than a decade; now may be a good opportunity to finally go ahead and turn i= t into a proper Internet standards document. The immediate cause for writi= ng this up now is that some IoT discovery work (some of which happens in W3= C) can make good use of JSONPath. Clearly, we already have JSON Pointer (R= FC 6901) for a more limited set of applications; the specification would do= good in defining how these two fit together. > > There is no active WG that immediately fits this work. > > Eventually CDDL may pick JSONPath up in the form of a predicate operator;= this might make the CBOR WG the right group (which probably would then go = ahead and write up another specification that makes JSONPath useful for que= rying CBOR instances that go beyond the JSON generic data model). > > Reopening the JSON WG may be another approach, as may be creating a short= -lived targeted WG. > > Please discuss! > > Gr=C3=BC=C3=9Fe, Carsten > > > > > Begin forwarded message: > > > > From: internet-drafts@ietf.org > > Subject: New Version Notification for draft-goessner-dispatch-jsonpath-= 00.txt > > Date: 2020-07-13 at 22:08:50 CEST > > To: "Stefan G=C3=B6ssner" de>, "Stefan = Gossner" de>, "Carsten Bormann" > > > > > > A new version of I-D, draft-goessner-dispatch-jsonpath-00.txt > > has been successfully submitted by Carsten Bormann and posted to the > > IETF repository. > > > > Name: draft-goessner-dispatch-jsonpath > > Revision: 00 > > Title: JSONPath -- XPath for JSON > > Document date: 2020-07-12 > > Group: Individual Submission > > Pages: 14 > > URL: https://www.ietf.org/internet-drafts/draft-goessner-dis= patch-jsonpath-00.txt > > Status: https://datatracker.ietf.org/doc/draft-goessner-dispatc= h-jsonpath/ > > Htmlized: https://tools.ietf.org/html/draft-goessner-dispatch-jso= npath-00 > > Htmlized: https://datatracker.ietf.org/doc/html/draft-goessner-di= spatch-jsonpath > > > > > > Abstract: > > insert abstract here > > > > > > > > > > Please note that it may take a couple of minutes from the time of submi= ssion > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Thu Jul 23 20:26:06 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB6A3A0848 for ; Thu, 23 Jul 2020 20:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 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, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 laJktX2njT-u for ; Thu, 23 Jul 2020 20:26:02 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 9B4D33A085B for ; Thu, 23 Jul 2020 20:26:02 -0700 (PDT) Received: from bens-macbook.lan (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 06O3Pv7q052350 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 23 Jul 2020 22:25:58 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1595561159; bh=ZfABXUkmrp8ryVcd92q15g2rVd3j0DxPNwzJoVUpHYs=; h=From:Subject:Date:Cc:To; b=kXxaWsIEiyIl+MQKbcVMosC7H2+SV8z5Kwhx8udtUbYU8CczZmxx/92nHAQlWeuEM EWdqfVlEeuBPng2MkEeatkfjF8dQNLzUrF4UM2h5IjOVblfL0Qfp5XfJmlC7Yl056v mY4PajYTvLm4UHpuJ6A+olf6l+8D7HRS/rOe5tVk= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be bens-macbook.lan From: Ben Campbell Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Message-Id: <8851CBDC-53E8-4D06-8F4C-9B7546E7F2C3@nostrum.com> Date: Thu, 23 Jul 2020 22:25:50 -0500 Cc: Patrick McManus To: DISPATCH WG X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [dispatch] Note Takers and Jabber Scribe X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 03:26:04 -0000 Hi All, We need volunteers to serve as note takers and jabber scribe for = Mondat=E2=80=99s meeting. We need at least one note-taker, but two would = be better. For notes, we need to capture decisions and action items. A play-by-play = transcript is not necessary (but we won=E2=80=99t turn it away if you = like to do that sort of thing.) The jabber scribe role may be a little different than usual. If = experience from IETF107 holds, there will be substantive conversations = in the jabber room/Meetecho chat. We=E2=80=99d like the jabber scribe to = consider whether those conversations should come to the audio channel, = and either bring them or encourage other jabber participants to do so. Volunteers will receive our undying gratitude. Thanks! Ben.= From nobody Thu Jul 23 20:38:58 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 554513A095E for ; Thu, 23 Jul 2020 20:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 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, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 tvg_m1H9jlPK for ; Thu, 23 Jul 2020 20:38:56 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 161E33A0953 for ; Thu, 23 Jul 2020 20:38:55 -0700 (PDT) Received: from bens-macbook.lan (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 06O3cpno057030 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 23 Jul 2020 22:38:52 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1595561933; bh=z8MvDe32VSiO3PCmbX6xRWp3x/Dyf5gTF9vb76GYZoU=; h=From:Subject:Date:Cc:To; b=rWl9Wrq6dQDuphqy0FC61fr8VcTU5qLGk/73MaX/d6eCHZF0rJTGo6TnNMWOIB9fl Zqn9u4dCQv0EaWjuKuZqrKIoSjSulHiJgpuNqRq1qrrEK9O3abM8qFnYfcLT092kyg wi5BC2nNuLPIqLI5f+gPswPtWKgl/fSInMMLmP0U= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be bens-macbook.lan From: Ben Campbell Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Message-Id: Date: Thu, 23 Jul 2020 22:38:45 -0500 Cc: Patrick McManus To: DISPATCH WG X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [dispatch] DISPATCH Meeting Details X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 03:38:57 -0000 Hi Everyone, The IETF108 DISPATCH meeting will occur over Meetecho from 1100-1240 UTC = on Monday, July 27. The MeetEcho session will open 15 min before start = time; please try to connect a few minutes early so we can start on time. Here=E2=80=99s some meeting links: Meeting Agenda: = https://www.ietf.org/proceedings/108/agenda/agenda-108-dispatch-02 Meetecho session: = https://meetings.conf.meetecho.com/ietf108/?group=3Ddispatch&short=3D&item= =3D1 CodiMD session (for note taking; replaces Etherpad): = https://codimd.ietf.org/notes-ietf-108-dispatch Jabber room: xmpp:dispatch@jabber.ietf.org?join (Note that the jabber = chat is mirrored in Meetecho) Audio Stream: http://mp3.conf.meetecho.com/ietf/ietf1081.m3u Thanks! Ben. From nobody Thu Jul 23 20:42:07 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB443A098D for ; Thu, 23 Jul 2020 20:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 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, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 nJZTkEy_EaXz for ; Thu, 23 Jul 2020 20:42:04 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 5C7723A098C for ; Thu, 23 Jul 2020 20:42:04 -0700 (PDT) Received: from bens-macbook.lan (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 06O3g2qU058296 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 23 Jul 2020 22:42:03 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1595562123; bh=6WEFpVarg/YxXokmbjrthskCKexLouMhd9kS+aDwkaE=; h=From:Subject:References:To:Date; b=IUuhbK898iS04W3x7/UwdbayAE5LyYwDH8rfEH6NSlHR74RpPhFktH+4zbVJvoSmB mLvDnvsxOszNM4oPMn8aFnlPK1RafV8U7GXpRTLk+1/D8l9EhktiyFyQu0ORmF8iaj 4x5BBvd0YfyGTp9QcSCsynJb45Jj/Ww/7XqYj31c= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be bens-macbook.lan From: Ben Campbell Content-Type: multipart/alternative; boundary="Apple-Mail=_447936C4-F88C-4B77-B82D-EEF140EE0437" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Message-Id: References: <7D754936-8681-4CB4-9A3F-7E11F3B32CA1@ietf.org> To: DISPATCH WG Date: Thu, 23 Jul 2020 22:41:55 -0500 X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [dispatch] Meetecho Resources X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 03:42:06 -0000 --Apple-Mail=_447936C4-F88C-4B77-B82D-EEF140EE0437 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Here are some helpful Meetecho resources from Greg Wood. I suggest = everyone read at least the participant guide enough in advance of the = meeting so you can make sure your local setup works. Thanks! Ben. > Begin forwarded message: >=20 > From: Greg Wood > Subject: IETF 108 Online session chair resources and information > Date: July 23, 2020 at 10:15:15 AM CDT > To: wgchairs@ietf.org >=20 > Hello, >=20 > Thanks to everyone who was able to join and provide feedback during = the Meetecho testing sessions over the past week. >=20 > Especially if you participated in an early testing session, you might = find these resources useful as they have been updated with new = information in the last few days. >=20 > -Greg >=20 > RESOURCES >=20 > + IETF 108 session chair guide > https://www.ietf.org/how/meetings/108/session-chair-guide/ >=20 > + IETF 108 participant guide > https://www.ietf.org/how/meetings/108/session-participant-guide/ >=20 > + Tutorial video from Meetecho=20 > https://youtu.be/cniAxuMczEk >=20 > + Meetecho documentation for IETF 108 > https://www.ietf.org/media/documents/Documentation-Meetecho-IETF.pdf >=20 > + Recordings of Meetecho test sessions for IETF 108 > - Participant test session recording > https://youtu.be/SiD3Rj-Beag >=20 > - Chair test session recording > https://youtu.be/vMY1MHgjE_c >=20 >=20 > TESTING >=20 > + There will be a test Meetecho session open 30 minutes before and 30 = minutes after the IETF 108 meeting sessions each day from 27-31 July. (I = will be participating in these.) >=20 > + We are working on a way for IETF 108 session chairs to further test = Meetecho in that role and will provide further details tomorrow (24 = July). >=20 >=20 > ASSISTANCE >=20 > + Each IETF 108 session will be monitored by someone from the Meetecho = team (they will have =E2=80=9CMeetecho=E2=80=9D as their role in the = session participant list) >=20 > + Information about how to report issues during IETF 108 is available = at: > https://www.ietf.org/how/meetings/issues/ >=20 --Apple-Mail=_447936C4-F88C-4B77-B82D-EEF140EE0437 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

Here = are some helpful Meetecho resources from Greg Wood. I suggest everyone = read at least the participant guide enough in advance of the meeting so = you can make sure your local setup works.

Thanks!

Ben.


Begin forwarded = message:

From: = Greg Wood <ghwood@ietf.org>
Subject: = IETF 108 Online = session chair resources and information
Date: = July 23, 2020 at 10:15:15 AM = CDT

Hello,

Thanks to everyone who = was able to join and provide feedback during the Meetecho testing = sessions over the past week.

Especially if = you participated in an early testing session, you might find these = resources useful as they have been updated with new information in the = last few days.

-Greg

RESOURCES

+ IETF 108 session = chair guide
https://www.ietf.org/how/meetings/108/session-chair-guide/<= br class=3D"">
+ IETF 108 participant guide
https://www.ietf.org/how/meetings/108/session-participant-guide= /

+ Tutorial video from Meetecho
https://youtu.be/cniAxuMczEk

+ = Meetecho documentation for IETF 108
https://www.ietf.org/media/documents/Documentation-Meetecho-IET= F.pdf

+ Recordings of Meetecho test = sessions for IETF 108
- Participant test session = recording
https://youtu.be/SiD3Rj-Beag

- Chair test session recording
https://youtu.be/vMY1MHgjE_c


TESTING

+ There will be a test = Meetecho session open 30 minutes before and 30 minutes after the IETF = 108 meeting sessions each day from 27-31 July. (I will be participating = in these.)

+ We are working on a way for = IETF 108 session chairs to further test Meetecho in that role and will = provide further details tomorrow (24 July).


ASSISTANCE

+ Each = IETF 108 session will be monitored by someone from the Meetecho team = (they will have =E2=80=9CMeetecho=E2=80=9D as their role in the session = participant list)

+ Information about how = to report issues during IETF 108 is available at:
https://www.ietf.org/how/meetings/issues/


= --Apple-Mail=_447936C4-F88C-4B77-B82D-EEF140EE0437-- From nobody Fri Jul 24 08:34:42 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B2C3A0D5E for ; Fri, 24 Jul 2020 08:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 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, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 onpfZJR59aWU for ; Fri, 24 Jul 2020 08:34:32 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 2FDC33A0DBA for ; Fri, 24 Jul 2020 08:34:24 -0700 (PDT) Received: from bens-macbook.lan (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 06OFYJSw011443 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 24 Jul 2020 10:34:21 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1595604861; bh=sg3tZBHemC/Q6G+0D9rmnZzoa38N2/WjK5sWQtGt9Hk=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=l1v1A9asdZORXoangSfyb/3IV2aLWW2/5XA+mRjpGokGG53vVMqR3V7AjzgaSDWZw T0Szlcv1dXu9BEZoQzC6iV9xZJpj/L4kYRiKRf5tcAJLZWNJaWkNo8IqNROu6ZUufR oIRfnKdgSWZiTtX3K4fYwgYVZFxCjp3BpdyUl9cs= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be bens-macbook.lan Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Ben Campbell In-Reply-To: <8851CBDC-53E8-4D06-8F4C-9B7546E7F2C3@nostrum.com> Date: Fri, 24 Jul 2020 10:34:14 -0500 Cc: Patrick McManus Content-Transfer-Encoding: quoted-printable Message-Id: <4E67054B-E33E-44BD-8C23-22E8CE133251@nostrum.com> References: <8851CBDC-53E8-4D06-8F4C-9B7546E7F2C3@nostrum.com> To: DISPATCH WG X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [dispatch] Note Takers and Jabber Scribe X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 15:34:41 -0000 Huzzahs for Bron who has volunteered to take notes! Hip hip=E2=80=A6 We still need a Jabber scribe and another note taker. Don=E2=80=99t let = Bron keep all that glory for himself :-) Thanks! Ben. > On Jul 23, 2020, at 10:25 PM, Ben Campbell wrote: >=20 > Hi All, >=20 > We need volunteers to serve as note takers and jabber scribe for = Mondat=E2=80=99s meeting. We need at least one note-taker, but two would = be better. >=20 > For notes, we need to capture decisions and action items. A = play-by-play transcript is not necessary (but we won=E2=80=99t turn it = away if you like to do that sort of thing.) >=20 > The jabber scribe role may be a little different than usual. If = experience from IETF107 holds, there will be substantive conversations = in the jabber room/Meetecho chat. We=E2=80=99d like the jabber scribe to = consider whether those conversations should come to the audio channel, = and either bring them or encourage other jabber participants to do so. >=20 > Volunteers will receive our undying gratitude. >=20 > Thanks! >=20 > Ben. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Fri Jul 24 11:27:01 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C563A1196 for ; Fri, 24 Jul 2020 11:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 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_DNSWL_BLOCKED=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 zVZK3ERvaZoI for ; Fri, 24 Jul 2020 11:26:42 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 0CB253A11AA for ; Fri, 24 Jul 2020 11:26:41 -0700 (PDT) Received: from bens-macbook.lan (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 06OIQch7090301 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 24 Jul 2020 13:26:39 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1595615199; bh=Ph0Lhq8dZoLH01uSbTUNnEhtF6sZ/hJMnrp31d37f9Q=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=fnNiOeALQR1rfFbGoysx7synL56W1Uxc/vBrNxlfRnt2LxwUXpNFCYe4c97kQB3nl kXyzrRN1JcqZ9zNp3h00PCHyzGQNBAn9OIsrVlT+h3Y4Tg8es8bRa/8bkwcpG5qveZ kdYofWOHREkhsmfe/b7mcIquTThzvwx/++AuarxQ= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be bens-macbook.lan Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Ben Campbell In-Reply-To: <4E67054B-E33E-44BD-8C23-22E8CE133251@nostrum.com> Date: Fri, 24 Jul 2020 13:26:32 -0500 Cc: Patrick McManus Content-Transfer-Encoding: quoted-printable Message-Id: References: <8851CBDC-53E8-4D06-8F4C-9B7546E7F2C3@nostrum.com> <4E67054B-E33E-44BD-8C23-22E8CE133251@nostrum.com> To: DISPATCH WG X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [dispatch] Note Takers and Jabber Scribe X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 18:26:50 -0000 More huzzahs for Brian the Jabber scribe! Can we get one more note take? Thanks! Ben. > On Jul 24, 2020, at 10:34 AM, Ben Campbell wrote: >=20 > Huzzahs for Bron who has volunteered to take notes! Hip hip=E2=80=A6 >=20 > We still need a Jabber scribe and another note taker. Don=E2=80=99t = let Bron keep all that glory for himself :-) >=20 > Thanks! >=20 > Ben. >=20 >> On Jul 23, 2020, at 10:25 PM, Ben Campbell wrote: >>=20 >> Hi All, >>=20 >> We need volunteers to serve as note takers and jabber scribe for = Mondat=E2=80=99s meeting. We need at least one note-taker, but two would = be better. >>=20 >> For notes, we need to capture decisions and action items. A = play-by-play transcript is not necessary (but we won=E2=80=99t turn it = away if you like to do that sort of thing.) >>=20 >> The jabber scribe role may be a little different than usual. If = experience from IETF107 holds, there will be substantive conversations = in the jabber room/Meetecho chat. We=E2=80=99d like the jabber scribe to = consider whether those conversations should come to the audio channel, = and either bring them or encourage other jabber participants to do so. >>=20 >> Volunteers will receive our undying gratitude. >>=20 >> Thanks! >>=20 >> Ben. >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Sun Jul 26 11:12:12 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F2C3A12D1 for ; Sun, 26 Jul 2020 11:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 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, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 vGfL8ZMU3h6V for ; Sun, 26 Jul 2020 11:12:08 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 6F7FD3A0F72 for ; Sun, 26 Jul 2020 11:12:08 -0700 (PDT) Received: from bens-macbook.lan (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 06QIC6l4062063 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sun, 26 Jul 2020 13:12:07 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1595787127; bh=y5jfJKa5kp8QbS5biEqoECDRLnQo2Ll17bb5iE9EDRw=; h=From:Subject:References:To:Date; b=pL42LftQmQRORZRFMJBhNHPFCTRjwh3mM4IMTB2O+LSgN8QYF6KzCezfjl6mY6rLA J6YaT0ON0UumCT4+efB+XLxRbmXEhv5SLFBTkca7zxVPqC85qr26EZKwhW5lf8yvPJ bOrPQWrOjZmw4X8tEfU0Wj+xWd8A7yQczfgu35zs= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be bens-macbook.lan From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Message-Id: <0E0C5C53-6B53-4427-8572-6CDE95EC6A11@nostrum.com> References: To: DISPATCH WG Date: Sun, 26 Jul 2020 13:11:59 -0500 X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [dispatch] Visit the NomCom X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 18:12:10 -0000 Hi, A message from the 2020 NomCom chair: Thanks! Ben. > I wanted to let everyone know that NomCom will be holding some office = hours next week. If you want to stop by and talk with us (just to say = Hi, ask about NomCom, ask about being a nominee for the various I* = positions, etc.), we'd love to see and hear from you. >=20 > The date and times (which are also posted on the IETF 108 Agenda) are: >=20 > Monday, July 27, 16:00-17:00 UTC WebEx: = https://ietf.webex.com/ietf/j.php?MTID=3Dm13c41ae118e538b6d25efb25d41307ee= > Tuesday, July 28, 09:30-10:30 UTC WebEx: = https://ietf.webex.com/ietf/j.php?MTID=3Dm6132b48c3eac5469a41043ce55dada20= > Thursday, July 30, 20:00-21:00 UTC WebEx: = https://ietf.webex.com/ietf/j..php?MTID=3Dmf7ce451931e35818fd7b3bf44abd102= 6 >=20 > In addition to being available by WebEx, those of us who can will = simultaneously be on Gather.Town (possibly in a special NomCom corner). = To find us, the easiest way is to go to the Participants list (at right = of the Gather screen), find "Barbara Stark", left click on my name and = select "Locate". >=20 > See you next week! > Barbara=20 >=20 From nobody Sun Jul 26 11:42:29 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D817C3A13AA for ; Sun, 26 Jul 2020 11:42:27 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 Y7ypttz1BFWA for ; Sun, 26 Jul 2020 11:42:26 -0700 (PDT) Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (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 F024B3A13A8 for ; Sun, 26 Jul 2020 11:42:25 -0700 (PDT) Received: by mail-ua1-x92a.google.com with SMTP id i24so4733387uak.3 for ; Sun, 26 Jul 2020 11:42:25 -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; bh=JU1XP6UdnwYo7q9ikiASUg3OKCCBV0tHepttmUBjPT0=; b=fHGSbj3fD4h/3UcyMZceI83vAKhWLByJSGImcPfiyvggzX7cbJSE3sLXMrhSFE5Vme 8HL11gY238KmuN1JccSJsqbAqf6VQFVL7QpuFfUyf9pwxcLs/1kDiQdlf0N8p0fSoi5q IXu/GtBL71H0MadDrBjmTBIrT4gOanMA/IUe2eoitGLoFCdsKNkSSqFZJAGShJ3OkSmF cTr2di+jd+7fGyT8hFdkco2K8j+WURE6jkDUdUNNXIDT8sSIOK/HsdK3B6Rpx70vrJjp rfDCHucq1G+lrAnwSA89losyFuPAdLNujiz4q1aeXgKNKBSZdNrBK4iKyuRuj8K875oI NLTQ== 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; bh=JU1XP6UdnwYo7q9ikiASUg3OKCCBV0tHepttmUBjPT0=; b=WtEacD7wU2ScdUTcpTB4LQE7b3lX/ouD0h+ZZUfhnf54md/cbMtqUhGV77x401qxZL W9Ed9s0++gSSCA4YTPXAph3SeJMvhcXSOWHKzSAiE+QGnswXxvKMfCKIXaJxteJjLaYl VOMGjXU8Inv6YYFZ+efZVtKubU2v61q6bJvjiGnDMMcicFBdGp2NgGs4qd3kaZ06piH9 vGHjy7Glrkj6YrlrX2MpCrl1cxDXHFLv6vr7Qd19UfEi7jJaNHj9drZ1Tivd0JCWhks7 Co3LObwVVcWKF1yr8tTj6o4x9aLqxgeDqgO3n/ZIHRbR8tiVcSuk4sPUwHpxZ2xZHDnw yCUw== X-Gm-Message-State: AOAM531k28Wc0tgGXCWxRhgxcFiz0x1PSdZu29jiVpzrhpAcqp7ZuEdr +cZBCFObomBbEZZ4cFwa8u3y+w75uH3RNGPeyM/10A== X-Google-Smtp-Source: ABdhPJyZZIf/wwwVf41UylPGOb7P0gw8bJygrGZLI8SZ/oBSAjL9Y6waTDj0XzNYAWGVELa6zqewu1WaX/+ezqZdbM8= X-Received: by 2002:ab0:764d:: with SMTP id s13mr657431uaq.76.1595788943388; Sun, 26 Jul 2020 11:42:23 -0700 (PDT) MIME-Version: 1.0 References: <159562615817.8487.8157656164577705814@ietfa.amsl.com> In-Reply-To: <159562615817.8487.8157656164577705814@ietfa.amsl.com> From: "Murray S. Kucherawy" Date: Sun, 26 Jul 2020 11:42:11 -0700 Message-ID: To: DISPATCH list Content-Type: multipart/alternative; boundary="0000000000001b745305ab5c91da" Archived-At: Subject: [dispatch] Fwd: WG Action: Formed Automatic SIP trunking And Peering (asap) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 18:42:28 -0000 --0000000000001b745305ab5c91da Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Of possible interest to this community. -MSK ---------- Forwarded message --------- From: The IESG Date: Fri, Jul 24, 2020 at 2:29 PM Subject: WG Action: Formed Automatic SIP trunking And Peering (asap) To: IETF-Announce Cc: , , The IESG , < dispatch-chairs@ietf.org> 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. Automatic SIP trunking And Peering (asap) ----------------------------------------------------------------------- Current status: Active WG Chairs: Adam Roach Gonzalo Salgueiro Assigned Area Director: Murray Kucherawy Applications and Real-Time Area Directors: Barry Leiba Murray Kucherawy Mailing list: Address: asap@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/asap Archive: https://mailarchive.ietf.org/arch/browse/asap/ Group page: https://datatracker.ietf.org/group/asap/ Charter: https://datatracker.ietf.org/doc/charter-ietf-asap/ The deployment of a Session Initiation Protocol (SIP)-based infrastructure in enterprise and service provider communication networks has been gradually increasing over the last few years. Consequently, direct IP peering between enterprise and service provider networks is replacing traditional methods o= f interconnection between these networks, such as analog lines and time-division multiplexing (TDM)-based digital circuits. Currently published standards provide a strong foundation over which direct IP peering can be realized. However, given the sheer number of these standards, it is often unclear which behavioural subsets, extensions to baseline protocols and operating principles ought to be configured by the enterprise network administrator to ensure successful IP peering with a SIP service provider network. This lack of context often leads to interoperability issues between enterprise and service provider SIP networks. As a result, a significant amount of time is spent by enterprise network administrators in troubleshooting these interoperability issues individuall= y or with enterprise equipment manufacturer and service provider support teams. Consequently, there is an increase in the time taken to deploy SIP trunking between enterprise and service provider networks. The ASAP working group will define a descriptive capability set, which is populated by a SIP service provider, and which, when communicated to an enterprise network, encapsulates sufficient information to set up SIP trunking with the service provider network. In addition to defining a descriptive capability set, the ASAP working group will define a data model for the capability set, a service discovery mechanism and a transport mechanism for the capability set. The aforementioned deliverables of the ASAP working group are collectively referred to as =E2=80=9CSIP Auto Peer=E2=80= =9D. The scope of the ASAP working group is: * A capability set that encapsulates sufficient information to ensure smoot= h IP peering between enterprise and service provider SIP networks. * A data model for the capability set. * An HTTPS-based transport mechanism for the capability set. * A mechanism to discover the server(s) in the SIP service provider network that hosts the capability set. * A mechanism to extend the data model to allow the encoding of proprietary parameters. The following are out of scope: * Extensions to SIP that enable an enterprise network to solicit and obtain a descriptive capability set from a SIP service provider. * A workflow/mechanism that allows service providers to directly configure devices in the enterprise network. The group will produce: * Specification for SIP Auto Peer This group will co-ordinate with the SIPCORE working group and the SIPConnect efforts carried out by the SIP Forum. Milestones: Jun 2021 - SIP Automatic Peering specification submitted for publication to the IESG. --0000000000001b745305ab5c91da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Of possible interest to this community.
-MSK

---------- Forwarded message ---------
From: The IESG &l= t;iesg-secretary@ietf.org>= ;
Date: Fri, Jul 24, 2020 at 2:29 PM
Subject: WG Action: Forme= d Automatic SIP trunking And Peering (asap)
To: IETF-Announce <ietf-announce@ietf.org>
Cc: = <asap-chairs@ietf.org>, = <asap@ietf.org>, The IESG <iesg@ietf.org>, <dispatch-chairs@ietf.org>

<= br>A new IETF WG has been formed in the Applications and Real-Time Area. Fo= r
additional information, please contact the Area Directors or the WG Chairs.=

Automatic SIP trunking And Peering (asap)
-----------------------------------------------------------------------
Current status: Active WG

Chairs:
=C2=A0 Adam Roach <adam@nostrum.com>
=C2=A0 Gonzalo Salgueiro <gsalguei@cisco.com>

Assigned Area Director:
=C2=A0 Murray Kucherawy <superuser@gmail.com>

Applications and Real-Time Area Directors:
=C2=A0 Barry Leiba <barryleiba@computer.org>
=C2=A0 Murray Kucherawy <superuser@gmail.com>

Mailing list:
=C2=A0 Address: asap@iet= f.org
=C2=A0 To subscribe: https://www.ietf.org/mailman/listinfo= /asap
=C2=A0 Archive: https://mailarchive.ietf.org/arch/brow= se/asap/

Group page: https://datatracker.ietf.org/group/asap/

Charter: https://datatracker.ietf.org/doc/charter= -ietf-asap/

The deployment of a Session Initiation Protocol (SIP)-based infrastructure = in
enterprise and service provider communication networks has been gradually increasing over the last few years. Consequently, direct IP peering between=
enterprise and service provider networks is replacing traditional methods o= f
interconnection between these networks, such as analog lines and
time-division multiplexing (TDM)-based digital circuits.

Currently published standards provide a strong foundation over which direct=
IP peering can be realized. However, given the sheer number of these
standards, it is often unclear which behavioural subsets, extensions to
baseline protocols and operating principles ought to be configured by the enterprise network administrator to ensure successful IP peering with a SIP=
service provider network. This lack of context often leads to
interoperability issues between enterprise and service provider SIP network= s.
As a result, a significant amount of time is spent by enterprise network administrators in troubleshooting these interoperability issues individuall= y
or with enterprise equipment manufacturer and service provider support team= s.
Consequently, there is an increase in the time taken to deploy SIP trunking=
between enterprise and service provider networks.

The ASAP working group will define a descriptive capability set, which is populated by a SIP service provider, and which, when communicated to an
enterprise network, encapsulates sufficient information to set up SIP
trunking with the service provider network. In addition to defining a
descriptive capability set, the ASAP working group will define a data model=
for the capability set, a service discovery mechanism and a transport
mechanism for the capability set. The aforementioned deliverables of the AS= AP
working group are collectively referred to as =E2=80=9CSIP Auto Peer=E2=80= =9D.

The scope of the ASAP working group is:

* A capability set that encapsulates sufficient information to ensure smoot= h
IP peering between enterprise and service provider SIP networks.

* A data model for the capability set.

* An HTTPS-based transport mechanism for the capability set.

* A mechanism to discover the server(s) in the SIP service provider network=
that hosts the capability set.

* A mechanism to extend the data model to allow the encoding of proprietary=
parameters.

The following are out of scope:

* Extensions to SIP that enable an enterprise network to solicit and obtain= a
descriptive capability set from a SIP service provider.

* A workflow/mechanism that allows service providers to directly configure<= br> devices in the enterprise network.

The group will produce:

* Specification for SIP Auto Peer

This group will co-ordinate with the SIPCORE working group and the SIPConne= ct
efforts carried out by the SIP Forum.

Milestones:

=C2=A0 Jun 2021 - SIP Automatic Peering specification submitted for publica= tion to
=C2=A0 the IESG.



--0000000000001b745305ab5c91da-- From nobody Sun Jul 26 17:23:27 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F063A157D for ; Sun, 26 Jul 2020 17:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us 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 xnaa8k6Q20ma for ; Sun, 26 Jul 2020 17:23:21 -0700 (PDT) Received: from gateway21.websitewelcome.com (gateway21.websitewelcome.com [192.185.45.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CAFE3A1584 for ; Sun, 26 Jul 2020 17:23:21 -0700 (PDT) Received: from cm10.websitewelcome.com (cm10.websitewelcome.com [100.42.49.4]) by gateway21.websitewelcome.com (Postfix) with ESMTP id AEFAF401250E7 for ; Sun, 26 Jul 2020 19:23:20 -0500 (CDT) Received: from box5527.bluehost.com ([162.241.218.19]) by cmsmtp with SMTP id zqvIj2xZNRQIVzqvIjci5i; Sun, 26 Jul 2020 19:23:20 -0500 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-type:Mime-version:In-Reply-To:References:Message-ID:To: From:Subject:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=K/iyHbCc2SZhsJSYScnTG7d9TbeF0HRdHtKs6nKRdCE=; b=Jh6GwwgEZKtMHFQ9s3MbkJ6JG/ QdhNyYt3WZDEEM/Ci4QVWoqmOhfVVkVqVU7+Gd4XkHNZbMMjkcUCkaCF7fzOHYsF5p7LUtFT32cEq bwlLBG/4gM5rUWIF4meJI1gXt; Received: from pool-100-36-18-145.washdc.fios.verizon.net ([100.36.18.145]:52051 helo=[192.168.1.156]) by box5527.bluehost.com with esmtpa (Exim 4.93) (envelope-from ) id 1jzqvI-001Efm-Ab; Sun, 26 Jul 2020 18:23:20 -0600 User-Agent: Microsoft-MacOutlook/16.39.20071300 Date: Sun, 26 Jul 2020 20:23:18 -0400 From: Richard Shockey To: "Murray S. Kucherawy" , DISPATCH list Message-ID: <4FA7939A-3462-41D5-8529-583F54195FB4@shockey.us> Thread-Topic: [dispatch] Fwd: WG Action: Formed Automatic SIP trunking And Peering (asap) References: <159562615817.8487.8157656164577705814@ietfa.amsl.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3678639800_305531356" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5527.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.18.145 X-Source-L: No X-Exim-ID: 1jzqvI-001Efm-Ab X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-18-145.washdc.fios.verizon.net ([192.168.1.156]) [100.36.18.145]:52051 X-Source-Auth: richard+shockey.us X-Email-Count: 5 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NTUyNy5ibHVlaG9zdC5jb20= X-Local-Domain: yes Archived-At: Subject: Re: [dispatch] Fwd: WG Action: Formed Automatic SIP trunking And Peering (asap) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 00:23:25 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3678639800_305531356 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable =20 When BTW was the BOF on this? =20 =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook =E2=80=93Twitter rshockey101 PSTN +1 703-593-2683 =20 =20 From: dispatch on behalf of "Murray S. Kucheraw= y" Date: Sunday, July 26, 2020 at 2:42 PM To: DISPATCH list Subject: [dispatch] Fwd: WG Action: Formed Automatic SIP trunking And Peeri= ng (asap) =20 Of possible interest to this community. =20 -MSK =20 ---------- Forwarded message --------- From: The IESG Date: Fri, Jul 24, 2020 at 2:29 PM Subject: WG Action: Formed Automatic SIP trunking And Peering (asap) To: IETF-Announce Cc: , , The IESG , 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. Automatic SIP trunking And Peering (asap) ----------------------------------------------------------------------- Current status: Active WG Chairs: Adam Roach Gonzalo Salgueiro Assigned Area Director: Murray Kucherawy Applications and Real-Time Area Directors: Barry Leiba Murray Kucherawy Mailing list: Address: asap@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/asap Archive: https://mailarchive.ietf.org/arch/browse/asap/ Group page: https://datatracker.ietf.org/group/asap/ Charter: https://datatracker.ietf.org/doc/charter-ietf-asap/ The deployment of a Session Initiation Protocol (SIP)-based infrastructure = in enterprise and service provider communication networks has been gradually increasing over the last few years. Consequently, direct IP peering between enterprise and service provider networks is replacing traditional methods o= f interconnection between these networks, such as analog lines and time-division multiplexing (TDM)-based digital circuits. Currently published standards provide a strong foundation over which direct IP peering can be realized. However, given the sheer number of these standards, it is often unclear which behavioural subsets, extensions to baseline protocols and operating principles ought to be configured by the enterprise network administrator to ensure successful IP peering with a SIP service provider network. This lack of context often leads to interoperability issues between enterprise and service provider SIP network= s. As a result, a significant amount of time is spent by enterprise network administrators in troubleshooting these interoperability issues individuall= y or with enterprise equipment manufacturer and service provider support team= s. Consequently, there is an increase in the time taken to deploy SIP trunking between enterprise and service provider networks. The ASAP working group will define a descriptive capability set, which is populated by a SIP service provider, and which, when communicated to an enterprise network, encapsulates sufficient information to set up SIP trunking with the service provider network. In addition to defining a descriptive capability set, the ASAP working group will define a data model for the capability set, a service discovery mechanism and a transport mechanism for the capability set. The aforementioned deliverables of the AS= AP working group are collectively referred to as =E2=80=9CSIP Auto Peer=E2=80=9D. The scope of the ASAP working group is: * A capability set that encapsulates sufficient information to ensure smoot= h IP peering between enterprise and service provider SIP networks. * A data model for the capability set. * An HTTPS-based transport mechanism for the capability set. * A mechanism to discover the server(s) in the SIP service provider network that hosts the capability set. * A mechanism to extend the data model to allow the encoding of proprietary parameters. The following are out of scope: * Extensions to SIP that enable an enterprise network to solicit and obtain= a descriptive capability set from a SIP service provider. * A workflow/mechanism that allows service providers to directly configure devices in the enterprise network. The group will produce: * Specification for SIP Auto Peer This group will co-ordinate with the SIPCORE working group and the SIPConne= ct efforts carried out by the SIP Forum. Milestones: Jun 2021 - SIP Automatic Peering specification submitted for publication = to the IESG. _______________________________________________ dispatch mailing list dispa= tch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch=20 --B_3678639800_305531356 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

 

When BTW w= as the BOF on this?

 

=E2=80= =94 

Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

<= div>

www.shockey= .us

www.sipforum.org

richard<at>shoc= key.us

Skype-Linkedin-Facebook =E2=80=93Twitter  rshockey101=

PSTN +1 703-593-2683

 

 

=

From:= dispatch <dispatch= -bounces@ietf.org> on behalf of "Murray S. Kucherawy" <super= user@gmail.com>
Date: Sunday, July 26, 2020 at 2:42 PM
To= : DISPATCH list <dispatch@ietf.org>
Subject: [dispatch] = Fwd: WG Action: Formed Automatic SIP trunking And Peering (asap)<= /span>

 

Of possible interest to this community.

 

-MSK

 

---------- Forwarded message ---------
From: The IESG <iesg-secretary@ie= tf.org>
Date: Fri, Jul 24, 2020 at 2:29 PM
Subject: WG Action: = Formed Automatic SIP trunking And Peering (asap)
To: IETF-Announce <ietf-announce@ietf.org>
Cc: = <asap-chairs@ietf.org>, <= asap@ietf.org>, The IESG <iesg@ietf.org>, <dispatch-chairs@ietf.org>



A new IETF WG has been forme= d in the Applications and Real-Time Area. For
additional information, ple= ase contact the Area Directors or the WG Chairs.

Automatic SIP trunki= ng And Peering (asap)
---------------------------------------------------= --------------------
Current status: Active WG

Chairs:
  A= dam Roach <adam@nostrum= .com>
  Gonzalo Salgueiro <gsalguei@cisco.com>

Assigned Area Directo= r:
  Murray Kucherawy <superuser@gmail.com>

Applications and Real-Time Are= a Directors:
  Barry Leiba <barryleiba@computer.org>
  Murray Kuchera= wy <superuser@gmail.= com>

Mailing list:
  Address: asap@ietf.org
  To subscribe: https://www.ietf.o= rg/mailman/listinfo/asap
  Archive: https://mailarchive.ietf.org/ar= ch/browse/asap/

Group page: https://datatracker.ietf.org/group/asap/
Charter: https://datatracker.ietf.org/doc/charter-ietf-asap/
=
The deployment of a Session Initiation Protocol (SIP)-based infrastructu= re in
enterprise and service provider communication networks has been gra= dually
increasing over the last few years. Consequently, direct IP peerin= g between
enterprise and service provider networks is replacing tradition= al methods of
interconnection between these networks, such as analog line= s and
time-division multiplexing (TDM)-based digital circuits.

Cur= rently published standards provide a strong foundation over which direct
= IP peering can be realized. However, given the sheer number of these
stan= dards, it is often unclear which behavioural subsets, extensions to
basel= ine protocols and operating principles ought to be configured by the
ente= rprise network administrator to ensure successful IP peering with a SIP
s= ervice provider network. This lack of context often leads to
interoperabi= lity issues between enterprise and service provider SIP networks.
As a re= sult, a significant amount of time is spent by enterprise network
adminis= trators in troubleshooting these interoperability issues individually
or = with enterprise equipment manufacturer and service provider support teams.Consequently, there is an increase in the time taken to deploy SIP trunkin= g
between enterprise and service provider networks.

The ASAP worki= ng group will define a descriptive capability set, which is
populated by = a SIP service provider, and which, when communicated to an
enterprise net= work, encapsulates sufficient information to set up SIP
trunking with the= service provider network. In addition to defining a
descriptive capabili= ty set, the ASAP working group will define a data model
for the capabilit= y set, a service discovery mechanism and a transport
mechanism for the ca= pability set. The aforementioned deliverables of the ASAP
working group a= re collectively referred to as =E2=80=9CSIP Auto Peer=E2=80=9D.

The scope of the = ASAP working group is:

* A capability set that encapsulates sufficien= t information to ensure smooth
IP peering between enterprise and service = provider SIP networks.

* A data model for the capability set.

= * An HTTPS-based transport mechanism for the capability set.

* A mech= anism to discover the server(s) in the SIP service provider network
that = hosts the capability set.

* A mechanism to extend the data model to a= llow the encoding of proprietary
parameters.

The following are out= of scope:

* Extensions to SIP that enable an enterprise network to s= olicit and obtain a
descriptive capability set from a SIP service provide= r.

* A workflow/mechanism that allows service providers to directly c= onfigure
devices in the enterprise network.

The group will produce= :

* Specification for SIP Auto Peer

This group will co-ordinat= e with the SIPCORE working group and the SIPConnect
efforts carried out b= y the SIP Forum.

Milestones:

  Jun 2021 - SIP Automatic P= eering specification submitted for publication to
  the IESG.

___________________= ____________________________ dispatch mailing list dispatch@ietf.org https:/= /www.ietf.org/mailman/listinfo/dispatch

--B_3678639800_305531356-- From nobody Sun Jul 26 17:55:55 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4A63A15A0 for ; Sun, 26 Jul 2020 17:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, MAY_BE_FORGED=1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 642fXG2M0BEG for ; Sun, 26 Jul 2020 17:55:52 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 E9C8F3A159A for ; Sun, 26 Jul 2020 17:55:51 -0700 (PDT) Received: from bens-macbook.lan (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 06R0thTw019031 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 26 Jul 2020 19:55:44 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1595811345; bh=6lAu8aYBQZEgYibKD/qWtWXMuxBFtPuZ5bIvm2YURJg=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=wWygSY8pK6q7mklho1boXQpE5+WXLPP6GSpOHVfKeigJErDvOEkQMV8vizjnWToU2 DcJUFO6GgLMb0CJeeG/w/V9FhHLcqgKUgNvJk8UxNVG6vjK9XZc3wZyYeMBS7R+YQf Dy7BpxtCwZDMOM6WlGqZievxrQHEucQTsZjjSBo0= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be bens-macbook.lan From: Ben Campbell Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_DE4591AE-CBFC-4D1F-B8B9-0BCE5126E7CE" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Sun, 26 Jul 2020 19:55:36 -0500 In-Reply-To: <4FA7939A-3462-41D5-8529-583F54195FB4@shockey.us> Cc: "Murray S. Kucherawy" , DISPATCH list To: Richard Shockey References: <159562615817.8487.8157656164577705814@ietfa.amsl.com> <4FA7939A-3462-41D5-8529-583F54195FB4@shockey.us> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [dispatch] WG Action: Formed Automatic SIP trunking And Peering (asap) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 00:55:54 -0000 --Apple-Mail=_DE4591AE-CBFC-4D1F-B8B9-0BCE5126E7CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Richard, There was not a BoF. ASAP was directly formed as a so-called = =E2=80=9Cmini-wg=E2=80=9D based on discussions in DISPATCH (at IETF106 = and on the mailing list.) Thanks, Ben. > On Jul 26, 2020, at 7:23 PM, Richard Shockey = wrote: >=20 > =20 > When BTW was the BOF on this? > =20 > =E2=80=94=20 > Richard Shockey > Shockey Consulting LLC > Chairman of the Board SIP Forum > www.shockey..us > www.sipforum.org > richardshockey.us > Skype-Linkedin-Facebook =E2=80=93Twitter rshockey101 > PSTN +1 703-593-2683 > =20 > =20 > From: dispatch on behalf of "Murray S. = Kucherawy" > Date: Sunday, July 26, 2020 at 2:42 PM > To: DISPATCH list > Subject: [dispatch] Fwd: WG Action: Formed Automatic SIP trunking And = Peering (asap) > =20 > Of possible interest to this community. > =20 > -MSK > =20 > ---------- Forwarded message --------- > From: The IESG > > Date: Fri, Jul 24, 2020 at 2:29 PM > Subject: WG Action: Formed Automatic SIP trunking And Peering (asap) > To: IETF-Announce > > Cc: >, = >, The IESG >, > >=20 >=20 > 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. >=20 > Automatic SIP trunking And Peering (asap) > = ----------------------------------------------------------------------- > Current status: Active WG >=20 > Chairs: > Adam Roach > > Gonzalo Salgueiro > >=20 > Assigned Area Director: > Murray Kucherawy > >=20 > Applications and Real-Time Area Directors: > Barry Leiba > > Murray Kucherawy > >=20 > Mailing list: > Address: asap@ietf.org > To subscribe: https://www.ietf.org/mailman/listinfo/asap = > Archive: https://mailarchive.ietf.org/arch/browse/asap/ = >=20 > Group page: https://datatracker.ietf.org/group/asap/ = >=20 > Charter: https://datatracker.ietf.org/doc/charter-ietf-asap/ = >=20 > The deployment of a Session Initiation Protocol (SIP)-based = infrastructure in > enterprise and service provider communication networks has been = gradually > increasing over the last few years. Consequently, direct IP peering = between > enterprise and service provider networks is replacing traditional = methods of > interconnection between these networks, such as analog lines and > time-division multiplexing (TDM)-based digital circuits. >=20 > Currently published standards provide a strong foundation over which = direct > IP peering can be realized. However, given the sheer number of these > standards, it is often unclear which behavioural subsets, extensions = to > baseline protocols and operating principles ought to be configured by = the > enterprise network administrator to ensure successful IP peering with = a SIP > service provider network. This lack of context often leads to > interoperability issues between enterprise and service provider SIP = networks. > As a result, a significant amount of time is spent by enterprise = network > administrators in troubleshooting these interoperability issues = individually > or with enterprise equipment manufacturer and service provider support = teams. > Consequently, there is an increase in the time taken to deploy SIP = trunking > between enterprise and service provider networks. >=20 > The ASAP working group will define a descriptive capability set, which = is > populated by a SIP service provider, and which, when communicated to = an > enterprise network, encapsulates sufficient information to set up SIP > trunking with the service provider network. In addition to defining a > descriptive capability set, the ASAP working group will define a data = model > for the capability set, a service discovery mechanism and a transport > mechanism for the capability set. The aforementioned deliverables of = the ASAP > working group are collectively referred to as =E2=80=9CSIP Auto = Peer=E2=80=9D. >=20 > The scope of the ASAP working group is: >=20 > * A capability set that encapsulates sufficient information to ensure = smooth > IP peering between enterprise and service provider SIP networks. >=20 > * A data model for the capability set. >=20 > * An HTTPS-based transport mechanism for the capability set. >=20 > * A mechanism to discover the server(s) in the SIP service provider = network > that hosts the capability set. >=20 > * A mechanism to extend the data model to allow the encoding of = proprietary > parameters. >=20 > The following are out of scope: >=20 > * Extensions to SIP that enable an enterprise network to solicit and = obtain a > descriptive capability set from a SIP service provider. >=20 > * A workflow/mechanism that allows service providers to directly = configure > devices in the enterprise network. >=20 > The group will produce: >=20 > * Specification for SIP Auto Peer >=20 > This group will co-ordinate with the SIPCORE working group and the = SIPConnect > efforts carried out by the SIP Forum. >=20 > Milestones: >=20 > Jun 2021 - SIP Automatic Peering specification submitted for = publication to > the IESG. >=20 >=20 >=20 > _______________________________________________ dispatch mailing list = dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch = --Apple-Mail=_DE4591AE-CBFC-4D1F-B8B9-0BCE5126E7CE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Richard,

There was = not a BoF. ASAP was directly formed as a so-called =E2=80=9Cmini-wg=E2=80=9D= based on discussions in DISPATCH (at IETF106 and on the mailing = list.)

Thanks,

Ben.

On Jul 26, 2020, at 7:23 PM, = Richard Shockey <richard@shockey.us> wrote:

 
When BTW was the BOF on = this?
 

=E2=80=94 

Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey..us
richard<at>shockey.us
Skype-Linkedin-Facebook =E2=80=93Twit= ter  rshockey101
PSTN +1 = 703-593-2683
 
 
From: dispatch <dispatch-bounces@ietf.org> on behalf of "Murray S. = Kucherawy" <superuser@gmail.com>
Date: Sunday, July 26, 2020 = at 2:42 PM
To: DISPATCH list <dispatch@ietf.org>
Subject: [dispatch] Fwd: WG = Action: Formed Automatic SIP trunking And Peering (asap)
 
Of possible interest to this community.
 
-MSK
 
---------- Forwarded = message ---------
From: The = IESG <iesg-secretary@ietf.org>Date: Fri, Jul 24, 2020 at 2:29 PM
Subject: WG = Action: Formed Automatic SIP trunking And Peering (asap)
To:= IETF-Announce <ietf-announce@ietf.org>
Cc: <asap-chairs@ietf.org>, = <asap@ietf.org>, The IESG = <iesg@ietf.org>, <dispatch-chairs@ietf.org>



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.

Automatic SIP trunking And Peering (asap)
---------------------------------------------------------------= --------
Current status: Active WG

Chairs:
  Adam Roach <adam@nostrum..com>
  Gonzalo Salgueiro <gsalguei@cisco.com>

Assigned Area Director:
  Murray Kucherawy = <superuser@gmail.com>

Applications and Real-Time Area Directors:
 = Barry Leiba <barryleiba@computer.org>
  Murray = Kucherawy <superuser@gmail.com>

Mailing list:
  Address: asap@ietf.org
  To subscribe: https://www.ietf.org/mailman/listinfo/asap
  Archive: https://mailarchive.ietf.org/arch/browse/asap/

Group page: https://datatracker.ietf.org/group/asap/

Charter: https://datatracker.ietf.org/doc/charter-ietf-asap/

The deployment of a Session Initiation = Protocol (SIP)-based infrastructure in
enterprise and = service provider communication networks has been gradually
increasing over the last few years. Consequently, direct IP = peering between
enterprise and service provider networks = is replacing traditional methods of
interconnection = between these networks, such as analog lines and
time-division multiplexing (TDM)-based digital circuits.

Currently published standards provide a strong = foundation over which direct
IP peering can be realized. = However, given the sheer number of these
standards, it is = often unclear which behavioural subsets, extensions to
baseline protocols and operating principles ought to be = configured by the
enterprise network administrator to = ensure successful IP peering with a SIP
service provider = network. This lack of context often leads to
interoperability issues between enterprise and service = provider SIP networks.
As a result, a significant amount = of time is spent by enterprise network
administrators in = troubleshooting these interoperability issues individually
or with enterprise equipment manufacturer and service = provider support teams.
Consequently, there is an increase = in the time taken to deploy SIP trunking
between = enterprise and service provider networks.

The= ASAP working group will define a descriptive capability set, which = is
populated by a SIP service provider, and which, when = communicated to an
enterprise network, encapsulates = sufficient information to set up SIP
trunking with the = service provider network. In addition to defining a
descriptive capability set, the ASAP working group will = define a data model
for the capability set, a service = discovery mechanism and a transport
mechanism for the = capability set. The aforementioned deliverables of the ASAP
working group are collectively referred to as =E2=80=9CSIP = Auto Peer=E2=80=9D.

The scope of the ASAP = working group is:

* A capability set that = encapsulates sufficient information to ensure smooth
IP = peering between enterprise and service provider SIP networks.

* A data model for the capability set.

* An HTTPS-based transport mechanism for the = capability set.

* A mechanism to discover = the server(s) in the SIP service provider network
that = hosts the capability set.

* A mechanism to = extend the data model to allow the encoding of proprietary
parameters.

The following are = out of scope:

* Extensions to SIP that = enable an enterprise network to solicit and obtain a
descriptive capability set from a SIP service provider.

* A workflow/mechanism that allows service = providers to directly configure
devices in the enterprise = network.

The group will produce:

* Specification for SIP Auto Peer

This group will co-ordinate with the SIPCORE = working group and the SIPConnect
efforts carried out by = the SIP Forum.

Milestones:

  Jun 2021 - SIP Automatic Peering specification = submitted for publication to
  the IESG.


_______________________________________________ dispatch = mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch 
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

= --Apple-Mail=_DE4591AE-CBFC-4D1F-B8B9-0BCE5126E7CE-- From nobody Sun Jul 26 17:58:04 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 229353A15A0 for ; Sun, 26 Jul 2020 17:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 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, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 BPlcILpJAQZd for ; Sun, 26 Jul 2020 17:58:01 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 AA5743A159A for ; Sun, 26 Jul 2020 17:58:01 -0700 (PDT) Received: from bens-macbook.lan (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 06R0vtwC019887 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 26 Jul 2020 19:57:56 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1595811477; bh=jifcqxmUL6nKE0L3FBOaVSbBZC3ncCA+Jd/D5R3hmIk=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=IPyK4WpCO3sxUj0zxayBrS2GAB1OLal3m3NFm43sH8E30h3Ky+ECPKsI5Ny/KgO10 ZilanvK6gyYLghl9lGPs6qjRqwa27gwy92KKuQullKBPfh/5rp9NMcMOkkMN41B2Lb 6mCd7vwu1EKBL1+oz7/RravH4euXkjeAsJbQwc+s= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be bens-macbook.lan Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Ben Campbell In-Reply-To: Date: Sun, 26 Jul 2020 19:57:49 -0500 Cc: Patrick McManus Content-Transfer-Encoding: quoted-printable Message-Id: References: <8851CBDC-53E8-4D06-8F4C-9B7546E7F2C3@nostrum.com> <4E67054B-E33E-44BD-8C23-22E8CE133251@nostrum.com> To: DISPATCH WG X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [dispatch] Note Takers and Jabber Scribe X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 00:58:03 -0000 Please, can we have one more note taker? Thanks! Ben. > On Jul 24, 2020, at 1:26 PM, Ben Campbell wrote: >=20 > More huzzahs for Brian the Jabber scribe! >=20 > Can we get one more note take? >=20 > Thanks! >=20 > Ben. >=20 >> On Jul 24, 2020, at 10:34 AM, Ben Campbell wrote: >>=20 >> Huzzahs for Bron who has volunteered to take notes! Hip hip=E2=80=A6 >>=20 >> We still need a Jabber scribe and another note taker. Don=E2=80=99t = let Bron keep all that glory for himself :-) >>=20 >> Thanks! >>=20 >> Ben. >>=20 >>> On Jul 23, 2020, at 10:25 PM, Ben Campbell wrote: >>>=20 >>> Hi All, >>>=20 >>> We need volunteers to serve as note takers and jabber scribe for = Mondat=E2=80=99s meeting. We need at least one note-taker, but two would = be better. >>>=20 >>> For notes, we need to capture decisions and action items. A = play-by-play transcript is not necessary (but we won=E2=80=99t turn it = away if you like to do that sort of thing.) >>>=20 >>> The jabber scribe role may be a little different than usual. If = experience from IETF107 holds, there will be substantive conversations = in the jabber room/Meetecho chat. We=E2=80=99d like the jabber scribe to = consider whether those conversations should come to the audio channel, = and either bring them or encourage other jabber participants to do so. >>>=20 >>> Volunteers will receive our undying gratitude. >>>=20 >>> Thanks! >>>=20 >>> Ben. >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 From nobody Sun Jul 26 20:48:51 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538163A1673 for ; Sun, 26 Jul 2020 20:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 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, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 kp5cLG2cwhGP for ; Sun, 26 Jul 2020 20:48:47 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 C818E3A1671 for ; Sun, 26 Jul 2020 20:48:47 -0700 (PDT) Received: from bens-macbook.lan (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 06R3mffF085464 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 26 Jul 2020 22:48:42 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1595821722; bh=VTYLAaSoQrfvpeoN0+zLhJjIpezJ8N4wGxdyaNEcldQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=jD7jYdG4CMR7Yi1o1RRpt4ULGaqVF0sYdDRz/9jqEVdowJ1LVjWBlhnrZb2iuWkEa 5xSPa1KcWQAcvuBAq+VQetLHIMe/J88B68CGpkZ3qeQaMdOe/PT3q+nFwf9XmQffJd mYFWRXsJzHjSlotM1FDIz0PTYBgC23OtAn869x9c= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be bens-macbook.lan Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Ben Campbell In-Reply-To: Date: Sun, 26 Jul 2020 22:48:34 -0500 Cc: Patrick McManus Content-Transfer-Encoding: quoted-printable Message-Id: <7F7AD2AB-0951-4BB3-928C-9F211EF5A9F4@nostrum.com> References: <8851CBDC-53E8-4D06-8F4C-9B7546E7F2C3@nostrum.com> <4E67054B-E33E-44BD-8C23-22E8CE133251@nostrum.com> To: DISPATCH WG X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [dispatch] Note Takers and Jabber Scribe X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 03:48:49 -0000 Pretty please? > On Jul 26, 2020, at 7:57 PM, Ben Campbell wrote: >=20 > Please, can we have one more note taker? >=20 > Thanks! >=20 > Ben. >=20 >> On Jul 24, 2020, at 1:26 PM, Ben Campbell wrote: >>=20 >> More huzzahs for Brian the Jabber scribe! >>=20 >> Can we get one more note take? >>=20 >> Thanks! >>=20 >> Ben. >>=20 >>> On Jul 24, 2020, at 10:34 AM, Ben Campbell wrote: >>>=20 >>> Huzzahs for Bron who has volunteered to take notes! Hip hip=E2=80=A6 >>>=20 >>> We still need a Jabber scribe and another note taker. Don=E2=80=99t = let Bron keep all that glory for himself :-) >>>=20 >>> Thanks! >>>=20 >>> Ben. >>>=20 >>>> On Jul 23, 2020, at 10:25 PM, Ben Campbell wrote: >>>>=20 >>>> Hi All, >>>>=20 >>>> We need volunteers to serve as note takers and jabber scribe for = Mondat=E2=80=99s meeting. We need at least one note-taker, but two would = be better. >>>>=20 >>>> For notes, we need to capture decisions and action items. A = play-by-play transcript is not necessary (but we won=E2=80=99t turn it = away if you like to do that sort of thing.) >>>>=20 >>>> The jabber scribe role may be a little different than usual. If = experience from IETF107 holds, there will be substantive conversations = in the jabber room/Meetecho chat. We=E2=80=99d like the jabber scribe to = consider whether those conversations should come to the audio channel, = and either bring them or encourage other jabber participants to do so. >>>>=20 >>>> Volunteers will receive our undying gratitude. >>>>=20 >>>> Thanks! >>>>=20 >>>> Ben. >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>=20 >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Mon Jul 27 10:34:37 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF20A3A1B1A for ; Mon, 27 Jul 2020 10:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 0jxG6qVa8f6K for ; Mon, 27 Jul 2020 10:34:30 -0700 (PDT) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (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 EF10B3A1B1B for ; Mon, 27 Jul 2020 10:34:29 -0700 (PDT) Received: by mail-ej1-x62a.google.com with SMTP id l4so17842910ejd.13 for ; Mon, 27 Jul 2020 10:34:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=TpfUFb03N0+DUo1RggFkE5CnNoYzLRzHftN5s2+rUEY=; b=vFX1atd0dEta4iWO1ZbezzVcYeKMGKtTJW7xOf6LdIc5JSy8XJS+9ImX3Lg/6sTTQj jUC9heoeOOGqqUBgI7rSRBJmDQIpFahu59VhUkmAXJgI0ElcM3bqhjVgHeq29FVsu1kQ SZeDmmp8GUXssSL3fJiUJ/MJm4Vzm75kvaFtzLY/F3jO4DPjaah4pXsMuGUpEnTzjDi5 QTjFqGNYkqHu3DItDfz3LIgYp3A8d+aB0FtPJZfGcCbrzt/AgwlzO/L9S/zhSLNWof8w OUNu/+DBmlIjjZJyTyD3xYbTME5bDbqW3iYjUXtwWFPZVJCBvzEzuhpGYooLd+Yto52X 4jew== 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=TpfUFb03N0+DUo1RggFkE5CnNoYzLRzHftN5s2+rUEY=; b=i2Kanw2QmgfEBBVyxVbWXo8nRcHALtIACavEVXdyhJRQrLFhq6OSgUABwZ43kpnioO dnry0mOBrI8SFfAL9gBhnaljIDSal+E9PW9bb52REMVKu0NGml7TOWPt8pf7pJykM229 jMFYwLbahmGSfFLoMPViiqziDy8Y24JWfTIk/CU8CiqS5VaTyD/NzdDlkrA70X0UAof1 BOxxLPErrkceJDqy+/2EDhUTy1UGIG+AXYnth4BbXiL0FZcq8VtgDr4Qjpd5xVORD0QK 6O+CGSOws7WpMfj5U2tubSdsQCPPTLtWE0GQI5iKH7Xuo0qC3KpGdhzsVQ9rqB4k5EN0 tKFw== X-Gm-Message-State: AOAM532XaWJ5MjjGP92+7onV49uKsBj3tq7ixpSKgNk/Mtbfbm1qDno1 swDwxjnmlxSk9oC7QK9BSdlnvf78BqDBKZadpCZ+ecU= X-Google-Smtp-Source: ABdhPJyK5c77dKC4WGiPYVqI3Yh1VeenaaNLVkMd0x2tTusN5P76GevKHeg/CCAiG/C8tHHECAPrcHZzofntpMqrlc8= X-Received: by 2002:a17:906:b5a:: with SMTP id v26mr2208401ejg.515.1595871268091; Mon, 27 Jul 2020 10:34:28 -0700 (PDT) MIME-Version: 1.0 From: Emad Omara Date: Mon, 27 Jul 2020 10:34:17 -0700 Message-ID: To: Dispatch WG Cc: sframe@ietf.org Content-Type: multipart/alternative; boundary="0000000000000b0f1405ab6fbc06" Archived-At: Subject: [dispatch] SFrame proposed WG charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 17:34:32 -0000 --0000000000000b0f1405ab6fbc06 Content-Type: text/plain; charset="UTF-8" Hi dispatch, Following up on the discussion we had this morning in IETF 108 dispatch session about SFrame , it seems there is enough interest to form a focused WG for this work. Richard Barnes proposed this charter for the WG. Please take a look and feel free to comment on the doc directly and propose other changes as well. Thanks Emad --0000000000000b0f1405ab6fbc06 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi dispatch,

Following up on the discus= sion we had this morning in IETF 108 dispatch session about SFrame, it seems there i= s enough interest to form a focused WG for this work.=C2=A0

<= /div>
Richard Barnes proposed this = charter for the WG. Please take a look and feel free to comment on the = doc directly and propose other changes as well.

Th= anks
Emad
--0000000000000b0f1405ab6fbc06-- From nobody Wed Jul 29 12:41:25 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5631A3A0E8C for ; Wed, 29 Jul 2020 12:41:24 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 hfoWwL7p0YT8 for ; Wed, 29 Jul 2020 12:41:23 -0700 (PDT) Received: from mail-il1-x143.google.com (mail-il1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) (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 D26063A0E52 for ; Wed, 29 Jul 2020 12:41:22 -0700 (PDT) Received: by mail-il1-x143.google.com with SMTP id c16so8661526ils.8 for ; Wed, 29 Jul 2020 12:41:22 -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; bh=bXazkk+jo9wtylist2vRQgwsUaKPw6GG1jsxNoEDD/g=; b=D60KhbRKI8+fDrM0+ItxEvMXqbLZjXlKnvk2+UCvp30V0Daj7EdIJf3Gx3jfMKHYZr PUfaB6OBHjsOoFJwnRgFB1Ri9NthO2/ZSHro451WIiw1GbISh7LxrnshYFeegDu6MeAX NBaib+jakiWM3bdOuIniM8wXCuXTr930pptxRu9fWOZtgt5d4t1U/ofleGVmeLQmV72S 58s7iH04HEtv324Cg/V5cHE5+Aq3VChP2YdT/kC+FFK5n8QajUpHO6Bv90vODlpU7ZjK B8c0euK3BmVpBjRP+F/sTTaoOR4+2o+F0EYTaSECfZ9fbqkYObpbBpXmTzpCPYFIh+xU FnjQ== 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=bXazkk+jo9wtylist2vRQgwsUaKPw6GG1jsxNoEDD/g=; b=gIteNpsPZqy40sr5nddj8ylcon9Z9uKJiyftNNcshjfwFfD+qEXZ4+LrMGPCbxLTn0 SmU6n9yMFvx5ns0KzYrBg8TRFVBGehqu0p/OI5zFhD9DPchLTTzB+1UZmPr12WYcoLZ0 KEzg9KNo3V6E8PTFvrhhHD2jVhNsvCMWr3efGFc/CNvljP2HxfxLpIsZpESFdx9LMF+K j1j3W2U+6XmxP8t0cCAnDUeU+tHzmV12mT0NoJGSSB1yFys7sc8mUtDfmgbep9lmvcCk KK+fvz7NGi+LIloFK2Ihe73huWWlrb+Cf3REgm9spxTGPspynifgYyHx1iG4vXSWIRS1 8CdA== X-Gm-Message-State: AOAM530vmsLabAszeoOFPIXYXE8AmNCDdObee6rkFexiLAnWrHYHqm7J BaworWeTouTYHlBoYsi0UwP5SmbXb45e0YO4HBRUx/6P72M= X-Google-Smtp-Source: ABdhPJxOhE3kpmpAHA4n3axhkcxrdDpHtRNu0VATP+KJdhOWrUoqFlPIOYXznEcCPu9UWAOLzp2oQGBbv16qEhseQRo= X-Received: by 2002:a92:4444:: with SMTP id a4mr1478789ilm.49.1596051681664; Wed, 29 Jul 2020 12:41:21 -0700 (PDT) MIME-Version: 1.0 From: Rob Sayre Date: Wed, 29 Jul 2020 12:41:10 -0700 Message-ID: To: dispatch@ietf.org Content-Type: multipart/alternative; boundary="00000000000087628b05ab99bd67" Archived-At: Subject: Re: [dispatch] A WG for HTTP API Building Blocks X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 19:41:24 -0000 --00000000000087628b05ab99bd67 Content-Type: text/plain; charset="UTF-8" Hi, Sorry to fragment the thread, but I wasn't subscribed to this list, and only saw a notice posted on the HTTP list. I think the proposal's aims are good, but some of the suggested techniques are a bit dated. The Australian example in the presentation is a good example of this concern[1]. This kind of documentation for a JSON API is considered an anti-pattern by many. It's a prose schema. Most companies I've worked with eventually switch to something like Protocol Buffers, Thrift, etc. Or, they started working with typed queries, as in GraphQL. Larger companies tend to combine these approaches. For example, GraphQL specifies pagination[2], but large companies often return something other than JSON, so they can get 64-bit numbers and binary payloads, in a somewhat more efficient format. Standardizing the things I've mentioned might not be possible (although I would love to settle on GraphQL + Flatbuffers...), but I think this list should at least contemplate whether the WG would be duplicating work here. thanks, Rob [1] https://www.youtube.com/watch?v=KDN7SamlAn0&t=4653s [2] https://graphql.org/learn/pagination/ --00000000000087628b05ab99bd67 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Sorry to fragment the thread, but I= wasn't subscribed=C2=A0to this list, and only saw a notice posted on t= he HTTP list.

I think the proposal's aims are = good, but some of the suggested techniques are a bit dated. The Australian = example in the presentation=C2=A0is a good example of this concern[1].

This kind of documentation for a JSON API is considere= d=C2=A0an anti-pattern by many. It's a prose=C2=A0schema. Most companie= s I've worked with eventually switch to something like Protocol Buffers= , Thrift, etc. Or, they started working with typed queries, as in GraphQL. = Larger companies tend to combine these approaches. For example, GraphQL spe= cifies pagination[2], but large companies often return something=C2=A0other= than JSON, so they can get 64-bit numbers and binary payloads, in a somewh= at more efficient format.

Standardizing the things= I've mentioned might not be possible (although I would love to settle = on GraphQL=C2=A0+ Flatbuffers...), but I think this list should at least co= ntemplate whether=C2=A0the WG would be=C2=A0duplicating work here.

thanks,
Rob

[1]=C2=A0https= ://www.youtube.com/watch?v=3DKDN7SamlAn0&t=3D4653s
--00000000000087628b05ab99bd67-- From nobody Wed Jul 29 20:05:56 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 413923A0C06 for ; Wed, 29 Jul 2020 20:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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=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 YcDKDbz62cO9 for ; Wed, 29 Jul 2020 20:05:49 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640104.outbound.protection.outlook.com [40.107.64.104]) (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 24AE73A0C02 for ; Wed, 29 Jul 2020 20:05:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YAGDJ3gUwAKEtJ5iL66suu27TJwnImev1UMXpWWSDToxjSfc4lEPs3w8IF/pBjeZwG0UbxrslyLdgCCUAKtm/8cce3KBbd+Kk0L4bf1jcn97721wgYXwhugNIWm4sE1s4Ef12QpZc6fm7O6ZP/wuoq48dgQWOo7lZdrI5/Qgpv7vH8ksAlAWbT7YdHUWDKiUEjLJXI0m2Abwcm4hF//7pgXqc1QGaYp+ws7p4Uy5bVYvfsdLzSnzay5X9xWJ9ua6hFZb6NcrdrcIZ838bQPjcjl19KCUFYs0gNOTSqkQIw3/Jk1QeKNaxZzek0U8p8HryaUUAFraLholM/EpKRpPUQ== 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=GCFL2/Acc9G1DT7CuYKLDJSrV8y2s032yn6jDjzLnLg=; b=QVpyOaohY1ngggLPsVqPcz32fmXCxFamB1PvHppzei5AGp7Axq1Anb3vZ9CWWmQk/df0FTmWuYbupu4OYauugmKgBQB2dyqi0bRUidHYN9tMBCfLu6sw4+jqqMxQeBsJmo+FfEir+SDEByslNbbc/PdyHmjfab+K2vdidhTU+BaD978oKhMYlo507vH5bGaopuI8VFlw/L99p7xZ/eQLhbAkZN4Zh8uGCeoydcerLNMA4P3/dEv+s1Y9mVy8vAAF2Q97h1b0sq9hqxm5CuJrEIdjKD2UFlK4f3A+tA1qBOD1YZt62l5uKpK/GCCjW8fYzB5igvjFJZVG71KLz3wwCA== 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=GCFL2/Acc9G1DT7CuYKLDJSrV8y2s032yn6jDjzLnLg=; b=ZZt5Rw7Rc1UJi1pWHjNQ7e97lj9qQGXL8kRUIZWtNe71E9hOkxCs4bV0e7ayAIOUDK1KFOlxpif1ATHZDgQ7XHn8SKXvNG8R5eAo7A512JoRG2F13Ir+Y+FKiW2wDS+No5uXKkC/nhnvs9MYs5r88uBjQzM8g546Mm68SpVlNR4= Received: from DM6PR00MB0845.namprd00.prod.outlook.com (2603:10b6:5:1bc::23) by DM6PR00MB0683.namprd00.prod.outlook.com (2603:10b6:5:21c::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3278.0; Thu, 30 Jul 2020 03:05:42 +0000 Received: from DM6PR00MB0845.namprd00.prod.outlook.com ([fe80::a43a:e0bf:7bd6:f2d7]) by DM6PR00MB0845.namprd00.prod.outlook.com ([fe80::a43a:e0bf:7bd6:f2d7%6]) with mapi id 15.20.3282.000; Thu, 30 Jul 2020 03:05:42 +0000 From: Darrel Miller To: "dispatch@ietf.org" Thread-Topic: [dispatch] A WG for HTTP API Building Blocks Thread-Index: AQHWZeB5RUZzwBBfDku3ANGv5NQrr6kfLL+T Date: Thu, 30 Jul 2020 03:05:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-CA 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-07-29T23:01:53.2150136Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Privileged 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: [69.159.101.65] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 33af175d-feba-484d-ee3d-08d83435725a x-ms-traffictypediagnostic: DM6PR00MB0683: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: egDwef7VjORDbiqkta+XiwzlqqZ8dISl74kn1cb+lmBkdky2RIactbs8dhUG9zAYvZhAundC+Wf35TW69nY36VXXuiICpPukbuF9Z5rO0dKJ24Mw3gstqxdIHKSTK0RS6lzmbKm/3gbpEm8atK85HzrCTdxJtf2gPLCyeB8fJ4+OULW97lYcTGob90yNxk/3z/Tr4uYSQkJXaXKc/gbH0QV0I6/Bi8lKXNip8bQ0IX6y6gmRqvGgKU6KiadOgaXSekXK6qf2Fp3BR3jHsxyL6OXYQW6RBZ2zSdQHVLXOQB4sIPCLLmNhFTOioYCl26paSL+3guB+sJBd0cIDXwJjD9zv3kfP9Ql0YZ9JYxnkSpm5iy3Oe2ves7X6LYRMot28RIIABam1Zmb7E37iKL0Uaw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR00MB0845.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(366004)(136003)(39860400002)(396003)(376002)(9686003)(6506007)(186003)(8990500004)(53546011)(55016002)(478600001)(5660300002)(7696005)(52536014)(10290500003)(71200400001)(33656002)(26005)(316002)(966005)(66946007)(82950400001)(166002)(82960400001)(66476007)(66556008)(64756008)(66446008)(2906002)(83380400001)(76116006)(86362001)(8676002)(8936002)(6916009); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: JJkPKViNErRo1lH5LOf0V1bhPYoR+u1x/3LphVcF/fbZ04nOr2RUoVg8Hv78RpF+NG7u2g3zHxPI24NoRx1GvbFOnpQnullFl3WMmIkNCmoYR5OQJ7HgaNXEhxBTlBty1mvcgEo/NoTmB+Yp3KuHN5ePtvvntW6CFKzAtywbdYcEHP1Vnf9TMOtvABm+4k5jYfPnPsZdGVcBJ5KERq9gV6/6ffXAxQC2ZcfiikPY+9xdH2geyT3KO1u33V4khZhwXOFNQT1xgIwLsCh9ZbhjG5/dXFH7jqN/2E0iKgLz+bru+lognjVG0j3I+KL9M5+ZQ6V7fJm0MxGK2r9oh4Lv/GyRk6vDXdxDp6+Jn8SUJTEbC94qAoyok26knZ/Ze7xkRo4Vy+fCLXQoNSU4PrMwaCW/hubqKw2UILwZQmI0QmvM6hpWBt0MNqxAfa34QZk6wBz4qJoTikGI7zXSvbVMsX2s8OmQUznLncZlX5h5lHH7BPd6SkdY33Q+bATKz/8zGXWaKpLOSQ/tSKmGmLKwlf/OO+GJFDYqDkasBED+cj2YktapL5kbfwQhiZ8f57n8zug3xEr6zff+RvV3yYaZlxamehg6KbqA7dCYvkk7LT36N72drzbtYdlThFIhXu59Ctkx8tgxYGqm+eEbA3s5zQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR00MB08455FC9C8F45CED0A416611F0700DM6PR00MB0845namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR00MB0845.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 33af175d-feba-484d-ee3d-08d83435725a X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2020 03:05:42.8332 (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: Ymknu2rnjv6Oh8HN/7N6scgl9fxbvzKtiFMqZG1IrYNMCg/oQJgM1wWsPU8rbMBvgLQpkBbDEOHGXWRtveQTYw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0683 Archived-At: Subject: Re: [dispatch] A WG for HTTP API Building Blocks X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 03:05:54 -0000 --_000_DM6PR00MB08455FC9C8F45CED0A416611F0700DM6PR00MB0845namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Rob, Thanks for sharing the link to the recording. I had planned on attending t= he meeting on Monday but sadly did not make it. I agree the aims of the charter are good. A large part of my day job invol= ves working with teams who are trying to expose HTTP APIs to our customers = and are looking for guidance on how to use HTTP in a consistent way for mac= hine 2 machine communications. I think there are a many areas that would benefit from