At 07:05 27-01-2009, Dave CROCKER wrote: >That section also does not tie the term to a particular tag. So >what is the problem with not changing the section?
In Section 4 of the draft, the UAID is defined as a value which identifies the user or agent. In Section 5, it is specified that the UAID must be the value of the i= tag. In Section 7, the corrected text says that i= The responsible User Agent Identifier. Section 3.5 of RFC 4871 mentions that the d= must be the same or or a parent domain of the "i=" tag (the signing identity, as described below). There is a tie to a particular tag. If you amend Section 3.5, then I cannot tell whether the Signing Identity in Section 1.1 (RFC 4871) refers to the Signing Domain identifier or the User Agent Identifier. The draft discusses about the relationship between the two new identifiers. It introduces an Identity Assessor which is primarily consuming the Signing Domain Identifier. Some people may read that as the Signing Identity in Section 1.1 (RFC 4871) is the de-facto Signing Domain Identifier. The reason we are having this discussion is because of a confusion about "identities". What may be clear to you and the rest of the WG might not be so for implementors who have not been part of the WG. RFC 4871 is on the Standards Track. That document or its successors will be around for quite some time if DKIM is widely deployed. If the goal is to get a technical specification published, then we can choose the easy route. If it is is to create a standard, then things like this may be a problem at some point in future. >The proposed errata changes the text. So I'm not understanding what >point you are making here. The point I am making is that d= was not defined as an identity which is why some people favor i= over d=. Your text changes it to an identifier and by extension an identity as it is consumed by the Identity Assessor. >I don't understand. In my opinion if the changes after a document has been published introduce new definitions and establish relationships, it is not clear on whether it can be approved as an errata. I'm posting the following for the record. There was a discussion about d= and i= tags when DKIM was drafted. It was viewed that in the absence of an i= tag, the d= tag is implicitly taken as the "identity". The i= tag might be used to perform a fine grained assessment. For example, I may decide not to give all DKIM signed mail from a large ESP the same way "weight" by assessing identities instead of the entire domain. That method may not scale. Some people will go for the d= tag as it's easier to manage. In a previous message I mentioned the g= tag and its relationship with the signing identity (i=). Section B.1.1. (the text is informational) elaborates on how it can be used to facilitate restricted authorization. It even mentions that a specific From header field Local-part can be authorized. I understand that the identity from i= is opaque and it is not required to match the identity in any message header fields. If the identity is stable, a verifier could implement a policy to identify that "source". This can be useful if we are thinking in terms of "good" and not "bad" messages. Regards, -sm _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
