Subject: [ietf-dkim] plain-text and g=

From: Tony Hansen <[email-masked]>
Date: Tue, 11 Jul 2006 18:30:51 -0400

I misspoke in the meeting about there being no ABNF for plain-text. It
turns out that there is no use of the term plain-text in any ABNF
production. So there does not need to be an ABNF for plain-text.

However, the term "plain text" is not defined anywhere.

Furthermore, the tags that *are* marked as requiring plain text all use
productions that do not permit utf8.

For example, g= is defined in terms of dot-atom:

   key-g-tag       = %x67 [FWS] "=" [FWS] key-g-tag-lpart
   key-g-tag-lpart = [dot-atom] ["*"] [dot-atom]

which is taken from 2822 and is defined to include only the following:

dot-atom        =       [CFWS] dot-atom-text [CFWS]

dot-atom-text   =       1*atext *("." 1*atext)

atom            =       [CFWS] 1*atext [CFWS]

atext           =       ALPHA / DIGIT /
	"!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" /	"-" / "/" /
	"=" / "?" / "^" / "_" / "`" / "{" / "|" / "}" / "~"

If we want to extend g= to permit utf8, or any other tag values, we'll
need to do that explicitly and choose a different set of ABNF leaf tokens.

	Tony Hansen
	[email-masked]
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Eric Allman <[email-masked]>
Date: Wed, 12 Jul 2006 08:43:40 -0400

Tony, thanks for doing the leg work.

I can see us going three directions here:

(1) Drop the references to 2822 and define at least the terminals 
ourselves to allow UTF-8 characters.  This makes us "EAI aware" and 
gives a warning to DKIM implementers to think about the future, but 
does separate us a bit more than we might like from 2822, and has the 
strange side effect of allowing DKIM to include characters in the 
header that "can't" be there according to 2822.

(2) Leave the references to 2822 but add an informative note about 
being flexible in how you interpret tag values.  This keeps the 
connection to 2822 and still gets the information across, but does 
perhaps create a bit of confusion of what an implementation should 
really do if it sees 8-bit characters in the values.

(3) Leave it as-is.  EAI is going to have to extend 2822 in order to 
allow UTF-8 in the headers, and so implicitly all standards that 
inherit from 2822 will have to be adjusted accordingly.  This is 
probably the most formally correct approach, and does "future proof" 
us from the day when we all give up on UTF and switch to URE 
(Universal Rational Encoding) (ha!), but is the least helpful for 
current DKIM implementers.

I lean toward (2).

Any comments?

eric

--On July 11, 2006 6:30:51 PM -0400 Tony Hansen <[email-masked]> wrote:

> I misspoke in the meeting about there being no ABNF for plain-text.
> It turns out that there is no use of the term plain-text in any ABNF
> Furthermore, the tags that *are* marked as requiring plain text all
> use productions that do not permit utf8.
>
> If we want to extend g= to permit utf8, or any other tag values,
> we'll need to do that explicitly and choose a different set of ABNF
> leaf tokens.
>
> 	Tony Hansen
> 	[email-masked]