Jim Fenton wrote:
> > Hmm -- back in IETF73 we seemed to agree (at least according to the
> > email below) that guessing is, while probably not a good idea,
> > possibly less bad than the alternative:
> >
> > http://mipassoc.org/pipermail/ietf-dkim/2008q4/010820.html
>
> Hmm, that's right; I had f
Jim Fenton wrote:
> I guess I should be paying more attention to the dkim-deployment
> drafts.
>
> RFC 4871 is very explicit about the meaning of the g= value. Last
> paragraph of section 3.2:
>
>Tags that have an empty value are not the same as omitted tags. An
>omitted tag is treated
Mark Martinec wrote:
> I don't think just dropping the errata works for me.
>
> The draft-ietf-dkim-deployment-11 says:
>
>If a DKIM verifier finds a selector record that has an empty "g"
>field ("g=;") and it does not have a "v" field ("v=DKIM1;") at its
>beginning, it is faced with
I'm getting the impression that this debate is starting to be about
proving points rather than making progress. In the interest of getting
this document moving forward, I have entered the following RFC editor note:
Please add a new paragraph to Section 1, after the first paragraph:
The rea
We still have couple of unprocessed errata for RFC 4871 left.
Let's try to handle an easy one first:
http://www.rfc-editor.org/errata_search.php?eid=1385
To me it looks like Section 3.6.2.2 does already specify the
necessary details:
Strings in a TXT RR MUST be concatenated together before us
The IETF Last Call for dkim-deployment ended on Monday. According
to my notes, we got the following comments:
http://mipassoc.org/pipermail/ietf-dkim/2009q4/012914.html
http://mipassoc.org/pipermail/ietf-dkim/2009q4/012916.html
http://www.ietf.org/mail-archive/web/ietf/current/msg59701.html
http
Tony, Ellen, Phillip, Dave and others,
I've finally done my AD review for draft-ietf-dkim-deployment-09
(and yes, it took a bit longer than it should have...). I have
couple of minor comments (below), but I've asked the secretariat
to start IETF Last Call, so you can consider these as the
first la
Specification of reputation systems would be in violation of the
charter, but e.g. the recently completed dkim-overview draft does
talk about the "boundary" between DKIM and assessment systems.
Certainly the intent of this text (rephrasing the Introduction in
draft-ietf-dkim-rfc4871-errata) was *
Jim Fenton wrote:
> Dave has proposed a change to the rfc4871-errata draft in response to a
> concern from the IESG. Can you clarify what concern the IESG has this
> is attempting to address? I'll repeat my original question below since
> you may have missed it.
It's attempting to address Culle
The IETF Last Call for dkim-overview has ended. According to my notes,
we got only a single comment, from IANA (no IANA actions, all OK):
https://datatracker.ietf.org/idtracker/draft-ietf-dkim-overview/comment/94762/
I've placed this draft on the agenda of the May 21 IESG telechat.
We didn't get
Dave CROCKER wrote:
> pasi.ero...@nokia.com wrote:
>
>> - I think introducing clear terminology for the identity/identities
>> (or identifier/identifiers) "output by DKIM" would make DKIM
>> significantly easier to understand, and would be useful in this
>&
Dave Crocker wrote:
> 2. The RFC Editor publishes rules for Errata. So does the IESG.
> You indicate that Pasi is refusing to process
> draft-ietf-dkim-rfc4871-errata-02 for two reasons: It introduces new
> terminology and it makes too many changes. Neither of these is
> included (or excluded)
Tony, Dave, Phillip and others,
I've finally gone through dkim-overview-10. Basically, it looks good,
but I have some suggestions on how to make it more accessible to
readers who don't already know what DKIM is, plus some minor nits:
- I think introducing clear terminology for the identity/identi
Douglas Otis wrote:
> Statements that imply the i= value is always OPAQUE prevents its
> utilization for highlighting purposes with respect to identity
> assurances, even when there is an exact match and this value could
> be said to not be opaque. This also seems to conflict with the
> defined us
Dave Crocker wrote:
> Pasi,
>
> Please reconsider your suggestion.
>
> This Errata effort developed out of real and immediate community
> need. Your opening comment indicates an understanding that the
> problem does exist. In other words, it does fix a specific, actual
> problem with the current
I think the proposed text changes would make RFC 4871 significantly
easier to understand, and less prone to multiple interpretations.
(I don't have a strong opinion about the content, though -- but
a clear spec is better than an ambiguous one.)
However, it seems we're not just fixing simple erro
John Levine wrote:
> > The terms "Valid Signature from an Author Domain" and "Author
> > Signature" are very easily confused.
>
> I think we're all confused at this point. If the From: address
> were a...@example.com and the signature had i...@example.com, that
> sure looks like a valid signatur
(Continuing from my previous email):
The terms "Valid Signature from an Author Domain" and "Author
Signature" are very easily confused. If I understood Doug's comments
right, he's essentially proposing making these two terms identical.
That would certainly simplify things, but since the WG h
I've gone through the IETF last call comments for ADSP.
I've understood that the major issues raised by Doug have been
discussed in the WG earlier, and the WG reached rough consensus
on them.
If that's the case, I have no problem with it. However, after reading
Doug's comments together with R
19 matches
Mail list logo
