Field separators, again
brad at danga.com
Wed Jun 8 14:05:14 PDT 2005
I don't think variable naming will be a huge fight. Propose something
good (and soon) and it'll probably be adopted. So far we've all been
distracted with crypto details to deal with docs/consistency.
On Wed, 8 Jun 2005, Nathan D. Bowen wrote:
> 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?
More information about the yadis