Subject: [ietf-dkim] Let's avoid "opaque"

From: Jim Fenton <[email-masked]>
Date: Sun, 08 Feb 2009 20:38:45 -0800

I have been hearing quite a bit of discussion and confusion on this list
about the word "opaque".  Since the stated intent of an erratum or
revision to the specification is to remove a point of confusion, it's
important not to introduce a new one.

I strongly suggest that we not use the word "opaque" in 4871bis, or in
an erratum if things go that way.  Instead, state exactly what the
significance of various fields is, e.g., "the local-part of the i= value
MAY have no significance to other than the signer, and may not be
depended upon by the verifier in the absence of other information
provided by the signer".

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

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 08 Feb 2009 21:58:18 -0800

Jim,

We've had quite a bit of confusion about a number of different things. Focusing 
on a particular term might be missing the underlying confusion(s).

In any event, if you do not like particular language in the current draft, 
please suggest specific changes.  You give one example of specific text, but 
don't anchor it to a particular place in the Errata draft and you do not 
indicate what other changes you believe should be made.

In addition, you do not indicate that the word opaque is being used incorrectly, 
suggesting that the confusion might be more with the underlying issue than with 
the term.

Indeed:

Jim Fenton wrote:
>      Instead, state exactly what the

specifies different semantics than are currently in the draft.

So you are not merely replacing a vocabulary term with an expanded form of text 
that means the same thing.

d/
-- 

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

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 08 Feb 2009 23:13:14 -0800

Jim,

I'm confused why you think that debating a vocabulary term should take 
precedence over getting consensus on the semantics. If you want the semantics 
changed, surely that is far more important than a particular word used to 
describe the semantics that you want changed.

In general, document modification works best with proposals for what should be 
added, removed or modified.  So far, you are saying remove all uses of a 
particular word, but are not offering specific replacements, thereby leaving a 
void in the document, should your proposal succeed.

Group discussion of document changes proceeds best when tied to specifics, and 
in particular specifics that leave the document complete.

Please suggest specific changes.  And a generic "remove all uses of word x" is 
not really a specific change, since it leaves the document incomplete.  (Try 
reading the existing text after only removing all occurrence of word x and see 
when the document still makes sense.  It won't.)

d/

Jim Fenton wrote:
> I'd like to see if there is consensus for my proposal to remove the term
> before suggesting specific language.
> 
> I do expect that my language has different semantics that are currently
> are in the draft.  But I don't think that the semantics of the language
> in the current draft are well enough understood by many to see that
> distinction.
> 
> -Jim
> 
> Dave CROCKER wrote:
>> Jim,
>>
>> We've had quite a bit of confusion about a number of different things.
>> Focusing on a particular term might be missing the underlying
>> confusion(s).
>>
>> In any event, if you do not like particular language in the current
>> draft, please suggest specific changes.  You give one example of
>> specific text, but don't anchor it to a particular place in the Errata
>> draft and you do not indicate what other changes you believe should be
>> made.
>>
>> In addition, you do not indicate that the word opaque is being used
>> incorrectly, suggesting that the confusion might be more with the
>> underlying issue than with the term.
>>
>> Indeed:
>>
>> Jim Fenton wrote:
>> So you are not merely replacing a vocabulary term with an expanded
>> form of text that means the same thing.
>>
>> d/
> 

-- 

   Dave Crocker

---

From: Jim Fenton <[email-masked]>
Date: Sun, 08 Feb 2009 22:53:34 -0800

-Jim

---

From: Hector Santos <[email-masked]>
Date: Mon, 09 Feb 2009 02:15:48 -0500

+1.  Thank god someone had the nerve to speak up.

Beside the fact it is being used in conflictive ways,  I just love it 
when a "new word" gets into ones vocabulary that they are compelled to 
use it even when not 100% understood to the layman.  Just consider, if 
a reader has to take the time to googled it to attempt to understand 
its usage in DKIM, then most likely, its the wrong technical term to 
use in the first place.

IMO, same is true with the word "Consume"  makes one feel that 
something is being "eaten up," never to be used again by seen and used 
by anything else, i.e. its not passed on. The fact is, it is passed on 
to whoever may want to see it and it may be passed on more than once, 
therefore it isn't "consumed", it is utilities, processed, etc, but 
not "consumed."

In my opinion, as far as I am concern as a potential implementation I 
need to know

1) Is I=/D= the same in RFC 4871 or are we trying to say that I= 
domains can in fact be DIFFERENCE than whats defined as the 
requirement in RFC 4871?

