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

Barry Leiba <> Wed, 04 September 2019 20:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 24471120A9B; Wed, 4 Sep 2019 13:54:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.401
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7hjkFp048fe1; Wed, 4 Sep 2019 13:54:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F17FE120E09; Wed, 4 Sep 2019 13:54:03 -0700 (PDT)
Received: by 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;; 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: <> <>
In-Reply-To: <>
From: Barry Leiba <>
Date: Wed, 04 Sep 2019 16:53:52 -0400
Message-ID: <>
To: Brian Campbell <>
Cc: Adam Roach <>,,, The IESG <>, oauth <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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?:

      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.
      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.

What do you think?