> 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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
