-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
But i= isn't opaque, not as a whole anyway. It has the syntax of an
email address, and the domain part of that address MUST be the same
as or a subdomain of the d= value.
I think I want to say just a few things about "opaque" as a term of
art, and perhaps this needs to flow back into the errata or something.
When I was an API designer, we would often return from the system to
the application an "opaque" identifier.
Usually, the opaque identifier was a pointer, either to an internal
data structure, or another pointer that was the actual pointer to the
structure. People who would write code could (and did) use it as a
pointer, reach into the data structures and do stuff. This worked, but
was unsupported. If the underlying private data structure changed, the
code that used the opaque identifier would break.
The relatively few times the opaque identifier wasn't a pointer, it
was an array index into structures or pointers to structures.
If you consider C's standard IO, you have "file pointers" that are
indeed pointers into implementation-dependent things, or "file
descriptors" that are array indexes.
These are opaque identifiers.
People can, and do, use these things but the code that does is highly
implementation and version dependent.
So must it be with i=.
There's nothing wrong with a receiver looking at (e.g.) Yahoo!'s i=
and noting that it is exactly an email address and processing it. But
if Yahoo! changes to using a hex string that is the internal user ID,
the receiver must cope.
All that opacity means is that the receiver is on their own when they
peer into it. The majority of the time, i= will be precisely an email
address, just as the majority of the time a C "FILE *" will be a
pointer to a data structure. It's just not guaranteed to be portable
nor invariant.
Jon
-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.6.3
Charset: US-ASCII
wj8DBQFJnJWfsTedWZOD3gYRAuFAAKDxqyZwy4ubZclDgojuQ+pF2vQttwCeP8r6
HkV7k8bTQN1GqWKG9mnnNtg=
=S4/w
-----END PGP SIGNATURE-----
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html