spf-discuss
[Top] [All Lists]

RE: Re: [IETF] Allocation of the new RR type for SP F

2004-11-12 12:39:07
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 12 Nov 2004, Hallam-Baker, Phillip spewed into the bitstream:
HP>> [mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com] On Behalf Of 
csm(_at_)moongroup(_dot_)com
HP>> On Thu, 11 Nov 2004, Hallam-Baker, Phillip spewed into the bitstream:
HP>> HP>You can do just as well by setting up your own standards 
HP>> group like 
HP>> HP>we did with the Web consortium when the IETF started to become a 
HP>> HP>threat to the success of the Web.
HP>> 
HP>> It worked too!
HP>
HP>As did the OASIS breakaway from W3C when W3C decided not to do Web services
HP>security on time. The IETF did not form the MARID group because they wanted
HP>to solve the problem, they formed the group to avoid the imminent likelihood
HP>of a breakaway that would challenge their authority.
HP>
HP>The problem with W3C and OASIS is that the membership fees make it a
HP>difficult structure for projects that require open source participation. It
HP>may seem as if the corporate members are trying to close the gate and
HP>exclude the open source community. This is not the case, there are people
HP>who we want to exclude, namely those people who do not have a commitment to
HP>a timely delivery of a finished spec. 

In my experience almost every time there is a closure of process there 
ends up being a closed product also. "Closed" and "Standard" are words 
which do *NOT* go together even in the best of times.

HP>I think that we could even come to an agreement on IPR terms. Divide specs
HP>up into two types, infrastructure specifications and extensions. The SPF
HP>syntax is an infrastructure specification, all parts of the deployment must
HP>understand it to work. The SPF, CSV and PRA interpretations are logically
HP>extensions but you do need to have at least one commonly supported
HP>interpretation.

This is a good idea but I wonder if it was suggested during the private 
negotiations with M$. Do you know?

HP>Everyone agrees that infrastructure specifications must be completely open
HP>and unencumbered. If we could agree that a no-charge RAND license was
HP>sufficient for extensions then everyone can play. There is a structural
HP>incompatibility between ensuring GNU like reciprocity of licensing terms and
HP>the ability to sublicense that we are not going to bridge in the next few
HP>months. I think that we can bridge the problem in time by moving to a
HP>different legal structure entirely - a rule book model. 

Under this "Rule Book Model" would all extensions fall under RAND? The 
thing is.. where software is concerned desired end states are rarely 
unique anymore... the algorithms and their requisite facility are where 
the $ and the competition would and should be. Thus if we "close" or 
limit the playing field by locking up the rights to achieve a particular 
end state we limit competitive implementation and that hurts consumers 
by limiting their right to choose what they believe works best for their 
situation. Extending that thought to the natural conflict between the 
desires of the proprietary and OSS crowds we see that a simple monopoly 
on cash can also monopolize an idea. That is *NOT* a good thing and 
where US law in particular is concerned it surely is not what the 
framers intended in the Constitution.

- --
csm(_at_)moongroup(_dot_)com, head geek
http://moongroup.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFBlRFev6Gjsf2pQ0oRAqfDAJ4//m3BfEv+5aXq4AWwHKl/MYkOLgCfSUwS
PnT0X4orWueqUSwjZbfBAxM=
=m2ZU
-----END PGP SIGNATURE-----


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