Re: Opaque right hand sides (was: Re: revised "generic syntax" internet draft)

[John C Klensin <[e-mail]>]

On Thu, 24 Apr 1997 10:14:32 -0400 (EDT) Gary Adams - Sun 
Microsystems Labs BOS <[e-mail]> wrote:

> In practice the local-part can be open or closed in the information 
> it conveys. e.g. [e-mail] or [e-mail] .
> For truely opaque handles, additional applications have recorded out
> of band "metadata", such as address book utilities for "real name", etc.

Gary,

In both the email case and the URL analogies, I wasn't 
really referring to opacity in the sense that the 
information was somehow hidden, but in the formal protocol 
sense of what gets to interpret the thing as is moves 
through the network (however that happens).

> I'd be happier to hear "prearrangement" defined in terms of some directory
> service mechanism, and "good sense" in terms of an "algorithm" for catching
> exceptions (e.g.  Martin posted a "try utf8, else try native encoding" scenario
> recently).  Best of all would be a self describing respresentation (wishful
> thinking).

This is another approach: keep the syntax defined and 
non-opaque (again, in the sense above), but provide a set 
of heuristics (try X, figure out if it succeeded, try 
Y,...) for doing the interpretation.   It is a reasonable 
third approach except that many of us have learned, from 
the scars of many battles, to purely loathe protocols that 
have to incorporate heuristics in order to function 
correctly and consider them the absolutely least acceptable 
of all of the alternatives that might, under some scenario, 
be acceptable.

> Today in practice we actually have a <translucent-part> in the URL.  It must
> obey a hierarchical component lookup mechanism to support relative URLs (e.g.,
> /a/b/c, ../d/e/f,etc.). And where latin-1 characters are in use today, the URLs 
> may also contain user friendly characters. If URLs were truely opaque, then
> the perceived inequity in representation would not be considered a problem.

Your "translucent" is my "opaque" iff absolutely no system 
other than the domain listed in the URL needs to process/ 
interpret/ modify/ transform that hierarchical component.  
If we can't impose that condition, then notions of 
safely hiding "funny" characters in the string to which the 
intermediate system doesn't explicitly agree are, well, 
delusional -- something will break, sooner or later.

    john