Ah, I am starting to getting your point. I was assuming that the text was just dealing with this particular flow, possibly a separate standalone document as David R. suggested. On the other hand, you are starting to think of it as a generic "include" mechanism, are you?
I agree that would be actually quite useful. If the idea gets support in the community I am all for it. =nat On Fri, Jun 4, 2010 at 4:21 PM, Manger, James H < [email protected]> wrote: > Nat, > > >>> All the request parameters MUST be provided through request file. > >>"All" doesn't make much sense if params can still appear in the URI, and > override the file. > > > What about this: > > > > Request parameters SHOULD be provided through request file. > > If it is perfectly legitimate to include some params in the user-url, and > those override the same params in the file, then there is no point requiring > the overridden params to be present in the file with a MUST or even a > SHOULD. What about saying: > "A shorter user-uri is more likely to avoid mobile browser URI length > limits, and to reduce bandwidth and latency for mobile traffic. > Consequently, as many parameters as practical should be provided through the > request file, instead of directly in the user-uri." > > > > >>> The "request_url" MUST be provided in the URL. > >> This isn't really a "MUST", its just indicates if you are using this > feature (this "flow"). > > > It is a MUST. Without it, you just cannot obtain other required > parameters. > > Without it you are using "normal" OAuth2 (all the params in the user-uri), > which is fine and shouldn't violate a MUST. > If this mechanism is defined in a separate spec then I guess it could be a > MUST for that spec. Even in that case, though, servers that support > request_url shouldn't reject interactions with all the params directly in > the user-uri. > > > > >> Would be good to say "A request_url param MUST NOT be provided in a > request file". Probably good to add "A request file MUST be rejected if it > includes a request_url param". > > > request_url param MAY be provided in a request file. It is just its > identifier. It probably is best to be there. > > It sounds like you are assuming the request_url in the file is the same as > the request_url in user-uri that led to the file. The server treats > request_url in user-uri as a trigger to include more params, but the server > treats request_url in the file as merely a name for the file (which it > ignores because there is nothing for the server to do with such a name). > > This is inconsistent. > > request_url should be an include mechanism, regardless of where it appears. > If we only want to support an include mechanism in user-uri, and not > supported nested includes, then we should explicitly say request_url MUST > NOT appear in a file. > > -- > James Manger > -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
