I went ahead with this in -07.

On Wed, Sep 4, 2019 at 3:07 PM Brian Campbell <bcampb...@pingidentity.com>
wrote:

> Thanks Barry, I kinda like it. Although I'm a bit hesitant to make a
> change like that at this stage. I guess I'd be looking for a little more
> buy-in from folks first. Though it's not actually a functional breaking
> change. So maybe okay to just go with.
>
> On Wed, Sep 4, 2019 at 2:54 PM Barry Leiba <barryle...@computer.org>
> wrote:
>
>> > 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
>>
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to