RE: URI scheme listing for httpsy

I think I get the idea, but there are some confusing parts
of your draft. You say that 'the host is merely a hint',
but it isn't optional, and there's no way to locate
the resource without the host. So this isn't consistent
with the ordinary technical definition of a 'hint'.

The draft, as written, looks like it is modifying the
https scheme, taking over all uses of https with
a '*' in the 'userinfo' field. With HTTPS, you say
'The *key_id@ portion of the URL MUST be ignored',
but this sounds like you're making normative change
to how the https URL is supposed to work. I'm not
sure why you need to do that. 

Suppose you do intend to take over a chunk of the
'userinfo' space. Consider using something more
distinctive than '*', like '*waterken:<key>*'

http://*waterken:<key>@host/path

I think you need to work out the deployment and
upgrade steps more clearly. Why do you ever need
'httpsy'? Anyone starting deployment would
never use a 'httpsy' URI because so few clients
would know what to do with it. So web sites might
start using the compatible form (using http: or
https:), but, since that works well enough, why
would anyone ever deploy something that understands
'httpsy'?

In general, the uses of MUST and SHOULD in your
document aren't conventional; e.g., when you say
'The address of a nameserver SHOULD be much more
constant than that of a server', it's hard to know
for whom this language should be normative.

Larry

Received on Sunday, 17 August 2003 12:41:55 UTC