ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] [Fwd: New Version Notification for draft-fenton-dkim-reputation-hint-00]

2009-02-18 19:14:17
-----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