Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
Jim Fenton wrote: 1. Introduction. The introduction, particularly paragraphs 2 and 3, assert that the payload (the output of DKIM verification) is only a validated signing domain. The output of DKIM verification is considerably more than that: The Errata draft carefully documents the basis for what it asserts. Where is the documentation that substantiates the claim of broader functionality that you keep making? RFC 4871 somewhat narrowly defines a protocol between the signer and verifier. 4871 defines a means of associating a domain name to a message and conveying it with the message, so that the validator can trust its... validity. 6. SDID definition I am confused by the definition of the SDID as opaque. This makes it sound like it's a pseudonym for the actual signing domain. I can't guess how you are deriving that interpretation, since the use of the term, here, is identical with its typical use in the field, and that's not what it means. 8. Identity Assessor The term is imprecise: it is not assessing an identity but a message. Imprecise?What could be more precise than name of the module that consumes DKIM's primary payload? In any event, there is a difference between assessing the associated identity, versus assessing a message. The former has to do with whether the indicated identity is believed to be a Good Actor or a Bad Actor. The later reviews attributes of the message, such as whether it promises a vigorous sex life, and decides whether it is a legitimate message or an abusive one. Entirely different functions. The latter, of course, has nothing to do with DKIM. The former is the consumer of the identifier DKIM outputs. 9. d= tag definition The corrected text removes the required relationship between the SDID and the AUID, which is perhaps repetitive of information in the i= tag definition, but which we felt important to repeat in the original It was a forward reference, and yes repetitive, and it placed the requirement into the functionality that isn't responsible for making the relationship happen. That is, the requirement is on i=, not on d=. So that's where the specification of the requirement is now placed. Stated differently: d= doesn't care whether i= conforms. d= doesn't really even know about i=. On the other hand, i= is required to relate to d= by being a sub-domain of it. 10. i= tag definition paragraph 2, simple change: OLD: value of the d= tag. NEW: SDID. [There are probably many more places in 4871 where words like this could be changed to the new terminology. Should this update those as well, for clarity?] oops. good catch! (I tried to fully audit the text for exactly this but pretty much never get all the occurrences during such an exercise. Thanks!. = 11. Signing by Parent Domains Small change, also in the original text: OLD: domain of the AUID (i= flag) NEW: domain of the AUID (i= value) Oops. But actually, neither of us got it right. According to 4871, it's a tag. = 12. Relationship between SDID and AUID This is another place where I'm having a problem with the premise that all a verifier needs to output is the SDID. Since all of the finished DKIM documents offer the deliver of an identifier as its only goal, are you suggesting explicitly expanding DKIM's scope? This section is engaging in considerable discussion about the relationship of the SDID and UAID to each other and to other header fields, most of which is not actionable by implementers of the DKIM base specification and in any case is covered elsewhere in the specification. The section is intended to counteract a couple of years of confusion. NEW: The SDID and AUID represent two different identifiers that may be relevant to assessors. Might be, yes. All sorts of things /might/ be relevant to the heuristic evaluation engine. But that's outside the scope of DKIM. DKIM's job is to deliver an identifier. Unlike the SDID, the AUID, or parts of it, represents an assertion on the part of the signer whose meaning is not defined by this specification. parts of it??? assertion? it's an identifier. the only assertion the spec suggests is that it can be used to identify a user -- although that's a bit problematic if it is only a domain name. The assessor MUST consider AUID values in the context of being an assertion: There is no requirement that the assessor see it and certainly no requirement that the assessor process it, nevermind process it in a particular way. The AUID local-part and any subdomain of the SDID used in the AUID are, in general, opaque. Signing domains MAY make specific practices known regarding their use of the AUID, such as that it does represent an actual email address, but in the absence of such assertions MUST NOT be assumed by the assessor. They /may/ do all sorts of things that aren't in the DKIM spec. The fact
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
Hi Eliot, At 00:30 22-03-2009, Eliot Lear wrote: This would be reaching goals for the sake of reaching goals. I would note that an update isn't in the charter at all. I'm not saying don't do it. I'm saying that I would rather Without goals, we don't have a clear path stating what we want to achieve. I don't think that we should reach goals for the sake of reaching them. the group re-examine its goals and decide what the right approach is. Is there a dependency on the proposed changes to get ADSP out the door, for instance? What about the readability of the document series? Can one simply write an update that attempts to cut and paste from the original without adding confusion? I'll skip your question about ADSP for now. Before doing any change, we should take into account its effect on the document series. And now that this is going to be a full blown update or -bis effort, what can be revisited? For instance, the approach I proposed, and many of my objections to the approach Dave and others proposed, was based on the notion that we were discussing an errata document and not a standards-track I-D. If we are to have a standards-track I-D, as I wrote quite some time ago, we have more leeway in changing DKIM. For instance, what is the proper way to deal with i= as a component of the standard? Should we deprecate it? I agree with your point about having more leeway if we are discussing a Standards-Track I-D. There has been discussions about making DKIM leaner by dropping some components. If we drop i=, then we introduce a change that affects ADSP. This, by the way, is one of the problems I have with the chairs' approach. We (those who opposed the draft) were asked to tweak specific lines in the doc, while at the same time being told that the draft's final disposition is being changed by the AD. I won't question the Chairs' approach. I still have other concerns. Ultimately I think there is a downside to being too constraining (the argument that John made earlier), that people will ignore the constraints. For instance, in this case, it's pretty clear that many people will ignore some of the terminology and just take d=, Sender:, From:, and potentially l= and the length, as inputs to identity assessment. And then they will use i= anyway. Saying otherwise, IMHO, *is* premature. Whatever. You're attempting to standardize secret sauce. Here's news: some people's secret sauce tastes bad (I always disliked Burger King's myself). In my opinion, people will take whatever input they view as useful for an assessment. There is nothing we can do about that except to say don't do it. John Levine made a good point about interoperability. Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
At 13:42 20-03-2009, Barry Leiba wrote: What path we take to publish the errata beyond the ID that it is now, and whether the WG is behind publishing it without Pasi's (or the IESG's) approval, are things we'll be discussing in San Francisco and on the mailing list. I hope that when we leave SF we'll have most of the answer to these, which answer we'll confirm on the mailing list. Pasi mentioned that the errata should not be marked as Approved using the errata process. He proposed getting the changes through the normal IETF consensus process, and published using the normal mechanisms we use for publishing updates to IETF work. The agenda for the upcoming meeting has an item of discussion about WG-approved errata vs update RFC vs replacement RFC. It may be better to stop using the term errata or WG-approved errata unless the WG is still considering submitting the ID or a variant of it as a proper errata. Let's call it RFC update. We had a long debate over the last month about RFC 4871. I think that it is premature to consider Draft Standard. I note that SSP and the Overview document were set for WGLC in November 2007 according to the charter. The Deployment document is still work in progress. It would be better for the DKIM WG to meet its goals before starting a discussion about Draft Standard. Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
My apologies for the delay in this; I meant to send this early this week, after getting back in town, but... then I didn't get to it. The chairs appreciate the view that the errata draft makes a lot of changes. Nevertheless, the view that those changes are too great... is quite a minority view. The only concrete objection we've seen in this latest round is about the UAID term, and that appears to be resolved by making it AUID. Beyond that, I've seen no clear objections and no alternative text proposed. Rough consensus appears to be with the errata draft, with the AUID change made to it. So there it is. We have time on the agenda next week for discussion of this, and I think that item will be brief. We have consensus on this text -- and yes, I note that it's given only grudgingly by some. I expect to spend the face-to-face time in getting agreement on the mechanism to proceed (RFC vs non-IESG-approved errata), and in discussing where ADSP is and how to proceed on that. Barry -- Barry Leiba, DKIM working group chair (barryle...@computer.org) http://internetmessagingtechnology.org/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
DKIM Chair wrote: My apologies for the delay in this; I meant to send this early this week, after getting back in town, but... then I didn't get to it. The chairs appreciate the view that the errata draft makes a lot of changes. Nevertheless, the view that those changes are too great... is quite a minority view. The only concrete objection we've seen in this latest round is about the UAID term, and that appears to be resolved by making it AUID. Beyond that, I've seen no clear objections and no alternative text proposed. Rough consensus appears to be with the errata draft, with the AUID change made to it. So there it is. Um, the reason I didn't say anything is because of how the question was phrased. Rather like: would you prefer your poison on the rocks, or straight up?. As I've said many times, the non-Crocker-inserted parts of the errata are not controversial. Nuking his parts in the entirety would be by far the most expeditious and would easily fit within the errata framework. Only having the choice of a poison pill or nothing just plain sucks. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
DKIM Chair wrote: My apologies for the delay in this; I meant to send this early this week, after getting back in town, but... then I didn't get to it. The chairs appreciate the view that the errata draft makes a lot of changes. Nevertheless, the view that those changes are too great... is quite a minority view. The only concrete objection we've seen in this latest round is about the UAID term, and that appears to be resolved by making it AUID. The question of whether the errata draft's changes are too great relates to whether it can be processed using the errata process or whether it requires IETF rough consensus. However, in http://mipassoc.org/pipermail/ietf-dkim/2009q1/011421.html , Pasi ruled that it requires IETF rough consensus because it might differ from the intended consensus when RFC 4871 was approved. So isn't the question of the size of the changes moot? Beyond that, I've seen no clear objections and no alternative text proposed. Rough consensus appears to be with the errata draft, with the AUID change made to it. So there it is. I still owe the list a more extensive set of comments, which I had promised in a few days. I will send those today. We have time on the agenda next week for discussion of this, and I think that item will be brief. We have consensus on this text -- and yes, I note that it's given only grudgingly by some. I expect to spend the face-to-face time in getting agreement on the mechanism to proceed (RFC vs non-IESG-approved errata), and in discussing where ADSP is and how to proceed on that. Based on Pasi's comments, I had thought we were going the RFC route. -Jim ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
OK, now I'm confused. Can someone define IETF rough consensus? The errata had a 2/3 majority after the last round of discussion... does the IETF ever get a better consensus than that? Pasi's point is that what you're quoting is from the DKIM working group only, and, at that, only from some 20 participants or so. There are a lot more people who participate in the IETF, and the normal process of review by the IESG and IETF last call provides the opportunity for many more people to review and comment on the document. Barry ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
From: ietf-dkim-boun...@mipassoc.org [ietf-dkim-boun...@mipassoc.org] On Behalf Of Jim Fenton [fen...@cisco.com] Sent: Friday, March 20, 2009 10:56 AM To: DKIM Chair Cc: DKIM Mailing List Subject: Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata The question of whether the errata draft's changes are too great relates to whether it can be processed using the errata process or whether it requires IETF rough consensus. However, in http://mipassoc.org/pipermail/ietf-dkim/2009q1/011421.html , Pasi ruled that it requires IETF rough consensus because it might differ from the intended consensus when RFC 4871 was approved. So isn't the question of the size of the changes moot? OK, now I'm confused. Can someone define IETF rough consensus? The errata had a 2/3 majority after the last round of discussion... does the IETF ever get a better consensus than that? Based on Pasi's comments, I had thought we were going the RFC route. Given the likely time frame for an updated RFC (-bis or otherwise), I'd like to make really sure that's the only option. Letting the Errata go through as errata and then following up with the -bis seemed like the best option to me... something gets out quickly, and then the more complete update follows. I'm hoping we can have some discussion around this next week. Ellen ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
DKIM Chair wrote: Beyond that, I've seen no clear objections and no alternative text proposed. Rough consensus appears to be with the errata draft, with the AUID change made to it. So there it is. I've placed a revised draft errata at: http://dkim.org/#sign which associates it directly to the original signing spec, RFC 4871. It does the string replacement for AUID and it has a NOTE indicating working group approval. I expect to spend the face-to-face time in getting agreement on the mechanism to proceed (RFC vs non-IESG-approved errata), Right. non-IESG-approved is important phrasing. Folks might realize that anyone can post anything they want under the errata mechanism. The issue with IESG approval affects the status label that is associated with that entry. Anything other than Rejected is likely to serve our purposes, until the change is folded into RFC4871bis. On the matter of whether to issue the Errata under Errata or defer its release further, we should consider how long the delay is likely to be, especially given the unspecified scope of RFC4871bis. Some folks assume that the scope is trivially small, but a bis effort that is seeking Draft status can -- and, IMO, should -- carefuly review the specification and remove what has proven extraneous. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
Siegel, Ellen wrote: OK, now I'm confused. Can someone define IETF rough consensus? The errata had a 2/3 majority after the last round of discussion... does the IETF ever get a better consensus than that? There's a difference between IETF rough consensus versus Working Group rough consensus. The vote we just took measures the latter. To evaluate IETF consensus requires an IETF-wide Last Call and an IESG assessment of the results. Based on Pasi's comments, I had thought we were going the RFC route. Well, he has a preference for /only/ going that route, but he can't actually veto our issuing the Errata under the Errata mechanism. Anyone can post anything they want under the Errata mechanism. Some pretty silly stuff has gotten posted, over the years. What Pasi /can/ do and has done is offer his assessment of the likely IESG decision about the /status/ that would be assigned to the Errata. In particular, he has a reading of the IESG rules for Errata which says that anything that is controversial cannot be approved. Unfortunately, I think his interpretation of the relevant rule's text is reasonable, based on the latest explanation he provided. I think it's a bad rule and should be changed, but dealing with that is different from debating his interpretation. In other words, I think he's providing a reasonable interpretation of a bad rule and that, for now, we have to live with it. The alternative labels available to our Errata, if issued through the Errata mechanism, are rejected and hold. In my view, hold, with text in the Errata that states there is working group consensus, is sufficient. Not ideal, but sufficient. It provides an official publication channel sooner, rather than later. Given wg approval, we aren't likely to see the label rejected get assigned... Given the likely time frame for an updated RFC (-bis or otherwise), I'd like to make really sure that's the only option. Letting the Errata go through as errata and then following up with the -bis seemed like the best option to me... something gets out quickly, and then the more complete update follows. +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
On Mar 19, 2009, at 11:22 PM, DKIM Chair wrote: The chairs appreciate the view that the errata draft makes a lot of changes. Nevertheless, the view that those changes are too great... is quite a minority view. The only concrete objection we've seen in this latest round is about the UAID term, and that appears to be resolved by making it AUID. Beyond that, I've seen no clear objections and no alternative text proposed. Rough consensus appears to be with the errata draft, with the AUID change made to it. So there it is. There have been suggested changes to the text that was made previously. There did not seem to be a reason to repeat the same objections and proposed changes when there did not appear to be agreement on going forward with portions of the errata that change prior definitions. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
On Mar 20, 2009, at 9:55 AM, Barry Leiba wrote: Pasi's point is that what you're quoting is from the DKIM working group only, and, at that, only from some 20 participants or so. There are a lot more people who participate in the IETF, and the normal process of review by the IESG and IETF last call provides the opportunity for many more people to review and comment on the document. The concern seemed more related to making definitional changes to an an RFC within an errata. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
At 09:41 20-03-2009, Siegel, Ellen wrote: OK, now I'm confused. Can someone define IETF rough consensus? The errata had a 2/3 majority after the last round of discussion... does the IETF ever get a better consensus than that? The Standards Process requires that a proposed standard be reviewed by the IETF community to establish whether it has the consensus. This Working Group, for example, is only a subset of the IETF community. The Working Group can be used to to determine whether it is worth asking the IETF community to review a proposal. However, it cannot act as a substitute for the IETF community. There isn't a formal definition of IETF rough consensus. From the Tao: a simple version is that it means that strongly held objections must be debated until most people are satisfied that these objections are wrong Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
Dave CROCKER wrote: Based on Pasi's comments, I had thought we were going the RFC route. Well, he has a preference for /only/ going that route, but he can't actually veto our issuing the Errata under the Errata mechanism. Anyone can post anything they want under the Errata mechanism. Some pretty silly stuff has gotten posted, over the years. I believe that what Dave is suggesting is an end run around the IESG. In which case, I suggest that the working group insist on s/our/my/g; above so that it has similar status. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
Thanks, all, for the clarification. I read too quickly and missed the semantic distinction between IETF consensus was and IETF working group consensus. Ellen -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of SM Sent: Friday, March 20, 2009 2:39 PM To: DKIM Mailing List Subject: Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871- errata At 09:41 20-03-2009, Siegel, Ellen wrote: OK, now I'm confused. Can someone define IETF rough consensus? The errata had a 2/3 majority after the last round of discussion... does the IETF ever get a better consensus than that? The Standards Process requires that a proposed standard be reviewed by the IETF community to establish whether it has the consensus. This Working Group, for example, is only a subset of the IETF community. The Working Group can be used to to determine whether it is worth asking the IETF community to review a proposal. However, it cannot act as a substitute for the IETF community. There isn't a formal definition of IETF rough consensus. From the Tao: a simple version is that it means that strongly held objections must be debated until most people are satisfied that these objections are wrong Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
Mike says... Dave CROCKER wrote: Based on Pasi's comments, I had thought we were going the RFC route. Well, he has a preference for /only/ going that route, but he can't actually veto our issuing the Errata under the Errata mechanism. Anyone can post anything they want under the Errata mechanism. Some pretty silly stuff has gotten posted, over the years. I believe that what Dave is suggesting is an end run around the IESG. In which case, I suggest that the working group insist on s/our/my/g; above so that it has similar status. Mike, I take what you're saying to mean that you don't think the working group is behind an end run around the IESG, and that the errata should not be saying that it is. What path we take to publish the errata beyond the ID that it is now, and whether the WG is behind publishing it without Pasi's (or the IESG's) approval, are things we'll be discussing in San Francisco and on the mailing list. I hope that when we leave SF we'll have most of the answer to these, which answer we'll confirm on the mailing list. I think we need the high-bandwidth discussion, with Pasi in the room and responding, to get this point resolved in a way that doesn't leave everyone waving scimitars at everyone else. We need to be discussing things productively as we go into final processing of ADSP and into 4871bis and Draft Standard consideration. (I'm going to try to get a conference call set up and use Skype and a microphone to allow remote participants to talk. I know we've failed at that before, but I want to try again.) So while I'm on the cooperation and productivity bit To everyone: Please say what you mean calmly and clearly, so there's less chance of misunderstanding or the taking of offense where none was meant. And please don't mean offense, either, of course. Digs, snarkiness, and passive-aggressiveness won't keep us moving forward. Barry -- Barry Leiba, DKIM working group chair (barryle...@computer.org) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
Barry Leiba wrote: Mike says... Dave CROCKER wrote: Based on Pasi's comments, I had thought we were going the RFC route. Well, he has a preference for /only/ going that route, but he can't actually veto our issuing the Errata under the Errata mechanism. Anyone can post anything they want under the Errata mechanism. Some pretty silly stuff has gotten posted, over the years. I believe that what Dave is suggesting is an end run around the IESG. In which case, I suggest that the working group insist on s/our/my/g; above so that it has similar status. Mike, I take what you're saying to mean that you don't think the working group is behind an end run around the IESG, and that the errata should not be saying that it is. Close. I'm saying that it toes the line of completely inappropriate for a _working group_ to consider an end run around the IESG, and that we ought not consider that as an option for the working group. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
Barry Leiba wrote: So while I'm on the cooperation and productivity bit To everyone: Please say what you mean calmly and clearly, so there's less chance of misunderstanding or the taking of offense where none was meant. And please don't mean offense, either, of course. Digs, snarkiness, and passive-aggressiveness won't keep us moving forward. Barry, what prompted this? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
On March 10, 2009, I wrote: DKIM Chair wrote: To those who voted against draft-ietf-dkim-rfc4871-errata: given, now, that we will be using draft-ietf-dkim-rfc4871-errata to move forward, and the other choices are off the table, can you accept draft-ietf-dkim-rfc4871-errata as written? If not, will you post specific changes, in OLD/NEW format, that would make it acceptable to you? Acceptable changes must keep the sense of the draft-ietf-dkim-rfc4871-errata document with regard to the new terminology. I can do that, but it will probably take a few days. Here are the rest of my comments on the draft. My comments are based on draft-ietf-dkim-rfc4871-errata-02 with the additional change from UAID to AUID. Perhaps user or agent should also change to agent or user but I'm neutral on that. 0. Change the title to RFC 4871 Update if it is not being processed using the errata process per Pasi's comments. = 1. Introduction. The introduction, particularly paragraphs 2 and 3, assert that the payload (the output of DKIM verification) is only a validated signing domain. The output of DKIM verification is considerably more than that: there are a great many values, such as the list of signed header fields, that may be useful to an assessor and that must be made available to the assessor if the verifier is to be as interoperable with as many assessors as possible. Furthermore, not requiring a verifier to output unknown tag/values makes DKIM non-extensible: What's the point of adding new tag/value definitions if all the verifier is going to output is the SDID? RFC 4871 somewhat narrowly defines a protocol between the signer and verifier. It does not define the semantics of everything that DKIM might convey; that was left for the overview and/or operations documents. To say that RFC 4871 has the potential for non-interoperable interpretations of how DKIM operates is to criticize the specification for something that is out of its scope. Suggested change: Replace everything beginning with paragraph 2 of the introduction with the following (and delete the remainder of the introduction): NEW: Hence, DKIM has a signer that applies a signature to a message, a verifier that confirms the signature, and DKIM interfaces with an assessor what consumes the validated signing information. This document attempts to clarify the meaning of identifier fields appearing in the DKIM signature to arrive at a more consistent use of these fields by verifiers. = 6. SDID definition I am confused by the definition of the SDID as opaque. This makes it sound like it's a pseudonym for the actual signing domain. The fact that it's possible to look up information about the SDID using DNS doesn't seem opaque to me. OLD: A single, opaque value that is the mandatory payload output of DKIM NEW: A single value that is a mandatory payload output of DKIM = 7. AUID definition Portions of the AUID are opaque, but not the whole thing because it has to have a specified relationship with the SDID. I would also clarify that there is always an AUID, even if it isn't explicitly specified in the signature and takes its default value. OLD: A single, opaque value that identifies the user or agent on behalf of whom the SDID has taken responsibility. It is specified in Section 3.5. NEW: A single value that identifies that agent or user on behalf of which the SDID has taken responsibility. The AUID has the syntax of an email address, although the local-part and any subdomain of the SDID which is used are opaque values which may not actually exist nor have any relationship with other identifiers in the message. It is specified in Section 3.5. The AUID takes the default value specified if it is not explicitly present in the signature. = 8. Identity Assessor The term is imprecise: it is not assessing an identity but a message. Suggest replacing this name with just assessor as is used in the Introduction. = 9. d= tag definition The corrected text removes the required relationship between the SDID and the AUID, which is perhaps repetitive of information in the i= tag definition, but which we felt important to repeat in the original document for emphasis. The narrative about conventions and semantics does not belong in the normative text describing the tag, and I'm not clear what it's trying to say in any case. The text also repeats much of the wording in the definition of SDID about claiming responsibility and such. NEW: The SDID of the signing entity (plain-text; REQUIRED). This is the domain that will be quieried for the public key. The SDID MUST be the same as or a parent of the domain in the AUID (the i= value, as described below) and MUST meet the requirements for parent domain signing described in Section 3.8. When presented with a signature that does not meet these requirement, verifiers MUST consider the signature invalid. = 10. i= tag definition paragraph 2,
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
So while I'm on the cooperation and productivity bit To everyone: Please say what you mean calmly and clearly, so there's less chance of misunderstanding or the taking of offense where none was meant. And please don't mean offense, either, of course. Digs, snarkiness, and passive-aggressiveness won't keep us moving forward. Barry, what prompted this? Nothing terribly special... mostly two points: 1. The way Mike made his point left lots of room for people to take it in different ways, and I wanted to remind folks to be clear. 2. Over time, various participants have angered various others, often leading to offline (and sometimes online) complaints. I just wanted to use the opportunity to remind everyone that snark doesn't help, even if it momentarily makes one feel good. The reminder wasn't addressed specifically. Barry ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
On Fri, 20 Mar 2009 16:42:30 -0400 Barry Leiba barryle...@computer.org wrote: Mike says... Dave CROCKER wrote: Based on Pasi's comments, I had thought we were going the RFC route. Well, he has a preference for /only/ going that route, but he can't actually veto our issuing the Errata under the Errata mechanism. Anyone can post anything they want under the Errata mechanism. Some pretty silly stuff has gotten posted, over the years. I believe that what Dave is suggesting is an end run around the IESG. In which case, I suggest that the working group insist on s/our/my/g; above so that it has similar status. Mike, I take what you're saying to mean that you don't think the working group is behind an end run around the IESG, and that the errata should not be saying that it is. What path we take to publish the errata beyond the ID that it is now, and whether the WG is behind publishing it without Pasi's (or the IESG's) approval, are things we'll be discussing in San Francisco and on the mailing list. I hope that when we leave SF we'll have most of the answer to these, which answer we'll confirm on the mailing list. I think we need the high-bandwidth discussion, with Pasi in the room and responding, to get this point resolved in a way that doesn't leave everyone waving scimitars at everyone else. We need to be discussing things productively as we go into final processing of ADSP and into 4871bis and Draft Standard consideration. (I'm going to try to get a conference call set up and use Skype and a microphone to allow remote participants to talk. I know we've failed at that before, but I want to try again.) So while I'm on the cooperation and productivity bit To everyone: Please say what you mean calmly and clearly, so there's less chance of misunderstanding or the taking of offense where none was meant. And please don't mean offense, either, of course. Digs, snarkiness, and passive-aggressiveness won't keep us moving forward. Then in the spirit of plain speaking: I do think that the current draft attempts to alter IETF consensus via the erata process in a way that is inappropriate. While I think that Mike's objection was formulated in a way that unfortunately strucutred around personality, I agree that the content to which he was referring should be dropped from an eratum and addressed when the RFC is revised. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
The output of DKIM verification is considerably more than that: there are a great many values, such as the list of signed header fields, that may be useful to an assessor and that must be made available to the assessor if the verifier is to be as interoperable with as many assessors as possible. We seem to have a fairly basic disconnect here. As far as I'm concerned, an assessor has better things to worry about than the internal details of the signature. Trying to reverse engineer or guess what the signer had in mind would be a hopeless swamp even if it were desirable. Sure, it's possible to put on a worthless signature that leaves out crucial headers, but signers who do so won't get a very good reputation so the problem should be self-limiting. There's no existing installed base of inept signers we have to work around, and it would be a poor idea do anything that would allow crummy signatures to appear to work. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
John Levine wrote: The output of DKIM verification is considerably more than that: there are a great many values, such as the list of signed header fields, that may be useful to an assessor and that must be made available to the assessor if the verifier is to be as interoperable with as many assessors as possible. We seem to have a fairly basic disconnect here. As far as I'm concerned, an assessor has better things to worry about than the internal details of the signature. Trying to reverse engineer or guess what the signer had in mind would be a hopeless swamp even if it were desirable. Sure, it's possible to put on a worthless signature that leaves out crucial headers, but signers who do so won't get a very good reputation so the problem should be self-limiting. There's no existing installed base of inept signers we have to work around, and it would be a poor idea do anything that would allow crummy signatures to appear to work. If assessors can't be bothered, then how will reputation systems know the difference? You really can't have it both ways. In any case, this is a false dilemma; it's not just crummy signatures at issue. And what you call a hopeless swamp, I call RFC 4871. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
We seem to have a fairly basic disconnect here. As far as I'm concerned, an assessor has better things to worry about than the internal details of the signature. Trying to reverse engineer or guess what the signer had in mind would be a hopeless swamp even if it were desirable. ... If assessors can't be bothered, then how will reputation systems know the difference? Sorry, but I have no idea what the antecedent to this question is supposed to be. The difference between what and what? Assessors know whether a message is signed, and if it has valid signature(s), the domain(s) that signed them. All that other stuff in the signature is implementation details. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
John R. Levine wrote: We seem to have a fairly basic disconnect here. As far as I'm concerned, an assessor has better things to worry about than the internal details of the signature. Trying to reverse engineer or guess what the signer had in mind would be a hopeless swamp even if it were desirable. ... If assessors can't be bothered, then how will reputation systems know the difference? Sorry, but I have no idea what the antecedent to this question is supposed to be. The difference between what and what? You wrote: Sure, it's possible to put on a worthless signature that leaves out crucial headers, but signers who do so won't get a very good reputation so the problem should be self-limiting. There's no existing installed base of inept signers we have to work around, and it would be a poor idea do anything that would allow crummy signatures to appear to work. If assessors can't be bothered to assess the supposedly self-limiting implementation details, then reputation systems can not take them into account. By definition. Assessors know whether a message is signed, and if it has valid signature(s), the domain(s) that signed them. All that other stuff in the signature is implementation details. RFC 4871 gives no precise definition of what an assessor can use to make whatever decisions it wants to draw from the message *and* the signature(s). That you have a particular use case in mind that doesn't care about implementation details does not and should not imply that that is the only valid use of DKIM information. That is why the errata is so wrong headed. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
If assessors can't be bothered to assess the supposedly self-limiting implementation details, then reputation systems can not take them into account. By definition. Right. That's a feature. It's not my job to work around or even identify crappy signatures. If there's junk in your signed mailstream, I'm not likely to accept your mail, regardless of how it got there. I have no interest whatsoever in trying to pick apart signatures and guessing which ones are particularly gnarly and which ones are sort of froody. They're either valid or they aren't, per 4871. RFC 4871 gives no precise definition of what an assessor can use to make whatever decisions it wants to draw from the message *and* the signature(s). Right. That's why we're clarifying it. R's, John PS: So if if I'm wrong and assessors are going to use implementation details, how do you expect them to use the fact that this message has a signed Cleverness header? Please be specific. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
On 3/20/09, Michael Thomas m...@mtcc.com wrote: John R. Levine wrote: Assessors know whether a message is signed, and if it has valid signature(s), the domain(s) that signed them. All that other stuff in the signature is implementation details. RFC 4871 gives no precise definition of what an assessor can use to make whatever decisions it wants to draw from the message *and* the signature(s). That you have a particular use case in mind that doesn't care about implementation details does not and should not imply that that is the only valid use of DKIM information. That is why the errata is so wrong headed. +1 -- hls ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
John Levine wrote: The output of DKIM verification is considerably more than that: there are a great many values, such as the list of signed header fields, that may be useful to an assessor and that must be made available to the assessor if the verifier is to be as interoperable with as many assessors as possible. We seem to have a fairly basic disconnect here. As far as I'm concerned, an assessor has better things to worry about than the internal details of the signature. Trying to reverse engineer or guess what the signer had in mind would be a hopeless swamp even if it were desirable. On the other hand, we definitely don't have enough information about assessors to know what information they need. Saying that the SDID is the only thing they can depend on getting from the verifier is too constraining. Sure, it's possible to put on a worthless signature that leaves out crucial headers, but signers who do so won't get a very good reputation so the problem should be self-limiting. There's no existing installed base of inept signers we have to work around, and it would be a poor idea do anything that would allow crummy signatures to appear to work. The worthless signature may not have been so worthless if one of the header fields in question wasn't present at the time of signing, but was added later. There have been proposals to convey some information relating to assessment (for example, Jon Callas's suggestion at http://mipassoc.org/pipermail/ietf-dkim/2009q1/011104.html ) by putting it in a separate header field and signing it. Are you suggesting that whether that header field is signed or not is irrelevant to the assessor? -Jim ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
Folks, Two days later. Still haven't seen any other issues raised with the draft. d/ Dave CROCKER wrote: Folks, Question to the working group... DKIM Chair wrote: To those who voted against draft-ietf-dkim-rfc4871-errata: given, now, that we will be using draft-ietf-dkim-rfc4871-errata to move forward, and the other choices are off the table, can you accept draft-ietf-dkim-rfc4871-errata as written? If not, will you post specific changes, in OLD/NEW format, that would make it acceptable to you? Unless I've missed or misread other postings, the only item lodged, so far, has been Jim Fenton's suggest that the UAID acronym be replaced, and discussion about that is proceeding. Are there other changes to draft-ietf-dkim-rfc4871-errata being proposed? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
Dave, all, I think the problem isn't so much that you aren't being precise with UAID, but rather two fold: 1. UA has an existing connotation that people will grab onto. This in itself is mnemonically confusing. 2. If you're going to add acronyms, let them be ones that either can be easily pronounced without having to spell them out. I won't be in SF, but I'll be listening for just how people handle this one ;-) Still I'm reticent to suggest a change and have a never-ending semantics discussion (see q. 2 below about urgency). Here's what I'd like NOT to have happen. I'd like not to have one term defined in -ter and then another term defined in -bis. It's okay (and IMHO advisable) to drop terms, but let's not change them. As to the chair's request, FWIW I *have* given Dave suggested changes, and I believe he has accepted some of them. I must admit some confusion about the process at this point. It seems that there is an outstanding request of Pasi about whether this draft can proceed. Here are my questions: 1. If it does proceed, what happens with rfc4871bis? I would expect we get to have this whole discussion over again because new avenues open themselves up when we are talking about a revision to the standard, like deprecating i=, adding r=, and perhaps even eliminating the concept of UAID. 2 . If it doesn't proceed, Dave has expressed urgency about having an erratum published. I'd like to know if that is still the case, and what people believe the right approach to be. 3. John has offered to rev. ADSP to handle r= instead of i=. I wonder what other people think about that. Eliot On 3/11/09 12:55 AM, Dave CROCKER wrote: Jim Fenton wrote: I have a particular problem with the term User Agent Identifier (UAID) because it doesn't necessarily represent a user agent -- it could, for example, represent a mailing list manager. I greatly prefer the term signing identifier (which replaces signing identity) because it covers the range of use cases more completely. One of the tricks in choosing labels is to make sure they each have useful meaning, but also that they are different enough to avoid confusion. Labels are intended to have mnemonic benefit. The two labels in the current Errata draft are defined as: Signing Domain Identifier (SDID) ... the identity claiming responsibility for the introduction of a message into the mail stream. and User Agent Identifier (UAID) ... the user or agent on behalf of whom the SDID has taken responsibility. Note that the latter definition is taken from the existing RFC4871 text: Identity of the user or agent (e.g., a mailing list manager) on behalf of which this message is signed So the UAID term reflects the exact language of RFC 4871 that defines the identifier: user or agent. If the term is changed to signing identifier it will be semantically wrong and mnemonically confusing. Wrong because it's not the domain doing the signing, per the definition of SDID, and confusing because the term is almost identical to SDID. d/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
Folks, Question to the working group... DKIM Chair wrote: To those who voted against draft-ietf-dkim-rfc4871-errata: given, now, that we will be using draft-ietf-dkim-rfc4871-errata to move forward, and the other choices are off the table, can you accept draft-ietf-dkim-rfc4871-errata as written? If not, will you post specific changes, in OLD/NEW format, that would make it acceptable to you? Unless I've missed or misread other postings, the only item lodged, so far, has been Jim Fenton's suggest that the UAID acronym be replaced, and discussion about that is proceeding. Are there other changes to draft-ietf-dkim-rfc4871-errata being proposed? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
Dave CROCKER wrote: One of the tricks in choosing labels is to make sure they each have useful meaning, but also that they are different enough to avoid confusion. Labels are intended to have mnemonic benefit. [...] User Agent Identifier (UAID) ... the user or agent on behalf of whom the SDID has taken responsibility. Note that the latter definition is taken from the existing RFC4871 text: Identity of the user or agent (e.g., a mailing list manager) on behalf of which this message is signed So the UAID term reflects the exact language of RFC 4871 that defines the identifier: user or agent. There's a significant difference between User Agent (as in Mail User Agent) and user or agent. It is wrong to give the impression that the MUA is doing the signing, or that the MUA is being identified by this. If the term is changed to signing identifier it will be semantically wrong and mnemonically confusing. Wrong because it's not the domain doing the signing, per the definition of SDID, and confusing because the term is almost identical to SDID. I'm open to other ideas, but signing identifier is a lot less semantically wrong than user agent identifier. And I hadn't proposed a mnemonic yet (SID is over used). 4871 currently uses signing identity which isn't excessively lengthy; signing identifier is more precise terminology and I'm not sure it needs an acronym either. -Jim ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
Dave CROCKER wrote: Are there other changes to draft-ietf-dkim-rfc4871-errata being proposed? I believe the Chairs requested that the other, non-controversial, errata be incorporated into this draft. Is that (editorial) work ongoing? -Jim ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
Jim Fenton wrote: Dave CROCKER wrote: Are there other changes to draft-ietf-dkim-rfc4871-errata being proposed? I believe the Chairs requested that the other, non-controversial, errata be incorporated into this draft. I think we suggested it as an option rather than requested. Is that (editorial) work ongoing? I think it'd be great if Dave were willing to do that, but I could understand if he'd rather not. S. -Jim ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
Jim Fenton wrote: Dave CROCKER wrote: Are there other changes to draft-ietf-dkim-rfc4871-errata being proposed? I believe the Chairs requested that the other, non-controversial, errata be incorporated into this draft. Is that (editorial) work ongoing? No, they didn't: DKIM Chair wrote: ... To those who voted against draft-ietf-dkim-rfc4871-errata: given, now, that we will be using draft-ietf-dkim-rfc4871-errata to move forward, and the other choices are off the table, can you accept draft-ietf-dkim-rfc4871-errata as written? If not, will you post specific changes, in OLD/NEW format, that would make it acceptable to you? Acceptable changes must keep the sense of the draft-ietf-dkim-rfc4871-errata document with regard to the new terminology. That does not mention a bis and it does not cite the items sitting in the RFC Editor's Errata queue. I think there is some confusion about the resolution of draft-ietf-dkim-rfc4871-errata with the development of RFC4871bis. And while there has been some reference to a bis effort, it's been consistently -- and I believe correctly -- kept separate. Let's resolve the draft-ietf-dkim-rfc4871-errata content issues and then move on to focus on a bis effort. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
Stephen Farrell wrote: Is that (editorial) work ongoing? I think it'd be great if Dave were willing to do that, but I could understand if he'd rather not. I'm fine with continuing to edit the draft-ietf-dkim-rfc4871-errata for the working group. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
On Wed, 11 Mar 2009 08:54:35 -0700 Dave CROCKER d...@dcrocker.net wrote: Folks, Question to the working group... DKIM Chair wrote: To those who voted against draft-ietf-dkim-rfc4871-errata: given, now, that we will be using draft-ietf-dkim-rfc4871-errata to move forward, and the other choices are off the table, can you accept draft-ietf-dkim-rfc4871-errata as written? If not, will you post specific changes, in OLD/NEW format, that would make it acceptable to you? Unless I've missed or misread other postings, the only item lodged, so far, has been Jim Fenton's suggest that the UAID acronym be replaced, and discussion about that is proceeding. Are there other changes to draft-ietf-dkim-rfc4871-errata being proposed? I won't propose any. I don't have time to do a proper job of rewriting it. I think it alters the IETF conensus view via errata and adds needless complexity. Silence or lack of change proposals does not equate to thinking the current draft is good. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
Scott Kitterman wrote: I won't propose any. I don't have time to do a proper job of rewriting it. I think it alters the IETF conensus view via errata and adds needless complexity. Silence or lack of change proposals does not equate to thinking the current draft is good. +1 I think it's rather premature to presuppose that we have any sort of consensus about any -bis changes as the people that those changes affect are most likely completely clueless that a -bis document is even on the working group's agenda. AFAIK it is not even in the _charter_, so how could a more casual but interested party be expected to know? At the very least, it seems to me that this decision can wait for the meeting next week to get a sense of the room. Rechartering and an update to the DKIM wg web page also seems like a prerequisite to making -bis changes. After all, this working group was all but winding down a month or two ago. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
This thread has been split from Dave's long note. Here's what I want to try, in order to convert the majority vote into what Stephen and I would be happy to call rough consensus. I have not discussed this yet with Stephen, in the interest of getting it out here more quickly, so he may feel free to object to this and whack me over the head (as Dave has already done). As I said in my note summarizing where we are, the working group vote between the a/b/c/d choices has taken the simpler errata changes out of the mix and given us draft-ietf-dkim-rfc4871-errata as the path forward. There were, though, enough votes against it for the chairs to consider it significant, so: To those who voted against draft-ietf-dkim-rfc4871-errata: given, now, that we will be using draft-ietf-dkim-rfc4871-errata to move forward, and the other choices are off the table, can you accept draft-ietf-dkim-rfc4871-errata as written? If not, will you post specific changes, in OLD/NEW format, that would make it acceptable to you? Acceptable changes must keep the sense of the draft-ietf-dkim-rfc4871-errata document with regard to the new terminology. Barry -- Barry Leiba, DKIM working group chair (barryle...@computer.org) http://internetmessagingtechnology.org/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
I can do that, but it will probably take a few days. But for clarification, is the new terminology cast in stone? I have a particular problem with the term User Agent Identifier (UAID) because it doesn't necessarily represent a user agent -- it could, for example, represent a mailing list manager. I greatly prefer the term signing identifier (which replaces signing identity) because it covers the range of use cases more completely. I'd say it's a fair proposal, and we'll see where it goes. What I meant was that, for example, it won't work to propose text changes that roll back the terminology changes altogether. Or something like that. A proposed change with a reason behind it gives everyone something to work with and to decide, one way or t'other. Barry ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
DKIM Chair wrote: To those who voted against draft-ietf-dkim-rfc4871-errata: given, now, that we will be using draft-ietf-dkim-rfc4871-errata to move forward, and the other choices are off the table, can you accept draft-ietf-dkim-rfc4871-errata as written? If not, will you post specific changes, in OLD/NEW format, that would make it acceptable to you? Acceptable changes must keep the sense of the draft-ietf-dkim-rfc4871-errata document with regard to the new terminology. I can do that, but it will probably take a few days. But for clarification, is the new terminology cast in stone? I have a particular problem with the term User Agent Identifier (UAID) because it doesn't necessarily represent a user agent -- it could, for example, represent a mailing list manager. I greatly prefer the term signing identifier (which replaces signing identity) because it covers the range of use cases more completely. -Jim ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
Jim Fenton wrote: I have a particular problem with the term User Agent Identifier (UAID) because it doesn't necessarily represent a user agent -- it could, for example, represent a mailing list manager. I greatly prefer the term signing identifier (which replaces signing identity) because it covers the range of use cases more completely. One of the tricks in choosing labels is to make sure they each have useful meaning, but also that they are different enough to avoid confusion. Labels are intended to have mnemonic benefit. The two labels in the current Errata draft are defined as: Signing Domain Identifier (SDID) ... the identity claiming responsibility for the introduction of a message into the mail stream. and User Agent Identifier (UAID) ... the user or agent on behalf of whom the SDID has taken responsibility. Note that the latter definition is taken from the existing RFC4871 text: Identity of the user or agent (e.g., a mailing list manager) on behalf of which this message is signed So the UAID term reflects the exact language of RFC 4871 that defines the identifier: user or agent. If the term is changed to signing identifier it will be semantically wrong and mnemonically confusing. Wrong because it's not the domain doing the signing, per the definition of SDID, and confusing because the term is almost identical to SDID. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
