URLs and TLS

The current model for URLs and TLS is that a URL either requires TLS to
process or effectively forbids use of TLS to process.  This is obviously
not desirable.  As we add "STARTTLS" commands to protocols this will
change to a situation where the client may use TLS if present, but the URL
is silent on the issue.  I believe this is the most desirable default
action. 

However, this raises the following questions: Is it ever useful to specify
in a URL that some use of TLS is required?  If so, what should the options
be? 

The IMAP and ACAP URL schemes (RFC 2192 and RFC 2244) specify an ";AUTH=" 
parameter on the user name to require a strong SASL mechanism.  I believe
this is desirable as it forces every client to support a minimal level of
security policy at least for the sake of interpreting URLs.  I further
believe that this model is also useful for TLS. 

Here's an initial strawman to shoot at:

If a URL includes a ";TLS=" parameter after the user name, that means TLS
support is required to resolve that URL.  My initial proposal for values
of this parameter is as follows:

anon       Anonymous encryption must be used to prevent passive attacks (?)
integrity  Server-side authentication and integrity protection must be used
privacy    Server-side authentication and encryption must be used
auth       Server and client certs must be used to mutually authenticate
           via TLS (takes precedence over any ";AUTH=" parameter) and
           integrity protect the session.
full       Same as "auth", except encryption must also be used.

Resolution of the URL fails if the security requirements in the URL
can't be met.  The client is free to use a higher level of TLS facilities
than the URL specifies.

I plan to update the IMAP/POP/ACAP TLS spec to amend the IMAP and ACAP URL
schemes appropriately.  I will coordinate with the author of the POP URL
scheme.

Please comment whether or not you think this is a good idea.

		- Chris