Hi Hector,
At 09:28 16-10-10, Hector Santos wrote:
From an IETF procedural angle. :)
I'll comment on how I read what the WG Chairs said in general
terms. If you believe that the process followed is not fair, you
could discuss the matter with the WG Chairs. I'll quote a message
from a WG Chair [1]:
"You're certainly welcome to file an appeal, if you think there's been
a procedural problem. The first step, of course, is to bring the
issue to the attention of the chairs (which you have), and the next is
to discuss it with the responsible AD (Sean)."
That clearly states whom you can contact to discuss any IETF WG
procedural problem.
"you can increase the chances that people will read your posts if
you post clearly, concisely, and calmly (the three Cs?), and avoid
invective and excess."
That sounds like good advice. If we describe a problem clearly and
concisely, it is easier for the readers to understand our
arguments. It is easier to find a solution if we discuss the matter calmly.
And quoting another message from a WG Chair [2]:
"I think it'd also be good if people could bear in mind that we're
not saving or endangering the planet here - we're moving an RFC
along the standards track by making very very minor changes and
clarifications in a quite controlled fashion. (Most of which will
be ignored by many coders;-)"
The first part explains the work this WG is trying to do. I gather
that you do know that some of the advice in the RFC will be ignored
whatever this WG says; the SHOULD will be reinterpreted to suit
personal taste and some people will read the MUST as legal advice.
But my question was:
If 4871 does not speak of requiring the DKIM client of parsing merged
TXT records to look for its specific inputs, then section 3.6.2.1
needs to make up for this dearth of verifier design information.
I ask because in Murray's suggested text:
"The use of wildcard TXT records in the DNS often result in
something coming back from a query that isn't a valid DKIM key
record
(and ADSP will encounter the same thing). Verifiers should expect
this to occur and plan accordingly."
I like it, but from an IETF standpoint, doesn't the last sentence
imply a 'change of code' thing that we try to avoid here?
There is, for example, a "should" in the text you quoted and some
people may nit about it. Would the above text force a "change of
code" in your implementation of DKIM?
I think the way it is stated was design to avoid this. Right?
Yes, it could be so.
An issue similar to the one in the subject line was raised in 2008 [3].
Regards,
-sm
1. http://mipassoc.org/pipermail/ietf-dkim/2010q4/015022.html
2. http://mipassoc.org/pipermail/ietf-dkim/2010q4/015063.html
3. http://mipassoc.org/pipermail/ietf-dkim/2008q2/010394.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html