ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)

2009-03-27 09:45:10
Sorry for top-posting, but couldn't we sidestep all of the analysis by simply 
saying that the *syntax* (rather than the *semantics*) matches that of domain 
names? 

Ellen

-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
bounces(_at_)mipassoc(_dot_)org] On Behalf Of Dave CROCKER
Sent: Thursday, March 26, 2009 6:50 PM
To: Jim Fenton
Cc: DKIM IETF WG
Subject: [ietf-dkim] (registered) domain name (Re: errata revision:
opaque)



Jim Fenton wrote:

Just for completeness, I'll point out that some might feel that the
(indirect) statement that the domain name portion of the AUID has domain
name semantics is too strong.  The subdomain portion (the portion, if
any, that is a subdomain of the SDID) doesn't need to be an actual
domain at all.

I'm not sure it's necessary to clutter the definition with this detail,
however.  I'm happy with it the way it is.


Well, I think we should make sure that clarification text doesn't wind up
diverging from the precise semantics of what it is trying to clarify, lest
we
create ambiguity.

So while this might be a pain, I think it's good you caught this issue and
raised it.

I don't claim to know the nuances of this issue well enough.  For
starters, I
did some searching around, which might or might not have improved my
understanding...

The best I can find is two kinds of distinction.  The term "hostname"
refers to
a constraint on use of the full Domain Name namespace.  The term
"registered"
appears to be the way of distinguishing names that appear in the
operational
service, ie, the public database.

That is, the former refers to names and the latter refers to a query
mechanism.

When we say "actual", I think it translates into what the documents I'm
seeing
are calling "registered".

RFC4871's i= text says:

      "The domain part of the address MUST be the same as or a subdomain
of the
value of the "d=" tag"

which does not imply registration or non-registration.  Either appears to
be legal.

I think this does motivate two improvements to the draft language, one for
SDID
and one for AUID:

6.  RFC4871 Section 2.9 Signing Domain Identifier (SDID)
...
     New:
       A single domain name that is the mandatory payload output of
       DKIM and that refers to the identity claiming responsibility for
       introduction of a message into the mail stream.  For DKIM
       processing, the name has only basic domain name semantics; any
       possible owner-specific semantics is outside the scope of DKIM.

    A single domain name -> A single, registered domain name



7.  RFC4871 Section 2.10 Agent or User Identifier (AUID)
...
     New:
       A single domain name that identifies the agent or user on behalf
       of whom the SDID has taken responsibility.  For DKIM
       processing, the name has only basic domain name semantics; any
       possible owner-specific semantics is outside the scope of DKIM.

    A single domain name -> A single, syntactically valid domain name

{{ no, I'm not in love that that wording choice.  /d }}


How much indigestion does this cause?

d/
--

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>