ietf-mxcomp
[Top] [All Lists]

Re: Work plan for Sender ID

2004-09-13 16:23:45

Andrew Newton <andy(_at_)hxr(_dot_)us> writes:

First, the PRA document is not being dropped.  Instead, we are 
proceeding with a document set that includes a non-encumbered (as far 
as we know) scope, "mailfrom", in addition to the "pra" scope.  As we 
stated before, the objection to PRA is based on questions of deployment 
caused by incompatibilities with open source licenses.  However, there 
were also a significant number for responses from participants stating 
that they had no such deployment issues.

Andrew, that is all true, but I think the interoperability of
deployments needs to be considered more strongly.  To use a reverse
analogy, I would not want the IETF to standardize a protocol that was
only reasonably licensed for use in GPL software (like some IBM Linux
patents are).  Deploying "pra" from when most receivers are unable to
implement it seems like a major deployment issue.
 
Second, it does not make sense to discuss alternatives to PRA if those 
alternatives may be reasonably inferred to be covered by the patent 
application (though not necessarily the license) since this working 
group does not wish to discount Microsoft's patent application.
identify the party most recently responsible for injecting the message.

For example, I believe the "fetchmail" alternative is:

a. possibly not encumbered by the Microsoft patent(s) and we could find
   out from Microsoft upon publication of the specification
b. more likely to result in an invalidated patent *if* the patent
   application also covers the algorithm due to prior art

Then, would it not be a good idea to encourge the workgroup to begin
work on additional scopes in parallel with the other scopes?  At worst,
we would decide they were no less encumbered than PRA, but *both* (a)
and (b) would have to go against them for that to be the case.

[...]
This would seem to at least exclude any scopes that use 2822 headers to 

I'm really confused as to why you think that's true.  I think my
reasoning is sound, can you explain why the chairs think a parallel
effort on additional "backup" scopes (which has been suggested by more
than a few people) should be ruled out?  I don't want to delay the
initial release of a "mailfrom" scope, but I also don't think we should
wait to work on "fetchmail" (or whatever) and "helo" until after the
others are done.  By waiting, I think we might paint ourselves into a
corner where the entire specification is rejected because only
"mailfrom" is deemed interoperable by the email community as a whole and
the "pra" scope is too much of a de-facto requirement.

Daniel

-- 
Daniel Quinlan
http://www.pathname.com/~quinlan/


<Prev in Thread] Current Thread [Next in Thread>