Murray S. Kucherawy wrote: >> -----Original Message----- >> From: Michael Thomas [mailto:m...@mtcc.com]
>> Current implementations are irrelevant. They will completely >> and utterly ignore what is in 4871bis, because they are done >> and work fine. The problem is whether we've introduced problems >> which will cause new implementations to not interoperate with >> current implementations. Given the huge number of changes, it's >> impossible to tell without getting real life data. > I quite agree that there's lots of text that's changing, but I'm > having trouble finding much in the way of actual protocol change. > Most of the changes I can recall have to do with dropping advice > or technical context that was simply incorrect or poorly stated > given the hindsight we now have. Fixing all of that can only > help future implementations. Probably, but with less functionality which will not depict the current DKIM Service Architecture currently supported by implementations. > This is why moving to DS is not allowed if we add stuff, only > if we remove stuff. So far, unless I've missed something, that's > all we've done. But I think the comments are suggesting there really isn't anything new being added from what is not already peppered throughout the document in some form providing non-spec changing justification to include in-scope outputs in the proposed Output Summary. Isn't RFC4871bis should be about codify existing implementations which if you think about it, what the RFC5585 overview has done? Overall, I believe there are four output values that are not new and can be extracted from DKIM: status d= i= From: You can probably write text for From: Since the From: is a mandatory input header bound to the signature, the address or the domain part of the address may be considered output to be consumed by an optional signature signing practice as described in the DKIM Service Architecture [RFC5585]. It would not be untrue and consistent with RFC5585 which is not new. If we allowed to RFC5451 to RFC4871bis, then we should allow a add a more directly DKIM related reference to DKIM Service Architecture [RFC5585] document. Doesn't that fit with DS? -- 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