Field separators, again

[Nathan D. Bowen]

Paul Crowley wrote:

> Brent 'Dax' Royal-Gordon wrote:
>
>>> That would be very inaccurate.  UMAC is *not* a hash algorithm.
>>
>> The word I keep seeing here is "algorithm", so just call the field 
>> "algorithm".
>
> I think we've debated the colour of this particular bike shed more 
> than enough.

We either take the time to name these fields in an unambiguous way now, 
or we take more time in writing the documentation, and every implementor 
takes more time in remembering what "openid.auth" and "openid.secret" mean.

For an outsider, the protocol is unarguably easier to understand if the 
names of variables come from the same shared vocabulary used in the 
specification. Right now, we have no shared vocabulary in the 
specification, so this discussion is happening now, at the protocol 
level, by those who are anticipating how they will describe the protocol 
in a specification.

We're not going to call this value "the auth" in the documentation, so 
why would we name the variable "auth"?

Maybe we'll call it "the token" in the specification regardless of 
whether it's digested, hashed, or signed. Then we might as well call the 
variable "token". Right now, some of us say "token" when talking about 
the plaintext and some say "token" when talking about the digest -- this 
decision would force us to call the plaintext token format "the 
plaintext token format".

 From the standpoint of the protocol alone, this would be a bikeshed 
argument. From the standpoint of the protocol *in tandem with  its 
specification*, I see a strong argument for consistency in naming. 
What's the argument against consistency?