At 4:23 PM -0700 9/13/04, Daniel Quinlan wrote:
>   Deploying "pra" from when most receivers are unable to
>implement it seems like a major deployment issue.
>

Note that deployment of "pra" resource records is not in
any way encumbered.  Zone maintainers may choose to
include a "pra" scope for their domains as information for
those who choose to check it.  Those MTAs who do choose
to check it will find it at some domains and not at others (just as those
who check for the existence of a MARID record will not find it at some
domains and will find it at others).

There have been a number of assertions that there must be
a mandatory scope if there are multiple scopes.  From my
perspective, there has never been a mandatory scope; it
was always up to the zone maintainer to determine whether
or not to put a record into her zone with the relevant data.
An MTA performing a MARID check against a domain with
no MARID record finds no data; an MTA performing a MARID
check against a domain with a MARID record but with a different
scope finds no relevant data.  From an engineering standpoint,
there are differences between the two (a present record with
a different scope would likely have different caching characteristics,
and would require bare minimum parsing), but many of the
key characteristics are the same.  So going in this direction
may not result in the same level of convergence as might
have occurred with a single scope, but it is an improvement
over where we are now, with engineering consequences
that are similar to the original proposal's.

It may be worth noting also that a fair number of folks said
that they would continue to check SPF records once spfv2/pra records
were available, because they reflected different things.  Having
both scopes available allows those records to transition to the new
RR, and supports those who want to check both as well as
those who wish to check one or the other.

>  > 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.

At least to me, the fact that the PRA algorithm has changed during
the course of the working group's deliberations but the need
for the declaration has not suggests that the original patent
claim covers the *idea* of checking the headers for the most
recent injector into the mail system against a domain-based
record maintained in the forward zone.  Even without that indication,
that is the broadest interpretation of the combination Microsoft
has identified, and many folks have indicated that they wish to
be very cautious in that regard.

That implies to me that other scopes which might later be registered have to
do something other than identify the most recent injector in order to
avoid this particular IPR filing.  Mail_from qualifies now.  If Ned Fred's
assessment is correct, the Sun algorithms would as well, since they
are meant to indicate where to send replies, rather than to identify
the most recent injector.  But they do so by not identifying the
same thing as PRA; anything that *does* the same thing as PRA
may be inferred to be covered by the declaration and license.
If Microsoft makes a different statement, of course, that would
change.  But that is my personal reading of the statements which
have been made.

Have I mentioned this was my personal opinion, said without hats?
It is so.
			regards,
				Ted Hardie