On Sat, 2007-04-07 at 10:30 -0700, Josh Hoyt wrote: > On 4/7/07, Douglas Otis <[EMAIL PROTECTED]> 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 _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs