-----Original Message-----
From: owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Andrew
Newton
Sent: Thursday, September 09, 2004 2:21 PM
To: IETF MARID WG
Subject: clarification on consensus call for compromise
In order to ensure that there are scopes for which there is no known
IPR encumbrance, the co-chairs propose a new document describing
a mail_from scope. The PRA scope would also be one of the scopes
initially
described, as there is clearly sufficient interest in checking pra to
allow it to move forward as one among several scopes (interest being
judged both on public statements and deployed code). An IANA registry
for additional scopes created by Standards Track RFCs would be created.
PRA isn't what I would think of when I think of the word scope. The scope
within which PRA operates is the 2822 message header. Within this scope
there is more than one way to determine which header field is appropriate to
use. PRA is one way. There are others.
If scope were defined by the type of data used to make a determination vice
the method, then I believe there is a limited, bounded set of potential
scopes that can be defined now. Pick different names if you want, but I
think they are:
1. Envelope [2821] ~ mail_from
2. Header [2822] (I would include SUBMITTER here since it's an early look at
this scope)
3. HELO (separate from Envelope because it relates to the MTA and not the
message)
If defined in this manner, then PRA is one potential method to evaluate the
Header scope, but there are others. This would let work on the documents
upon which there is some agreement move forward while preserving the
possibility of eventually reaching rough consensus on an approach for the
Header scope. I put this forward in the hopes that this will meet the
objections of those that strongly object to any standard going forward that
includes PRA as currently licensed.
Done this way, I don't think there's a need for an IANA registry of scopes.
What there will be is an eventual set of RFCs that describe appropriate
methods for evaluating each scope. There may even be more than one per
scope if they are demonstrated to be interoperable.
There is also a need to define the inter-relationship of the different
scopes, but once defined that would be static and dependable. The variable
remaining for future drafts is how to evaluate the individual scopes in
isolation.
Scott Kitterman