Re: Opacity and mailto: in conflict

It seems to me that, as with the Metadata in URI discussion, it may be 
worthwhile to distinguish what you must not do, what you should not do, 
and what you should avoid if possible. 

Tim Bray writes:

>> For example, in mailto: URIs, the bit
>> before the @ is opaque, the bit after 
>> isn't at all.  HTTP URIs are explicitly 
>> opaque after the host part.

Accepting without debate that the above is in some sense true, I think it 
still pays to discourage people and software from depending on any aspect 
of the URI's particulars, including the scheme, except where necessary.  I 
believe the folllowing is a quote from the metadata in URI document [1] 
(or maybe it's text that I proposed :-)...I'm on an airplane at the moment 
and can't get to the original, only some old email discussing it.)

"People and software using URIs assigned outside of their own authority 
should make as few inferences as possible about a resource based on its 
identity and inferences arising from delegated authority. The more 
dependencies a piece of software has on particular constraints and 
inferences, the more fragile it becomes to change and the lower its 
generic utility."

I believe that this is good advice, regardless of whether the http  and/or 
mailto specs licenses inferences about the DNS names used.  For me, the 
Metadata in URI did a good job of balancing these concerns.  I learned a 
lot from reading it, and I suggest that its formulation be considered in 
clarifying the current discussion of opacity. Thank you!

Noah

[1] http://www.w3.org/2001/tag/doc/metaDataInURI-31

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------

Received on Tuesday, 23 September 2003 17:37:06 UTC