> 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