On Mon, 27 Sep 2004, Jim Lyon wrote:
William,
SUBMITTER as defined by your draft is a different concept than SUBMITTER
as defined by draft-ietf-marid-submitter-xx. Related, but different.
I disagree especially since I used exactly the same text as in marid-core
and marid-submitter to specify this concept.
Your argument is that all would be well if we dropped the semantics
specified by draft-ietf-marid-submiter, and changed the specs to use the
semantics you supply. While this might make everything fine from your
perspective, it doesn't from mine. I for one decline your invitation.
Your choice...
Your comment that we should give the IETF and implementers a choice
about which to use is exactly on point. The easiest way to do so is to
have different extensions, so that MTAs in conversation know exactly
what is meant by each other.
I do not believe that MTAs would ever specify different SUBMITTER value
based on the text of these drafts, so having them add two different
submitter parameters with exactly same value during MAIL is just not
necessary.
Since the name SUBMITTER is already in use by
draft-ietf-marid-submitter, please choose another name.
If IESG makes recomendation to me at later point to make changes
to semantics and name, I'll of course do so, but it'll not happen
at this time.
---
Again I invite you to reconsider the issues of difference and invite
you to work together on something that will be acceptable to both
FOSS world and those who want to support Microsoft solution while
allowing both to share in common points, concepts and semantics.
I note that when putting this draft together I specifially took parts
of the SenderID that did not have any major technical or IPR issues
as such I consider those to be a subpart that is the closest to having
had consensus of the working group.
Considering that responsible-submitter represents a subpart of former
SenderID concept, it should be fairly easy for you to extend on these
parts and this would allow everyone to benefit from the former MARID
concepts and to have shared common parts (like we have with SPF
record format) instead of trying to force a complete choice.
---
William Leibzon, Elan Networks:
mailto: william(_at_)elan(_dot_)net
Anti-Spam and Email Security Research Worksite:
http://www.elan.net/~william/emailsecurity/