Re: URLs and TLS

Let me attempt to explain my motivations better for my TLS in URLs
proposal. 

It is important that the default model is "use TLS if available and
performance constraints permit."  This is the reason there is pressure to
move away from the separate port model which is basically "use TLS if and
only if the resource requires it." 

However, I still think it is useful to be able to express "this resource
requires TLS" in a URL without having to use a new URL scheme and separate
port. First, this prevents the client from going through any unnecessary
negotiation attempt which will fail.  And second, it forces clients to
implement a minimal level of client-enforced security policy (e.g., don't
connect to this resource unless TLS is used).  Remember that URLs are not
always received from an insecure remote site -- they can be configured
locally or through a secure channel and thus are a useful place for some
minimal client-enforced security policy.

Incidentally, this is the exact same justification as for the ";AUTH=" 
parameter in the IMAP and ACAP URL schemes (RFC 2192 & 2244).

I consider this an important case, but not the default case.

The difficult question is to what degree should client security policy for
TLS be expressed in a URL?  The minimal solution, which is not
unreasonable, would be a ";TLS=required" option.  Expressing which cipher
suite or which options within a cipher suite is obviously ridiculous and
should be left up to TLS's in-band negotiation.  I think at least a
distinction between "use TLS client auth" and "don't use TLS client auth" 
is a good idea.  I also like expressing "integrity vs. privacy," as I
proposed previously although I could live without that.  I don't think
going further is useful -- effective key bits is starting to get to a
level of detail that changes quickly with time and is probably best
negotiated via TLS in-band negotiation. 

Does this reasoning pass muster with others here?

FYI, I'm bringing this up because the question was raised in the context
of the POP3 URL scheme which is interesting because it's usually a 
reference to a non-public resource.  However, it's important because it
allows the abstract concept of an inbox resource to be modeled as a URL
(either IMAP or POP).

		- Chris