2) Resolve this MUST convey concept. It is conflictive with other
relaxed semantics regarding i= described in the specs.

Keep in mind, IMO, is DKIM is going to succeed, be widely adopted, its 
not going to be 100% used the same way across the board.  Others may 
not want to convey anything about backend passive, transparent DKIM 
verification methods to users - this is especially true if the sender 
is anonymous, there is no WHITE/REPUTATION info to fall back on.

IMV, this is where POLICY concept plays an important role.  It is the 
policy that is going to help receivers to dissemination the OBVIOUS 
FRAUD from the rest, and folks, if we can not dissemination the 
OBVIOUS FRAUD, then I ask, where is the payoff for the high value 
exclusive domains who may want to use DKIM in 1 to 1 communications 
with users.

I hate to rehash anything, but we need to keep the eye on the prize 
here - FRAUD DETECTION.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: Hector Santos <[email-masked]>
Date: Mon, 09 Feb 2009 02:31:41 -0500

> when the document still makes sense.  It won't.)

Of course not, rewording is required.

Mr. Fenton provided a clear cut, easy to understand (IMO) single 
statement:

   "the local-part of the i= value MAY have no significance to
    other than the signer, and may not be depended upon by the
    verifier in the absence of other information provided by the
    signer".

Mr. Otis clearly highlight the delima:

   What problem do you see this over-extended opaque assertion
   solving, especially when it creates a problem where none had
   existed.

You can not reach reasonable consensus if you continue to plead 
ignorance of those you feel do not matter here.

-- 
Sincerely

Hector Santos, CTO

---

From: [email-masked] (Wietse Venema)
Date: Mon, 9 Feb 2009 08:01:00 -0500 (EST)

> before suggesting specific language.

I suggest: you propose a concrete replacement, and if it is better,
then we adopt it.

	Wietse

---

From: Al Iverson <[email-masked]>
Date: Mon, 9 Feb 2009 09:27:18 -0600

> I suggest: you propose a concrete replacement, and if it is better,

+1

I personally think "opaque" is an appropriate term. It's a pretty
common use of the term. However, I am likely going to be fine with
suggested replacement text.

Regards,
Al

-- 
Al Iverson on Spam and Deliverability, see http://www.spamresource.com
News, stats, info, and commentary on blacklists: http://www.dnsbl.com
My personal website: http://www.aliverson.com   --   Chicago, IL, USA
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Eliot Lear <[email-masked]>
Date: Mon, 09 Feb 2009 17:03:33 +0100

Can someone please explain how something can be opaque and yet processed 
in g=, as SM has pointed out?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 09 Feb 2009 08:10:03 -0700

> I suggest: you propose a concrete replacement, and if it is better,

If it helps, Jim, I'd support a better term -- if anyone can think of one. 
But the linguistic centers of my brain would rather be writing poetry, so 
anything I'm likely to come up with would be even /more/ opaque than "opaque."

(Fuliginous?  Turbid?  Otissian?)

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Mon, 9 Feb 2009 21:47:33 +0530

On Mon, Feb 9, 2009 at 9:33 PM, Eliot Lear <[email-masked]> wrote:
> Can someone please explain how something can be opaque and yet processed in
> g=, as SM has pointed out?

