I'll get to John's message later, after I digest it more. I can reply to
this one now.
please explain how you and I can each write applications to that?
>
> **
>
> ** **
>
> You can write applications to that by having the profile chain end, and
> with the contents of the Audience field being completely specified
> somewhere in the profile chain being used.
>
>
In order for that to work, we have to know ("we" being both sides of the
protocol, and also "we" being different implementors of similar
applications) what profile to use.
> I am proposing that there must be a way for someone writing an application
> to know what to use in these fields that will work with your application
> (or will work with a server in the same way as your application does, or
> whatever) *without* having to go to the documentation of your application
> to figure it out.****
>
> ** **
>
> I agree with what I think you mean, but possibly not with how you’re
> saying it. Using the TCP analogy again, in fact, to understand the
> contents of the TCP stream for port 25, one has to go to the documentation
> of the application communicating on port 25. In this case, that
> documentation is RFC 821 and its successors.
>
> Yeh, here's where we're disconnected. One does NOT have to go to the
documentation of the application at all. One has to go to the
specification of SMTP. But one needn't know *anything* about any other
implementations of SMTP: everything you need is in the SMTP spec (including
that it runs on port 25).
If there were a similar thing here, I'd be happy. But if there's a similar
thing here, I don't see it.
I’ll also observe that the working group is also working on a specification
> that enables an OAuth client to dynamically register itself with the
> Authorization Server (draft-ietf-oauth-dyn-reg) *and that that
> registration does declare information about what profile is being used*,
> as John Bradley pointed out in his response. That’s a key piece of the
> whole solution to enable interoperable implementations.****
>
>
It sounds like it is a key piece, and in that case I think that document
needs to come forward along with (or before) the ones that depend on it for
interoperability. Absent something like that, we can't evaluate whether
it's possible to write interoperable implementations of this spec.
> We already do have mechanisms for dynamically declaring what profile is
> being used, and we are using them.****
>
>
"Dynamically declaring," in what sense? Where are those mechanisms
documented?
> I agree with Stephen that we should let this conversation run for a while
> to make sure everyone comes to a common understanding, but ultimately, I
> hope that you’ll withdraw your DISCUSS, because, in fact, interoperable
> implementations can be written by reading the specs used alone.
>
>
I still don't see that that's true (how did those interoperable
implementations resolve the incompletely specified bits?), but, in any
case, don't obsess over the DISCUSS ballot, because it no longer matters:
Stephen has returned the document to the working group, and when it comes
back to IESG Evaluation again I'm sure Stephen will issue a new ballot and
we'll start the process from a clean slate.
Barry
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
