Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT)

Barry Leiba <barryleiba@computer.org> Wed, 04 September 2019 20:54 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24471120A9B; Wed, 4 Sep 2019 13:54:05 -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, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 7hjkFp048fe1; Wed, 4 Sep 2019 13:54:04 -0700 (PDT)
Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) (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 F17FE120E09; Wed, 4 Sep 2019 13:54:03 -0700 (PDT)
Received: by mail-io1-f50.google.com with SMTP id n197so45567220iod.9; Wed, 04 Sep 2019 13:54:03 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=3S0q7N2+oy8iv3p98Fw+LPRtDCs5I3aQV0YgYFqnjVc=; b=lONsiqKnAYlAIWkF58Ig+DgXsbzmr1HgL7eF8tcwdyewwBTkj1ZZVN1mSpKFmtrQcM duhwdVZWcdk9N6YuiZjsM3OEYrq+sCJ49WRl/b5lvTWoyQhMjuRGZvHytn4ynCXELSv1 dy3zC/pBlt2qN04krqJck0alTfEPAfk6KgB/HB3AaEwSMemfLccES+7Mvya5eEuJkSrz cPjC3+k9BG7473YDQ5rgaFQmTido46XzshHmZaetyckxHwU4BeKF7D3a/Uawk5LULL29 B+W+BJLC5Ju8/gOe3JehzEym38ljBss7ZZFYvX9tIqVvR6TOQNbG6i9SB7k8t5vxZdKH uNJg==
X-Gm-Message-State: APjAAAUQdbWzbHGgr3XJVRTDq08PInhEyMUtqtLIF+1E8eEKeR6GpZ+r wHYU4g5W9gaetaOr9PZRhYXRTN1p6nD8QLQf7zc=
X-Google-Smtp-Source: APXvYqxfsY5BWncZ1EWhpxK6UCC6Cm6FMeV8PBXFuBq/YKeJAKMXpbN9k26X6yhLadfqlK+swNCo1j6sf27xK/cQWeM=
X-Received: by 2002:a5d:9b96:: with SMTP id r22mr4928948iom.17.1567630443048; Wed, 04 Sep 2019 13:54:03 -0700 (PDT)
MIME-Version: 1.0
References: <156757720342.20663.3055037033818226992.idtracker@ietfa.amsl.com> <CA+k3eCSH5pkMkqBUmcENSdc3kDB0z3kpZoVGrPdB2hbsXvV8Bg@mail.gmail.com>
In-Reply-To: <CA+k3eCSH5pkMkqBUmcENSdc3kDB0z3kpZoVGrPdB2hbsXvV8Bg@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
Date: Wed, 4 Sep 2019 16:53:52 -0400
Message-ID: <CALaySJJKt7UM7Xq-azgh1eF8hoBwvf+xatdC-PTeSOYvFBsieA@mail.gmail.com>
To: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
Cc: Adam Roach <adam@nostrum.com>, draft-ietf-oauth-resource-indicators@ietf.org, oauth-chairs@ietf.org, The IESG <iesg@ietf.org>, oauth <oauth@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/RS0UZSsguQurHl4P18Zo77BzZnU>
Subject: Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Sep 2019 20:54:05 -0000

> Yeah, with query parameters lacking the hierarchical semantics that the path component has, it is much less clear. In fact, an earlier revision of the draft forbid the query part as I was trying to avoid the ambiguity that it brings. But there were enough folks with some use case for it that it made its way back in. While I am sympathetic to the point you're making here, I'd prefer to not codify the practice any further by way of example in the document.

Is it perhaps reasonable to discourage the use of a query component
while still allowing it?  Maybe a "SHOULD NOT", such as this?:

OLD
      Its value MUST be an absolute URI, as specified by
      Section 4.3 of [RFC3986], which MAY include a query component but
      MUST NOT include a fragment component.
NEW
      Its value MUST be an absolute URI, as specified by
      Section 4.3 of [RFC3986].  The URI MUST NOT include
      a fragment component.  It SHOULD NOT include a query
      component, but it is recognized that there are cases that
      make a query component useful.
END

What do you think?

Barry