Dave, all,
I think the problem isn't so much that you aren't being precise with
UAID, but rather two fold:
1. UA has an existing connotation that people will grab onto. This in
itself is mnemonically confusing.
2. If you're going to add acronyms, let them be ones that either can be
easily pronounced without having to spell them out. I won't be in SF,
but I'll be listening for just how people handle this one ;-)
Still I'm reticent to suggest a change and have a never-ending semantics
discussion (see q. 2 below about urgency). Here's what I'd like NOT to
have happen. I'd like not to have one term defined in -ter and then
another term defined in -bis. It's okay (and IMHO advisable) to drop
terms, but let's not change them.
As to the chair's request, FWIW I *have* given Dave suggested changes,
and I believe he has accepted some of them. I must admit some confusion
about the process at this point. It seems that there is an outstanding
request of Pasi about whether this draft can proceed. Here are my
questions:
1. If it does proceed, what happens with rfc4871bis? I would expect we
get to have this whole discussion over again because new avenues open
themselves up when we are talking about a revision to the standard, like
deprecating i=, adding r=, and perhaps even eliminating the concept of UAID.
2 . If it doesn't proceed, Dave has expressed urgency about having an
erratum published. I'd like to know if that is still the case, and what
people believe the right approach to be.
3. John has offered to rev. ADSP to handle r= instead of i=. I wonder
what other people think about that.
Eliot
On 3/11/09 12:55 AM, Dave CROCKER wrote:
Jim Fenton wrote:
I have a particular problem with the term "User Agent Identifier (UAID)"
because it doesn't necessarily represent a user agent -- it could, for
example, represent a mailing list manager. I greatly prefer the term
"signing identifier" (which replaces signing identity) because it covers the
range of use cases more completely.
One of the tricks in choosing labels is to make sure they each have useful
meaning, but also that they are different enough to avoid confusion. Labels
are
intended to have mnemonic benefit.
The two labels in the current Errata draft are defined as:
Signing Domain Identifier (SDID)
...
the identity claiming responsibility for the introduction of a message into
the mail stream.
and
User Agent Identifier (UAID)
...
the user or agent on behalf of whom the SDID has taken responsibility.
Note that the latter definition is taken from the existing RFC4871 text:
Identity of the user or agent (e.g., a mailing list manager) on behalf of
which this message is signed
So the UAID term reflects the exact language of RFC 4871 that defines the
identifier: user or agent.
If the term is changed to "signing identifier" it will be semantically wrong
and
mnemonically confusing. Wrong because it's not the domain doing the signing,
per the definition of SDID, and confusing because the term is almost identical
to SDID.
d/
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html