Label replacing Key

[Douglas Otis]

On Sat, 2007-04-07 at 10:30 -0700, Josh Hoyt wrote:
> On 4/7/07, Douglas Otis <dotis at mail-abuse.org> wrote:
> > This would then require all locations that use the term "key" when
> > referring to a field label to be changed to "label"
> 
> -1
> 
> If it needs to be changed, Martin's suggestion of "name" instead is much better.

Okay, but the use of name should be explicitly defined.

The use of just name creates some ambiguity with the "name" attribute.
Review sections 5.2.2. and 7.1.. Or with DNS name in 9.2. and and 12.

The OpenID draft refers to the field name and to the right most labels
of the field name as being synonymous with "key".  This short-hand
should be clearly defined using other terms.

Key is not a term used in w3.org definitions, that tend to use the all
encompassing "keyword" instead.  Key normally refers to keyboard keys,
or cryptographic keys.  Unfortunately "Name" does not permit an explicit
definition due to conflicts within the spec and the ambiguity when using
subordinate naming elements.  

note:

 rfc2822 (2.2.) for email defines roughly the same structure as "field
 name" followed by a "field body".

 rfc1034 (3.1.) for dns defines names as a tree structure of labels.


How about:

Additional terms clarified within the terminology section such as:

---
2.  Terminology
...

Attribute:

 Attributes hold associated properties of HTML elements and may have
 values.  Attribute/value pairs appear before the final ">" of an
 element's start tag. Any number of (legal) attribute value pairs,
 separated by spaces, may appear in any order within an element's
 start tag.
 
Message Parameter:

 Message Parameters are in Field Name-Value Form as a sequence of
 lines terminated by a single newline (UCS codepoint 10, "\n"). Each 
 line begins with  a field name, followed by a colon, and a single value
 or a comma separated list associated with the field name.

Short Name:

 A Short Name is resolved by removing or assuming an "openid" prefix
 of an associated Field Name.
  
---

---
4.1.  Protocol Messages

The OpenID Authentication protocol messages parameters are mappings of
plain-text field names to plain-text field values. The field names and
field values permit the full unicode character set (UCS). When the field
names and field values need to be converted to/from bytes, they MUST be
encoded using UTF-8 (Yergeau, F., “UTF-8, a transformation format of
Unicode and ISO 10646,”) [RFC3629]. 

Messages MUST NOT contain multiple values within the same field name. 

Throughout this document, all OpenID message parameters are REQUIRED,
unless specifically marked as OPTIONAL. 

 
4.1.1.  Field Name-Value Form Encoding

A message in Field Name-Value Form is a sequence of lines. Each line
begins with a field name, followed by a colon, and the field value
associated with the field name. The line is terminated by a single
newline (UCS codepoint 10, \n"). A field name or field value MUST NOT
contain a newline and a field name also MUST NOT contain a colon. 

Additional characters, including whitespace, MUST NOT be added before or
after the colon or newline. The message MUST be encoded in UTF-8 to
produce a byte string. 

A Short Name-Value Form of encoding is used for signature calculation
and for direct responses(Direct Response) to Relying Parties. See
sections 5.1.2, 5.1.2.2, 6.1, 8.2.1, 8.2.2, 8.2.3, 8.2.4, 11.4.2.2. 
 
---

This change requires all locations that use the term "key" when
referring to a field name to be changed to "field name".  When referring
to a derived short name to be changed to "short name".


-Doug