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

Reply via email to