SM wrote:
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]:
SM, I think you made a correlation I did not expect.
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.
That is all I wanted to point out or ask about.
My original text did not try to make any additional Verifier
requirement even though I knew that that is what is required because
DKIM failed or at least inadequately envision the mixed TXT issues.
I'm not saying the text below should be used, but to point out it was
addressed as a DNS management guideline.
The DKIM public key TXT record MUST not be mixed or merged
with other TXT records, i.e. SPF. In addition, make sure other
TXT records with Wildcards do not conflict with DKIM public
key lookups.
I was trying to appease the IETF procedure here but not saying
anything more about a verifier needs to do. But technically I do
agree that we should be more specific and as Murray wrote
"Verifiers should expect this to occur and plan accordingly."
I was just wondering is this was going to be a contentious point.
Again, the posted issue was about the mixed TXT issue. I understood
that DKIM was not specific regarding dealing with mixed TXT. What I
don't know if that was on purpose, a presumption that was well
understood a verifier will look for v=DKIM1 or just fell through the
crack. In any case, I didn't want to post an issue that would add
more requirements, but simply highlight for DNS management people to
not make it difficult for DKIM adopters.
But I think that might not be good enough and we might need to go
ahead and add text about a verifier looking for the right string in a
merged TXT response, just like SPF specification provides for its
implementators.
I am just wondering if you guys (the editors) recognize what appears
to be a technical need conflicted with "IETF procedure" time lines to
get this doc "out the door."
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html