Opaque to OTHERS.  As long as the g= and i= strings match, that's just
fine.  I see no reason why the receiver must do other than a string
match to see that the two are the same.

   g=  Granularity of the key (plain-text; OPTIONAL, default is "*").
       This value MUST match the Local-part of the "i=" tag of the DKIM-
       Signature header field (or its default value of the empty string
       if "i=" is not specified), with a single, optional "*" character
       matching a sequence of zero or more arbitrary characters
       ("wildcarding").  An email with a signing address that does not
       match the value of this tag constitutes a failed verification.
       The intent of this tag is to constrain which signing address can
       legitimately use this selector, for example, when delegating a
       key to a third party that should only be used for special
       purposes.  Wildcarding allows matching for addresses such as
       "user+*" or "*-offer".  An empty "g=" value never matches any
       addresses.

-- 
Suresh Ramasubramanian ([email-masked])
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Mon, 9 Feb 2009 21:01:31 +0530

> suggested replacement text.

+1 for opaque. People seeking alternatives are cordially requested to
consult a copy of Websters Thesaurus.

srs

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 09 Feb 2009 08:57:35 -0800

> in g=, as SM has pointed out?

1.  g= provides a literal string for comparison.  It does not specify any other 
syntax or semantics for the string.  Hence, the string cannot be interpreted. 
It can only be compared, which means the string is opaque.

2.  g= is for a mechanism that is internal to the dkim signature processing 
engine.  It does not impart any syntax or semantics if the target string is 
output to a client of the signature validation process. To the module that 
consumes that string, as output of DKIM validation, the string remains opaque.

DKIM imparts and communicates no details about the meaning of the string, nor 
its relationship to other identifiers.

d/

-- 

   Dave Crocker

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Mon, 9 Feb 2009 22:53:11 +0530

On Mon, Feb 9, 2009 at 10:41 PM, Jim Fenton <[email-masked]> wrote:
> def. 2a: Hard to understand or explain : UNINTELLIGIBLE
> def. 2b: OBTUSE, STUPID
>
> I didn't find your suggestion helpful, Suresh.

I am sure there are more appropriate synonyms to opaque available?
I'm not calling you stupid, and I am sure you realize that.

srs

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Mon, 9 Feb 2009 23:16:21 +0530

That said, I guess we just do a yes or no vote on shipping this
current version of the errata doc.

And then working towards a -bis sometime later once the dust has settled.

-srs

---

From: Jim Fenton <[email-masked]>
Date: Mon, 09 Feb 2009 09:11:47 -0800

> consult a copy of Websters Thesaurus.

I don't have a copy of Webster's Thesaurus, but Webster's New Collegiate
Dictionary lists synonyms (in ALL CAPS) in a couple of its definitions.

-Jim

---

From: Al Iverson <[email-masked]>
Date: Mon, 9 Feb 2009 12:03:41 -0600

> I didn't find your suggestion helpful, Suresh.

Suresh actually has a point, and I think the thesaurus backs it up.
The use of the data may be static, and perhaps receivers will find it
a use for it, but the field contents as observed by the receiver, is
likely to obtuse or unintelligible. Opaque.

This is a mountain being lovingly crafted out of a molehill..........I
don't really care if, at the end of the day, "opaque" is replaced with
another term or a different description. But, just for the record,
this is what opaque means in common usage in technology applications.
Google is your friend: http://en.wikipedia.org/wiki/Magic_cookie

Regards,
Al

---

From: Al Iverson <[email-masked]>
Date: Mon, 9 Feb 2009 12:25:02 -0600

> depended upon by the verifier in the absence of other information

After further review of the existing wording, and having posted at
least one cite to the word "opaque" used in a similar context, I'd
like to propose that we move forward with the wording as-is.

Dave, this strikes me as ready to go...My thought is that it's
appropriate to give a last call for feedback and then move it forward.

Regards,
Al Iverson
ExactTarget

---

From: Roland Turner <[email-masked]>
Date: Tue, 10 Feb 2009 13:01:59 +0800

+1 for opaque; the current usage is consistent with its widespread usage
in other contexts.

- Roland

-- 
  Roland Turner | Product Manager, RealMail | BoxSentry Pte Ltd
  3 Phillip Street, #13-03 Commerce Point, Singapore 048693
  Mob: +65 96700022 | Skype: roland.turner | Fax: +65 65365463
  [email-masked] | www.boxsentry.com