RE: Alternatives drafts for SUBMITTER identity

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: [email protected]
Anti-Spam and Email Security Research Worksite:
 http://www.elan.net/~william/emailsecurity/