On Feb 10, 2009, at 11:42 AM, Eliot Lear wrote:
While cleaner than the errata Dave Crocker is proposing, this still
changes the definition of the i= parameter intended to represent the
identity on whose behalf the signature was added. It is not
reasonable to assume the i= represents a colliding namespace where the
i= value must be considered undefined. This type of definition
permits the deceptive use of the i= value and is no benefit.
Perhaps rather than:
Absent additional external information outside of the context of g=,
verifiers MUST treat the Local-part contents as opaque strings.
When the i= value exactly matches an email-addresses contained within
signed header fields, it is reasonable to assume this value is
representative of this email-address. Otherwise, the content of the
i= value may represent a token for on whose behalf the message was
signed, where any subdomains below the d= domain as well as the local-
part may not reference valid email-addresses for the domain.
NOTE WELL: This list operates according to