Jim Fenton wrote:
Dave CROCKER wrote:
For a base spec to say "the value is opaque" and another spec to come along
and
say "I'm announcing the particular, and possibly interesting, scheme that I
follow for creating that value, and I promise to conform to that scheme for
all
such values that I create" is just fine.
The phrase "the value is opaque" could be interpreted to mean that it
MUST NOT have any easily-discerned relationship to other things. So any
message with an Author Signature (as defined in ADSP) would be in
violation of the base spec. If it said "the value MAY be opaque" that's
probably reasonable.
Jim,
There is nothing in the semantics of "opaque" that says the structure can't be
there. It means there is no means of declaring and communicating it that is
part of the standard and hence the presence of any possible structure and
semantics is outside of the spec.
I don't know what "easily-discerned" means, as a technical term talking about
an
interoperable protocol.
What "opaque" means and what the draft Errata text says explicitly is:
"Their sub-structures and particular semantics are not publicly
defined and, therefore, cannot be assumed by an Identity Assessor."
Hmmm. Perhaps that sentence should be added to the definitions of the two
terms, rather than appear in the 'relationship' section?
Use of language like "MAY be opaque" would completely defeat the point behind
explaining that, in terms of technical standards specification in the base
document -- the string has no guaranteed structure or meaning. That's the
essence of opacity. That some encoders might create structure and meaning and
that some assessors might discern it is nicely heuristic. And heuristic ain't
standard.
Anyhow, I think that clarifying text has a meaning that is clear -- if not,
then
we need to fix it -- and certainly quite different from the interpretation you
are suggesting.
Also, can you provide some technical distinction between "easily discerned" and
"not easily discerned" with respect to technical implementation?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html