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

John C Klensin <> Thu, 24 April 1997 16:21 UTC

Received: from cnri by id aa01364; 24 Apr 97 12:21 EDT
Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa14591; 24 Apr 97 12:21 EDT
Received: (from daemon@localhost) by (8.8.5/8.8.5) id LAA13262 for uri-out; Thu, 24 Apr 1997 11:31:56 -0400 (EDT)
Received: from (mocha.Bunyip.Com []) by (8.8.5/8.8.5) with SMTP id LAA13257 for <>; Thu, 24 Apr 1997 11:31:52 -0400 (EDT)
Received: from by with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA20647 (mail destined for; Thu, 24 Apr 97 11:31:45 -0400
Received: from ("port 1738" by (PMDF V5.1-8 #21705) with SMTP id <> for; Thu, 24 Apr 1997 11:31:43 -0400 (EDT)
Date: Thu, 24 Apr 1997 11:31:42 -0400
From: John C Klensin <>
Subject: Re: Opaque right hand sides (was: Re: revised "generic syntax" internet draft)
In-Reply-To: <libSDtMail.9704241014.18562.gra@zeppo>
To: Gary Adams - Sun Microsystems Labs BOS <>
Reply-To: John C Klensin <>
Message-Id: <>
Mime-Version: 1.0
X-Mailer: Simeon for Win32 Version 4.1.1 Build (14)
Priority: NORMAL
X-Authentication: none
Precedence: bulk

On Thu, 24 Apr 1997 10:14:32 -0400 (EDT) Gary Adams - Sun 
Microsystems Labs BOS <Gary.Adams@East.Sun.COM> wrote:

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


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.