Hi Martin,
On 06/08/2012 10:54 PM, Martin Thomson wrote:
One small comment, that I know the authors are aware of...
On 6 June 2012 13:33, Jonathan A Rees <rees(_at_)mumble(_dot_)net> wrote:
I think using .well-known is a good idea.
I think that using .well-known is a bad idea.
Ok. Opinions vary.
This imposes an unnecessary restriction on the deployment of
resources. /.well-known/ is a space that can only be deployed to by
an administrator of the system. By identifying specifically where the
resource might live (potentially with more than one URL), this avoids
the deployment issue.
Yes, I am aware of the "extensions".
I don't get what you mean above. If its something that
implies a change, I don't know what change.
And:
(a lot of other things)
I agree with all of this, the authority thing, the content-type thing.
All of it. (And none of the rebuttal.)
So the probability of us being completely correct in all this is
probably infinitesimally small, but equal to the probability
of us being completely wrong. That would imply that our rebuttals
are not completely wrong and hence you are equally wrong in
saying "all" and "none" above. (Isn't sophistry great:-)
Anyway, I take that as another +1 for adding ct= to this draft
which is fine. I'm starting to think that might be a good plan.
Let's see if others (dis)agree during the rest of IETF LC.
I also take that as another claim that our use of the
authority field is somehow "wrong" for what seem to me to
be near-mystical reasons, with no compelling argument offered
as to any bad effects at all ensuing. I'm still entirely happy
that our current design is good enough as-is. For me, running
code is a winner in that part of the argument.
Nit:
The draft makes some strange statements about redirects.
Put another way, a server SHOULD return a 30x response when a .well-
known/ni URL is de-referenced.
Requiring a compliant HTTP implementation that follows redirects is
sufficient. What the server does to serve this request is the
server's business. Redirects seem likely, but 2119 language for the
server is not necessary for interoperation.
Good point. I've tweaked that a bit in response to Bjoern's
comments, but your suggestion above is better than what I
have now so I'll work that in. (Actually, is client support
for 3xx mandatory according to 2616? Not sure myself.)
Thanks,
S.