Field separators, again

[Brad Fitzpatrick]

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.

- Brad


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?
>
>