Re: Consensus Call for draft-housley-tls-authz
On Mon, 9 Mar 2009 14:20:45 -0700, Hallam-Baker, Phillip pba...@verisign.com said: Phillip 1) Patents happen, get over it. The problem is not that patents happen. The problem is IETF's position when patents happen. Clearly stated in http://www.fsf.org/news/reoppose-tls-authz-standard is that granted rights are inadequate. ... RedPhone has given a license to anyone who implements the protocol, but they still threaten to sue anyone that uses it. ... While this may be fine in your world of big proprietary business, it is a severe problem for FOSS. Phillip 2) Very few patents are so essential that they are worth more than Phillip interoperability. The bar is not that of being so essential. Phillip 3) It follows that the only allowable patents are on non-essential aspects When a protocol is contaminated with patents it no longer serves the real purpose of a standard destined protocol. That of creating a level playing field for interaction of all participants. About 10 years ago, I brought all of this up in the context of patent contaminated WAP protocols in: The WAP Trap An Expose of the Wireless Application Protocol http://www.freeprotocols.org/PLPC/100014 Some of that same patent related logic applies in this case. Mohsen BANAN -- http://mohsen.banan.1.byname.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call for draft-housley-tls-authz
On Tue, 10 Mar 2009 12:04:13 -0700, SM s...@resistor.net said: SM At 11:21 10-03-2009, Richard M Stallman wrote: RMS In the cases where an experimental RFC is useful, how is it more RMS useful for the Internet than publication of the same information in RMS some other way? Long ago, before search engines, perhaps interested RMS people would not have found it elsewhere, but that isn't true now. SM The RFC Series predates the IETF. It is a repository of technical SM information and, hopefully, it will still be around when I am no SM longer around. I don't know how search engines will be years from now SM but there is one thing I know. As long as the tradition is preserved, SM the Internet community will have a mechanism to publish technical SM information. Note here that the following are independent of one another: - Publication (RFC or other wise) - Patent contamination - Standards designation My remarks here are limited to Publication. I'll follow up with a separate note on what the solution is for the process as a whole. RFC publication in fact is more complex than SM describes. With RFC publication there is a real part and there is an imaginary part. The imaginary part is what is the process as advertised (in RFC-2026). That access to RFC publication is fair and reasonable and that the RFC series are a source for the Internet technical community at large. The real part is that IETF is now fully dominated by interests of proprietary big business. In practice the role of the RFC Editor for documents coming from outside of the IETF/IESG/IAB has been reduced to that of a glorified clerk of the IESG. Much of the Internet technical community has chosen to be outside of the IETF. And RFC publication is now mostly an IETF work group game. Plenty of concrete examples for both the real and the imaginary. In my case: http://mohsen.banan.1.byname.net/PLPC/120026 http://www.esro.org/documents/baseProtocols.html http://www.emsd.org/communicationRecord/rfc2524Publication/maillist.html In D. J. Bernstein's case: http://cr.yp.to/proto/rfced.html And all of those were in the cases of patent free protocols. Now in this particular case of a patent contaminated protocol extension why would non-RFC publication be adequate? ...Mohsen ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call for draft-housley-tls-authz
On Wed, 11 Mar 2009 14:35:36 -0700, Mohsen BANAN lists-i...@mohsen.banan.1.byname.net said: Mohsen Now in this particular case of a patent Mohsen contaminated protocol extension why would non-RFC Mohsen publication be adequate? I omitted the important not in that sentence. I meant: Now in this particular case of a patent contaminated protocol extension why would not non-RFC publication be adequate? I am asking as to why it should be published as an RFC (any status) when we know to begin with that it is a patent contaminated specification. Addressing the RFC Editor: Has there ever been a case before where a known patent contaminated specifiaction been published as an independent submission? What are the RFC Editor's values/policies with respect to publication of known patent contaminated specifiactions? What are the minimum rights demanded from the patent holder in such a case? -- Mohsen BANAN http://mohsen.banan.1.byname.net Neda Communications, Inc http://www.neda.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Fixing the Process: RFC Publication - Patent contamination protection - Standards designation
Consensus Call for draft-housley-tls-authz and maturity of FOSS (e.g., Stallman ... participating in ietf mailing lists) has brought up again a process problem that I have been pointing to over the past 10 years. IETF functions need to be broken into independent separate entities with checks and balances. I mean truely separate entities. The solution is to revisit the process in favor of distributing responsibility for the various aspects of protocol development, rather than consolidating all these aspects under the umbrella of a single organization, such as the IETF. I wrote it all up and posted it right here about 10 years ago. Here we go again. -- The Free Protocols Foundation Policies and Procedures www.FreeProtocols.org http://www.freeprotocols.org/PLPC/100201 Version 0.5 March 29, 2000 Copyright 2000 Free Protocols Foundation. Published by: Free Protocols Foundation 3610 164th place SE Bellevue, WA 98008 USA Permission is granted to make and distribute verbatim copies of this document provided the copyright notice and this permission notice are preserved on all copies. Contents 1 Introduction 1.1 The Patent Debate 1.2 How Patents Affect Protocols 1.3 Difficulties Relating to Software and Protocol Patents 1.4 Terminology 1.4.1 Definitions 1.5 About the Free Protocol Processes and Procedures 1.6 About this Document 2 The Protocol Development Process 2.1 Phases of Development 2.1.1 Initial Protocol Development 2.1.2 Global Parameter Assignment 2.1.3 Protocol Publication 2.1.4 Patent-Free Declarations 2.1.5 Industry Usage 2.1.6 Maintenance and Enhancement 2.1.7 Endorsement by a Standards Body 2.2 Role of the Free Protocols Foundation 2.3 Coordination of Activities 3 The Free Protocols Foundation 3.1 General Philosophy 3.2 Purpose, Activities and Scope 3.3 Other Activities 4 Free Protocol Development Working Groups 5 Patent-Free Declarations 5.1 Author's Declaration 5.2 Working Group Declaration 6 Patents, Copyright and Confidentiality - Policy Statement 6.1 Policy Statement Principles 6.2 General Policy 6.3 Confidentiality Obligations 6.4 Rights and Permissions of All Contributions 6.5 FPF Role Regarding Free Protocol Specifications 1 Introduction 1.1 The Patent Debate --- At the time of writing, there is an on-going debate within the software industry regarding software patents. Like many others within the industry, at the Free Protocols Foundation we regard the historical tradition of patents as being entirely inappropriate for software. We consider software patents to have the effect of inhibiting free and open competition within the software industry, and to be extremely detrimental to the industry and the consumer. A complete discussion of the software patent issue is outside the scope of this document. For more information on this subject can be found at various sources, see [1] or [2]. 1.2 How Patents Affect Protocols -- Patents are applied to software, not to protocols. It is not possible to patent a protocol; in general only a process or an algorithm can be patented. However, a protocol may include a patented algorithm as an integral part of its specification. In this case, any software implementation of the protocol requires the use of patented software. That is, a patented process is an inherent part of the protocol. Even if a protocol does not explicitly decree the use of a specific patented software process, it may still be the case that any practical implementation of the protocol requires the use of patented software components. The protocol could in principle be implemented in a way which avoids the use of patented software; in practice, however, the result would be a significantly inferior implementation, for example in terms of efficiency. In either case, the protocol effectively implies the use of patented software. We will refer to any such protocol as a patented protocol. That is, a patented protocol is any protocol whose practical implementation requires the use of patented software components. We will use the term patent-free protocol, or just free protocol, to refer to a protocol which is functionally free from software patents. By ``functionally free from software patents,'' we mean either that the protocol is truly free from patents, or if the protocol does imply the use of patented software, that the patent-holder has granted non-restrictive rights to include the patented software components in implementations of the protocol. In either case, the result is that the protocol can be freely implemented and used by anyone, without encountering significant restrictions. 1.3 Difficulties Relating to Software and
Re: RFC Publication - Patent-Free Declarations ... -- Market of Protocols -- Free Protocols Foundation
On Sat, 18 Mar 2006 07:14:52 -0800, Dave Crocker [EMAIL PROTECTED] said: Dave Mohsen BANAN wrote: we propose... Dave Besides yourself, who is the we? Among others, Richard M. Stallman has served as a director of the Free Protocols Foundation (FPF) and has reviewed and endorsed various FPF initiatives. ...Mohsen ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
On Sun, 19 Mar 2006 04:56:57 +0100, Harald Alvestrand [EMAIL PROTECTED] said: Harald Mohsen BANAN wrote: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO) Harald The IESG pointed some of the issues out to the RFC Editor, who handled Harald the communication with the author; that was the procedure at that time. Harald Nevertheless, the RFC Editor felt that the document was worthy of Harald publication, and published anyway. As the written record clearly shows, this is factually incorrect. In the case of RFC-2188 the RFC Editor was no more than an IESG puppet. Publication was held up for more than 7 months, until finally Scott Bradner (Transport Area Director at the IESG) made it happen -- emphatically *not* the RFC Editor. Scott can step in, if he wishes. Full communication records are available at: http://www.esro.org/communicationRecord/rfc2188Publication/maillist.html And then there is the communication record of what happened when the IESG invited us to put ESRO on the standards track. http://www.esro.org/noStdTrack/main.html Harald The IESG note put on this document says: In general, I consider the garbage that IESG puts in non-IETF RFCs as a badge of honor for the author. For example, the negative IESG note in the original HTTP specs and the success of HTTP demonstrated IESG's attitude and its eventual relevance. Harald In this case [RFC-2524], too, the RFC Harald Editor exercised the RFC Editor's Harald independent judgment and published the Harald document. Had it not been for my very public RFC-2188 complaint, I do not believe RFC-2524 would have been published at all. Please note the time of my complaint and of the RFC-2524 publication. How many other non-IETF RFCs have ever been published by the RFC Editor in the face of IESG opposition? I believe the answer is very few if not zero. If I am wrong, I ask the RFC Editor/IESG to correct the record. Please name the RFCs. Harald This was eight years ago. ... Lack of true independence of the RFC Editor was the issue then, and it is the issue now. ...Mohsen ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
On Sun, 19 Mar 2006 04:56:57 +0100, Harald Alvestrand [EMAIL PROTECTED] said: On Sat, 18 Mar 2006 21:10:10 -0800, Dave Crocker [EMAIL PROTECTED] said: Harald What's the point of reposting this message now? Dave Seems like there ought to be a statute of limitations. In response to both of you: the point of referring to eight-year old history is not to disinter the corpse of the past. The point is that this history is directly relevent to a current discussion thread. I believe I made the point of reposting clear in the following header: Mohsen [ This is a repost from 6 Nov 1998. Mohsen In particular the section on: Mohsen o Separate The RFC Publication Service from the IETF/IESG/IAB. Mohsen is relevant to the current: MohsenSTRAW PROPOSAL RFC Editor charter Mohsen thread. ] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
On Sun, 19 Mar 2006 11:23:45 +, Dave Cridland [EMAIL PROTECTED] said: Dave On Sun Mar 19 09:46:30 2006, Mohsen BANAN wrote: For example, the negative IESG note in the original HTTP specs and the success of HTTP demonstrated IESG's attitude and its eventual relevance. Dave For the crowd watching who were curious, but not curious enough to Dave bother looking, RFC1945 (HTTP/1.0), which of course is NOT the Dave original HTTP spec at all, carries the note: DaveThe IESG has concerns about this protocol, and expects this document Daveto be replaced relatively soon by a standards track document. Dave RFC2068, HTTP/1.1, was published a little over half a year later, Dave which would appear to be relatively soon. The primary author of Informational RFC1945 with the negative IESG note is Tim Berners-Lee. He then pulled out of the IETF/IESG and formed W3C. Why do you think that happened? And where is IETF/IESG with W3C now? In my opinion what started with the Informational RFC1945 is the most significant advancement since formation of IETF/IESG/IAB/... Almost always innovation comes from outside of committees. Dave But back to your argument, which appears to be that if the RFC editor Dave function were utterly independent from the IAB/IETF/IESG, your Dave protocols would have been published without those notes, and without Dave the review those notes required. Which part is the problem, the Dave review, or the note attached to the document? None of those. My concern is not my own RFCs. I got them published despite of the IETF/IESG opposition. The IESG note is a badge of honor similar to Tim Berners-Lee's. The perspective that the world needs the IESG note to be able to judge the merits of a protocol is at best comical. The scope and purpose of the IESG note should be limited to relevance and overlap with current or planned IETF work. An independent RFC Editor should enforce this and put the IESG in its place. That is what the then BCP -- RFC-2026 -- said. Of course, things work differently in a cult. I suspect that lots of direct independent RFC submissions are being censored by the IESG. The community is being fragmented. And the trend appears to be for the situation to only be getting worse. Again, all of this is in the context of: STRAW PROPOSAL RFC Editor charter where the key topics are: - Independence of RFC Publication Service - Relationship of IETF/IESG/IAB with the RFC Publication Service - Use of the RFC Publication Service by the Internet Community Tony gets it: On Sun, 19 Mar 2006 09:28:17 -0800, Tony Hain [EMAIL PROTECTED] said: Tony The point is that the past IESG practice which has driven out those who Tony would submit individual submissions, resulting in the current ratios, MUST Tony NOT become the guide for what SHOULD happen going forward. The RFC editor Tony role needs to be extricated from the overbearing IESG and returned to its Tony independent role. Doing otherwise further fragments the community which will Tony only lead to its downfall. From my perspective, based on past performance, the IETF/IESG/IAB can not be trusted to control the RFC Publication Service. ...Mohsen ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
Keith, You have totally confused ESRO with EMSD. RFC-2188 is different from RFC-2524. 1) RFC-2188 (ESRO) As far as I know the RFC-2188 complaint had nothing to do with you. Everything is fully documented. We are talking about historic facts, not opinions. IESG did not object to publication of ESRO (RFC-2188). I declined IESG's invitation to put ESRO on standards track. That was my choice. The problem was that it took 7 months. 2) RFC-2524 (EMSD) You lost. I managed to convince the RFC Editor of the merits of publication. I used the RFC-2188 complaint to strengthen the RFC Editor's independence. There has never been any formal complaints related to RFC-2524. The only part of the IESG note that can be considered to have any aspect of legitimacy is: -- In the near future, the IESG may charter a working group to define an Internet standards-track protocol for efficient transmission of electronic mail messages, which will be highly compatible with existing Internet mail protocols, and which wil be suitable for operation over the global Internet, including both wireless and wired -- links. And that was in 1999. I am curious to know what happened. In the mean time of course there has been the proprietary and patent full BlackBerry. Our real enemy are proprietary patented protocols. It would be hard to argue that existence of the WhiteBerry concept has done any harm. http://www.freeprotocols.org/operationWhiteberry/index.html Back to the topic at hand: Keith ... I don't see how it's relevant now. Again, all of this is in the context of: STRAW PROPOSAL RFC Editor charter where the key topics are: - Independence of RFC Publication Service - Relationship of IETF/IESG/IAB with the RFC Publication Service - Use of the RFC Publication Service by the Internet Community Tony gets it: On Sun, 19 Mar 2006 09:28:17 -0800, Tony Hain [EMAIL PROTECTED] said: Tony The point is that the past IESG practice which has driven out those who Tony would submit individual submissions, resulting in the current ratios, MUST Tony NOT become the guide for what SHOULD happen going forward. The RFC editor Tony role needs to be extricated from the overbearing IESG and returned to its Tony independent role. Doing otherwise further fragments the community which will Tony only lead to its downfall. From my perspective, based on past performance, the IETF/IESG/IAB can not be trusted to control the RFC Publication Service. ... Mohsen On Sun, 19 Mar 2006 08:08:10 -0500, Keith Moore moore@cs.utk.edu said: Harald The IESG pointed some of the issues out to the RFC Editor, who handled Harald the communication with the author; that was the procedure at that time. Harald Nevertheless, the RFC Editor felt that the document was worthy of Harald publication, and published anyway. As the written record clearly shows, this is factually incorrect. In the case of RFC-2188 the RFC Editor was no more than an IESG puppet. Publication was held up for more than 7 months, until finally Scott Bradner (Transport Area Director at the IESG) made it happen -- emphatically *not* the RFC Editor. Scott can step in, if he wishes. Keith I will go on record to say that I was the IESG member who did the most Keith to discourage publication of your document as an RFC. Contrary to Keith your perception of things, the RFC Editor published it over my strong Keith objections, and also insisted on diluting the IESG note that was Keith originally written for that document. I don't recall the reasons for Keith the delay other than the high workload of IESG (we were reviewing Keith dozens of documents per week, the fact that IESG discussed things in Keith conference calls every two weeks, and there were several iterations of Keith back-and-forth with the RFC Editor regarding your document. It is my Keith recollection that your document was handled much more quickly than Keith working group documents -- because unlike WG documents which proceeded Keith normally though the IESG's queue (and for which the speed of Keith processing was sensitive to IESG's workload), the RFC Editor had a Keith policy of giving IESG a limited amount of time to comment on Keith independent submissions that had the perverse side-effect of giving Keith priority to those submissions. Keith It was and still is my opinion that RFC 2188 was not suitable for Keith publication as an RFC, as it is poorly designed and has numerous Keith technical flaws. To have published this document IMHO dilutes the Keith quality of the RFC series and may confer an undeserved appearance of Keith acceptance on ESRO. Perhaps more importantly, the discussion about Keith this document wasted a colossal amount of time that could have been Keith put to much better use reviewing working group output (on the part of Keith the IESG) and editing better quality
Re: STRAW PROPOSAL RFC Editor charter
On Thu, 16 Mar 2006 18:43:35 -0500, RJ Atkinson [EMAIL PROTECTED] said: Ran It is a bug that the scope of the RFC Editor, which for decades Ran has been the broader Internet community, has above been limited Ran to just the IETF community. For openers, the IRTF and IAB Ran are not properly part of the IETF, though they are obviously Ran related and co-operative. More broadly though, the RFC Editor Ran has handled Internet documents that had nothing to do with the Ran IETF for many years now. It would be a mistake to narrow the Ran RFC Editor's scope as the above sentence appears to do. Right on! Ran Proposed edit: Ran s/of the IETF community/of the Internet community/ Absolutely. Ran Similarly, it is a bug that the IETF process would govern the Ran publication of non-IETF documents. The IETF process properly Ran should govern how IETF generated documents should be handled Ran for publication. However, the IETF processes ought not govern Ran how IRTF, IAB, or other non-IETF documents are handled by the Ran RFC Editor. Exactly. The RFC Editor's independence needs to be strengthened. Not weakened. The IETF is just one customer of the RFC Publication Service. RFC publication and the RFC Editor predate IETF/IESG/... Since establishment of the IETF, the main innovation in the Internet; the Web; was through a non-ietf RFC publication. It is a good thing that W3C has been using the RFC Publication Service. IETF should not be permitted to interfere with other uses of the RFC Publication Service. Allowing IETF/IESG/... to control the RFC Publication Service will be to the detriment of the broader Internet community. It should be expected of the RFC Editor to publish non-IETF RFCs despite objections from IETF/IESG. How often has this happened? I managed to do it, but it was very difficult. What is being proposed will make things worse. Shortly after this note, I will send two messages dating back to 1998-2000. One is with regard to a complaint against the RFC Editor for lacking a back bone and the IESG for being irresponsible in the case of RFC-2188. My recommendations for a remedy there are consistent with Ran's observations. I had to drive that complaint to be able to publish RFC-2524 despite IESG's objections. See: http://www.emsd.org/communicationRecord/rfc2524Publication/maillist.html for details. Has there been other cases where the RFC Editor chose to publish a RFC despite of IESG's don't publish recommendation? The second is the Policies and Procedures of the Free Protocols Foundation http://www.freeprotocols.org which propose a model for independent entities creating an environment for a market oriented protocol development process. IETF's culthood will be further strengthened, if the RFC Editor's independence was to be further weakened. ...Mohsen ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
[ This is a repost from 6 Nov 1998. In particular the section on: o Separate The RFC Publication Service from the IETF/IESG/IAB. is relevant to the current: STRAW PROPOSAL RFC Editor charter thread. ] Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO) Mohsen Banan mohsen at neda.com November 5, 1998 This is a complaint against the IESG and the RFC-Editor about publication of RFC-2188 (Efficient Short Remote Operations - ESRO) as an Informational RFC. A lot went wrong in the process of publication of RFC-2188. The highlights are: o The publication of the RFC was delayed for *8 months* for no good reason. o During the period from the day of submission to the day of publication (8 months) there was only one technical email exchange related to this RFC and the RFC was published exactly as it was submitted (plus the IESG note). o The IESG was irresponsible and negligent in fulfilling its role. o The RFC-Editor was negligent in fulfilling its role. o In practice, the publicized processes and procedures for the Informational RFC publication were not being followed neither by the IESG and nor by the RFC-Editor. o In practice, RFC-Editor was reduced to a puppet of IESG acting as a glorified secretary and an inefficient messenger. o The IESG over stepped the scope of its authority and displayed an arrogant an dictatorial attitude which caused serious delays in the publication of the RFC. I (Mohsen Banan -- mohsen at neda.com) have used very strong words in the above list to characterize the problems in this specific case. Use of those words are in no way extreme. Use of ALL of those words are justified in this message. The fact that a lot went wrong in the case of publication of RFC-2188 is known to many. Steve Coya and Scott Brander have admitted that there were a number of problems and have apologized for them. Scott Bradner ... the iesg fucked up and I'm trying to fix the issue ... Steve Coya You DO have a valid complaint, but not with the RFC Editors. Scott Bradner ... As I said things slipped through Scott Bradner the cracks and I am sorry that happened. ... I accepted their apologies and after the publication of RFC-2188 I was going to let this drop. However, since then I have seen even more evidence of the IESG being way out of control and now feel that something needs to be done. This note is complete and includes all that is necessary to allow people to judge for themselves the validity of my complaints. My goal is to PRESERVE the so far mostly open Informational RFC publication process from censorship by the likes of IESG. We need to find a way to ensure that what went wrong in this case never happens again. I am preparing this complaint because I think that it can help a number of areas which are critical to the continued success of the Internet. In the absence of any sort of accountability by the IESG and the RFC-Editor to anyone, I am hoping that peer pressure and public embarrassment can be used as tools to bring the IESG under control and restore the Information RFC publication process to the open process that it is supposed to be. Internet Standards are better than other standards because we realize that no entity (IETF/IESG/IAB) has exclusivity on good ideas. Many (if not most) good/successful Internet protocols have come from outside of committees, task forces, groups or boards. (If you are looking for examples, consider the web.) Fair and equitable access to the RFC publication service is fundamental to the success and growth of the Internet. Good protocols (as well as bad protocols) coming from outside of the IETF should have access to the RFC publication service, so that they can be used and even sometimes compete with IETF/IESG work. The network and the market place ultimately decides the winners and the loosers. Now, my experience with the publication of RFC-2188 has convinced me that: o the IESG frequently abuses its authority and in fact is allowed to delay the publication of RFCs indefinitely and even engage in censorship of material that it just does not like or that it does not understand. o both the IESG and the RFC-Editor operate with an authority oriented attitude as opposed to a responsibility oriented attitude. o in practice there are not adequate checks and balances in the process to guard against mistakes by the IESG or the RFC-Editor. If any of the above is true we have a problem. Unfortunately, this note clearly demonstrates that all of the above were true in the case of RFC-2188. I am also now convinced that the problems in the case of RFC-2188 were not isolated to that case alone. There is a serious problem. The rest of this note substantiates my claims
RFC Publication - Patent-Free Declarations ... -- Market of Protocols -- Free Protocols Foundation
As an alternative to allowing IETF to decide and control the future of the RFC Publication Service, we propose a model of independent services (RFC Publication, IANA, patent-free declarations, ...) creating an environment for a market of protocols with inherent checks and balances. What is to follow, for the most part focuses on the Patent-Free declarations but the general model and the importance of an independent RFC Publication Service separate from the likes of IETF/IESG are also described. The plain text version below has been trimmed, the general process and RFC Publication Service related text is kept. The complete document in plain text, PDF and HTML formats are available at: http://www.freeprotocols.org/freeProtocolProcess/index.html. The Free Protocols Foundation Policies and Procedures www.FreeProtocols.org Version 0.7 May 10, 2000 Copyright 2000 Free Protocols Foundation. Published by: Free Protocols Foundation 3610 164th place SE Bellevue, WA 98008 USA Permission is granted to make and distribute verbatim copies of this document provided the copyright notice and this permission notice are preserved on all copies. 1 Introduction 1.1 The Free Protocols Foundation Mission --- Software patents pose a significant danger to protocols. In some cases patents become included in protocols by accident -- that is, without deliberate intentionality on the part of the protocol developer. In other cases, however, an unscrupulous company or organization may deliberately introduce patented components into a protocol, in an attempt to gain market advantage via ownership of the protocol. In either case, the protocol can then be held hostage by the patent-holder, to the enormous detriment of anyone else who may wish to use it. The inclusion of software-related patents in protocols is extremely damaging to the software industry in general, and to the consumer. The mission of the Free Protocols Foundation is to prevent this from happening. We have defined a set of processes which a protocol developer can use to work towards a patent-free result, and we provide a public forum in which the developer can declare that the protocol conforms to these processes. As described below, it is not possible to provide an absolute guarantee that any particular protocol is truly patent-free. However, the Free Protocols Foundation processes allow a developer to provide some public assurance that reasonable, good-faith measures have been taken to create a patent-free protocol. In some cases, standards organizations, such as the IESG, make use of their own processes for developing patent-free protocols. However, these processes are available only for the organization's own internal use. The Free Protocols Foundation makes the same general processes available to any protocol developer. Its processes allow any company, organization or individual to develop patent-free protocols, without requiring the developer to be part of a formal standards organization. At the Free Protocols Foundation we strenuously oppose the creation and promotion of patented protocols. By providing clear mechanisms and assurances of patent-freedom, our goal is to make it abundantly clear to the industry at large whether a particular protocol is, or is not, patent-free. 1.2 The Patent Debate --- At the time of writing, there is an ongoing debate within the software industry regarding software patents. Like many others within the industry, we at the Free Protocols Foundation regard the historical tradition of patents as being entirely inappropriate for software. We consider software patents to have the effect of inhibiting free and open competition within the software industry, and to be extremely detrimental to the industry and the consumer. A complete discussion of the software patent issue is outside the scope of this document. More information on this subject can be found at various sources, for example [1] or [2]. 1.3 How Patents Affect Protocols -- Patents are applied to software, not to protocols. It is not possible to patent a protocol; in general only a process or an algorithm can be patented. However, a protocol may include a patented algorithm as an integral part of its specification. In this case, any software implementation of the protocol requires the use of patented software. That is, a patented algorithm is an inherent part of the protocol. Even if a protocol does not explicitly decree the use of a specific patented software process, it may still be the case that any practical implementation of the protocol requires the use of patented software components. The protocol could in principle be implemented in a way which avoids the use of patented software. In practice, however, the result would be a
Re: Beyond China's independent root-servers -- Expanding and Fixing Domain Notation
On Thu, 2 Mar 2006 22:26:59 +0800, Stephane Bortzmeyer [EMAIL PROTECTED] said: Stephane On Thu, Mar 02, 2006 at 12:26:23AM -0800, Stephane Jefsey Morfin, disguised as Mohsen BANAN Stephane [EMAIL PROTECTED] wrote Stephane a message of 551 lines which said: Hello Stephane Bortzmeyer. I have no reason to believe that you are not Stephane Bortzmeyer. Why are you publicly accusing Jefsey Morfin of masquerading as me, Mohsen Banan? That is bad form, you know. I can assure that I am me, and he is he, and we are not the same. I think you should publicly apologize for wrongly and baselessly accusing him of pretending to be someone else. I wrote the email that you have quoted. Had you put Mohsen Banan in the google box and clicked on I'm Feeling Lucky, you would have landed on: http://mohsen.banan.1.byname.net/ProfessionalBio/ You could also grep for my name in the RFC series ... If Jefsey (Jean-Francois C. MORFIN) were really masquerading as someone else, he would surely choose an unknown, a nonentity, a cipher. But I am none of those things. I have a history. I do not recall having ever met Mr. Morfin and don't know him other than from his participation on this list. Based on his writings, I consider him far more reasonable than the typical IETF cult leader or your typical IETF groupie. His notes I do not ignore. Outside of this clarification, the rest of your remarks I can comfortably ignore. Regards, ...Mohsen ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Multinational Internet or Balkanization?
On Wed, 1 Mar 2006 14:46:42 -0800 (PST), william(at)elan.net [EMAIL PROTECTED] said: William On Wed, 1 Mar 2006, Hallam-Baker, Phillip wrote: From: JFC (Jefsey) Morfin [mailto:[EMAIL PROTECTED] Dear Phillip, Full agreement. Let not confuse alt-roots and open-roots. I was not suggesting confusing them, I was suggesting ignoring them. William Ignore China? William I know some do it with their email, but on the large-scale of global William infrastructure and business relationships, I do not think it would work. Ignore the world and the world will ignore you. Of course, many here will continue to go on and just ignore reality. Today's announcement is just a beginning. Shortly after this note, I'll follow up with how this perceived threat may be viewed as an opportunity. -- Mohsen BANAN ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Beyond China's independent root-servers -- Expanding and Fixing Domain Notation
More than 5 years ago I predicted what the Chinese government announced today. What happened today: http://english.people.com.cn/200602/28/eng20060228_246712.html http://www.interfax.cn/showfeature.asp?aid=10411slug=INTERNET-POLICY-MII-DOMAIN%20NAME-DNS http://www.domainesinfo.fr/vie_extensions.php?vde_id=859 http://politics.slashdot.org/politics/06/02/28/1610242.shtml http://news.com.com/China+creates+own+Internet+domains/2100-1028_3-6044629.html was obvious and quite easy to foresee. Addressing the requirements of a very real international multi-root environment is also not all that hard and will likely naturally evolve. But there is more that can be done. The Internet technical community is now given a unique opportunity to expand the domain notation and even address past mistakes and fix the domain backwardness problem. About 4 years ago, in a note with the subject of: Revisiting - Re: Now: Next Generation Domains and DNS -- Was: Re: No More Central Authority: Not NSI/ICAN! Not ORSC! I re-sent the write up (dated Jan 1999) for what needs to be done to move things forward. It is included here again below. Obviously, IETF is not fit to move this forward. If anybody translates this plan into Chinese, please email me a copy. -- Mohsen BANAN To: Internet Technical Community ietf at ietf.org Subject: Revisiting - Re: Now: Next Generation Domains and DNS -- Was: Re: No More Central Authority: Not NSI/ICAN! Not ORSC! From: public at mohsen.banan.1.byname.net Date: 06 Aug 2002 06:42:23 -0700 Sender: owner-ietf at ietf.org Good! After many years, the Internet technical community (save ICANN and IETF cult's chiefs) has now arrived to the general recognition that the concept of parallel root server clusters are in fact practical, workable, stable and democratic. It may now be a good time to re-visit other DNS problems and recognize that they can also be solved. Most notably, The DNS Notation Backwardsness. Parallel root server clusters and the fixing of the DNS Notation Backwardsness problem are very related and can be done at the same time. I explained all of this in reasonable detail more than 3.5 years ago. It is comforting to see that parts of the solution that I proposed is now in place. Below is the main email from the thread that I introduced in 1998/1999. At that time, with hope, I said: I believe it is only now that we have an opportunity to plant the right seeds so that the problem can be fixed over time. From a historic perspective it is worthwhile noting that shortly after Bob Allisat suggested that the IETF build on the concepts that I had introduced, he was banned from the IETF mailing list by the then IETF Chair, Fred Baker. While I address this message to the Internet technical community, if in fact IETF does not stand for Innovation Extermination Task Force, then perhaps even IETF can get involved in cultivation of these concepts. --- 1999 Original Message Follows --- To: IETF Mailing List ietf at ietf.org Subject: Re: Now: Next Generation Domains and DNS -- Was: Re: No More Central Authority: Not NSI/ICAN! Not ORSC! Date: Tue, 26 Jan 1999 00:41:34 -0800 (PST) [This is a summary response which covers comments which were in reply to my: 199901220641.WAA11066 at rostam.neda.com message with the subject of: Re: Now: Next Generation Domains and DNS -- Was: Re: No More Central Authority: Not NSI/ICAN! Not ORSC! dated Thu, 21 Jan 1999 22:41:13 -0800 (PST).] I ended my previous note, by saying: On Thu, 21 Jan 1999 22:41:13 -0800 (PST), Mohsen BANAN mohsen at neda.com said: Mohsen ... Mohsen Now, after all of this if there was to be an Mohsen acknowledgment that there is an architectural Mohsen problem here and that this is not a strings Mohsen parsing issue which can go either way, then Mohsen may be we can work on solutions Many got the point -- that there is a notation backwardness problem. For example: On Fri, 22 Jan 1999 08:42:32 -, mark.paton mark.paton at btinternet.com said: mark I hate to admit it but he has a point! and: On Fri, 22 Jan 1999 14:50:41 +0400, Peter Dawson peterdd at gto.net.om said: Peter ... Peter How come the folks don't admit the mistakes and just Peter keepcontinuing.. ?? we all understand it is human to err.. !! and: Now, we just have got to leave behind those who after all of this, still don't get it and can't (or don't want to) follow. I -- and many others -- have known about this notation backwardness for more than 10 years. Prior to last week, I had never brought up this issue publicly. There is a good reason why I chose 1999 as the time to bring it up. That is because, I believe it is only now that we have an opportunity to plant the right seeds so that the problem can be fixed over time. Taking advantage of this opportunity to fix it is a lot more reasonable than living with it. On Fri, 22 Jan 1999 04:14:55 -0500 (EST), Theodore Y. Ts'o tytso
Re: Faux Pas -- web publication in proprietary formats at ietf.org
On Sat, 05 Nov 2005 18:59:10 +0100, Brian E Carpenter [EMAIL PROTECTED] said: Brian Here's the text. You can pick up a map at the Brian concierge desk in the Westin. I ate at Wild Brian Garlic last night and it was excellent. Mr. Carpenter, the IETF Chair; Your restaurant recommendations, I do take seriously. The goers go, the talkers talk and the doers do. Remember! Of course many now visit the ietf.org site primarily for the restaurant guide. And now that is only available as a .ppt file. Is big business now so entrenched at the ietf that use of Microsoft's PowerPoint is being encouraged at the ietf.org website? True to form, like an experienced cult leader, you have again trivialized a real problem. My email was not about restaurants or a need for the text. Publication of anything in Microsoft PowerPoint format at the ietf.org website is utterly inappropriate and wrong. If IETF's Best Current Practices are to be taken seriously, ietf.org website should lead by example. A responsible IETF Chair would have: - Recognized and acknowledged that publication of anything at the ietf.org web site in Microsoft's PowerPoint format is wrong. - Immediately addressed the problem and republished in an Open/Libre/Free format. - Addressed the broader question of what are the Open/Libre/Free formats appropriate for web publication and what constitutes an Open/Libre/Free format. In between good meals, perhaps you can also consider your responsibilities. As of Sat Nov 5 14:32:04 PST 2005 the Restaurant Guide in http://www.ietf.org/meetings/IETF-64.html points to http://www.ietf.org/meetings/Restaurant_Guide_Map.ppt This information is provided in Microsoft PowerPoint, a vendor-specific proprietary format. Fix it quick. Enjoy Vancouver's many good restaurants. Bon Appetit! ...Mohsen ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Faux Pas -- web publication in proprietary formats at ietf.org
On Sun, 06 Nov 2005 01:35:55 +0100, Brian E Carpenter [EMAIL PROTECTED] said: Brian As a matter of fact I agree with you that it's desirable Brian to avoid proprietary formats, and I have passed this on Brian to the IAD for future reference. Thank you. Glad you agree. But, I consider it a very sad day when I have to go through all of that to get the IETF Chair to agree with me that web publication in proprietary formats at ietf.org is a faux pas. ...Mohsen ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
FPF Position Statement regarding the RIM Mobile E-Mail Patent Assertion
[ Please distribute this article as widely as possible, wherever appropriate. ] The Free Protocols Foundation article Position Statement regarding the RIM Mobile E-Mail Patent Assertion is provided as an attachment in Plain Text format. The article states the position of the Free Protocols Foundation regarding the RIM mobile e-mail patent. The article is also available in PDF and HTML formats at http://www.freeprotocols.org/position-rim-6219694 This position statement has the endorsement of the Free Software Foundation and the personal endorsement of Richard M. Stallman. --- document in text form follows --- Position Statement regarding the RIM Mobile E-Mail Patent Assertion Free Protocols Foundation Version 2.4 September 12, 2002 Copyright and Permission Copyright (c)2001, 2002 Free Protocols Foundation. Permission is granted to make and distribute verbatim copies of this document provided the copyright notice and this permission notice are preserved on all copies. 1 Introduction The Free Protocols Foundation (FPF) is a non-profit organization and independent public forum dedicated to the support of patent-free protocols and software. The FPF views software and protocol patents as being detrimental to the industry and the consumer, and part of the FPF mandate is to oppose exceptionally harmful patents when they appear. For more information see the FPF website at http://www.freeprotocols.org. In May 2001 Research in Motion (RIM) made a patent assertion which we regard as an egregious example of patent law abuse, and exceedingly harmful in its potential effects. The following is a statement of the FPF position regarding this patent, the actions we have undertaken to oppose it, and the remedial action we are now demanding of RIM. 2 Research in Motion (RIM) and BlackBerry === Research in Motion (RIM) is a Canadian wireless technology company based in Waterloo, Ontario, Canada. Among other things RIM manufactures and licenses BlackBerry, a popular wireless handheld e-mail device. BlackBerry is a closed, single-vendor e-mail system, based on a set of proprietary protocols. For details see the BlackBerry website at http://www.blackberry.net. 3 RIM's Patent Assertion In April 2001 RIM was granted U.S. Patent # 6,219,694, entitled System and method for pushing information from a host system to a mobile data communication device having a shared electronic address. The complete text of the patent is available in PDF format on the FPF website at: http://www.freeprotocols.org/usPatents/06219694.pdf. The patent describes a method of directing e-mail to wireless devices, while maintaining mailbox synchronization with a desktop e-mail system. The described method is a basic element of the functioning of various existing mobile e-mail systems, including the BlackBerry system. RIM was quick to take advantage of this patent. Less than a month after the patent was granted, RIM announced a lawsuit against Glenayre Electronics, Inc. for infringement against the patent. To view an article describing this patent assertion, visit http://www.totaltele.com/view.asp?ArticleID=40057pub=ttcategoryid=625. The same article is also available on the FPF website at http://www.freeprotocols.org/rimBBPatentProblem/extNews2.html. In order to understand the eventual disposition of RIM's lawsuit, it is important to know that when it comes to patents Glenayre is no angel either; and in particular, had previously filed its own patent infringment suit against RIM. An article describing the Glenayre patent assertion is available at http://www.garywill.com/waterloo/ctt9908.htm; the same article is also available on the FPF website at http://www.freeprotocols.org/rimBBPatentProblem/extNews1.html. Thus with the initation of RIM's lawsuit against Glenayre, both companies now had patent lawsuits pending against each other. 4 FPF Position on the RIM Patent Assertion The Free Protocols Foundation views the RIM patent assertion as an extreme example of patent-law abuse. This is because: * The patent is based on methods and processes which were previously known and implemented, and there is ample prior art to demonstrate this. RIM's claim that these processes are novel is false. * The patent covers an aspect of mobile e-mail that is so fundamental that if it goes unchallenged, it will have the effect of hobbling the wireless and mobile e-mail industry. The patent is particularly noxious because of the very large scope of its claims. Note that mobile e-mail is not merely another generic product or service - it is an extremely large-scale interconnected system, whose functioning is of profound importance to business and society.
Re: DNSng: where to discuss/get info?
Did you follow the discussions that I initiated on a similar set of topics on the [EMAIL PROTECTED] mailing lists about two years ago? In that thread I proposed something along the lines that you are looking for. I am including my last message on that thread below. Bob Allisat [EMAIL PROTECTED] followed up on that idea and asked why we can't build on it and move towards a solution. If I remember right, the subject line of his message was: "Does IETF stand for Innovation Extermination Task Force?" Shortly after that, the IETF Chair restricted his participation in [EMAIL PROTECTED] mailing list. The problems with DNS are well known. Fixing them in the context of some next generation DNS makes good sense. I am also interested in the answer to your question. Rahmat - is there any WG, or organization, or list, or whatever Rahmat which is actively discussing the TECHNICAL (not political) Rahmat aspect of how a new DNS scheme should be? ...Mohsen. --- From: Mohsen BANAN [EMAIL PROTECTED] To: IETF Mailing List [EMAIL PROTECTED] Subject: Re: Now: Next Generation Domains and DNS -- Was: Re: No More Central Authority: Not NSI/ICAN! Not ORSC! Date: Tue, 26 Jan 1999 00:41:34 -0800 (PST) Content-Type: text/plain; charset=US-ASCII MIME-Version: 1.0 Message-Id: [EMAIL PROTECTED] [This is a summary response which covers comments which were in reply to my: [EMAIL PROTECTED] message with the subject of: Re: Now: Next Generation Domains and DNS -- Was: Re: No More Central Authority: Not NSI/ICAN! Not ORSC! dated Thu, 21 Jan 1999 22:41:13 -0800 (PST).] I ended my previous note, by saying: On Thu, 21 Jan 1999 22:41:13 -0800 (PST), Mohsen BANAN [EMAIL PROTECTED] said: Mohsen ... Mohsen Now, after all of this if there was to be an Mohsen acknowledgment that there is an architectural Mohsen problem here and that this is not a "strings Mohsen parsing" issue which can go either way, then Mohsen may be we can work on solutions Many got the point -- that there is a "notation backwardness" problem. For example: On Fri, 22 Jan 1999 08:42:32 -, "mark.paton" [EMAIL PROTECTED] said: mark I hate to admit it but he has a point! and: On Fri, 22 Jan 1999 14:50:41 +0400, Peter Dawson [EMAIL PROTECTED] said: Peter ... Peter How come the folks don't admit the mistakes and just Peter keepcontinuing.. ?? we all understand it is human to err.. !! and: Now, we just have got to leave behind those who after all of this, still don't get it and can't (or don't want to) follow. I -- and many others -- have known about this notation backwardness for more than 10 years. Prior to last week, I had never brought up this issue publicly. There is a good reason why I chose 1999 as the time to bring it up. That is because, I believe it is only now that we have an opportunity to plant the right seeds so that the "problem" can be fixed over time. Taking advantage of this opportunity to fix it is a lot more reasonable than "living" with it. On Fri, 22 Jan 1999 04:14:55 -0500 (EST), "Theodore Y. Ts'o" [EMAIL PROTECTED] said: Theodore ... Theodore Whether or not you call this a "Problem" depends on your point Theodore of view. But this is reality. Live with it. Ted, you live with it. If you want to. I am an engineer. I try to fix problems when the opportunity presents itself. Please consider what I refer to as the "opportunity to plant the right seeds", with an open mind for a moment. May be it is workable. May be it is not. Worstcase, we live with it. I want to try. Yes. This problem has widespread roots. On Fri, 22 Jan 1999 10:09:02 -0800 (PST), Ned Freed [EMAIL PROTECTED] said: Ned I am in complete agreement with Ted here. I also have issues with the way Ned things work and the way things were done, but I recognize that this stuff is Ned far too widely deployed at far too many levels to change now. Ned, I understand (and respect) the significance of the installed base as much as the next guy. That is why I don't refer to this as a "quick fix" but as a "planting of the seeds" type of an approach. In order to understand what I am proposing we have to consider it in the larger context of Domains and DNS ambiance of 1999. Let's put everything on the table and take a quick look. - We have a DNS-mess grid-lock. At least according to some (me included). The idea of expanding top level domains have gone nowhere. Introducing competition at the root-server and registration level has gone nowhere. General confidence in progress is low ... - Updates to DNS Software (both client and server) for beyond IPv4 addresses are needed. - Updates to DNS Software (both client and server) for security, public keys, certificates, ... are needed. - As phone numbers and Domains keep comin
Re: TCP for Transaction (T/TCP) protocol
(Updated by RFC2065); (Updated by RFC2181); (Updated by RFC2308). [15] Mohsen Banan. Efficiency Study of EMSD vs. SMTP/POP3/IMAP. Neda Published Document 103-101-01.01, EMSD Organization, 1996. Online document is available at http://www.emsd.org/pubs/biblio/103-101-01_01/index.html. [16] Mohsen Banan. ESROS Application Programming Interface. Neda Published Document 103-101-06.03, ESRO Organization, 1996. Online document is available at http://www.esro.org/pubs/biblio/103-101-06_03/index.html. [17] Mohsen Banan. Lightweight Efficient Application Protocol (LEAP) Manifesto. FPF Published Document 108-101-01, Free Protocols Foundation, Bellevue, WA, January 2000. Online document is available at http://www.freeprotocols.org/pubs/biblio/108-101-01/index.html. [18] Mohsen Banan. The WAP Trap. FPF Published Document 108-102-01, Free Protocols Foundation, Bellevue, WA, January 2000. Online document is available at http://www.freeprotocols.org/pubs/biblio/108-102-01/index.html. [19] G. Montenegro, S. Dawkins, M. Kojo, V. Magret, and N. Vaidya. Long Thin Networks. Request for Comments (Informational) 2757, The Internet Society, January 2000. Online document is available at ftp://ftp.isi.edu/in-notes/rfc2757.txt. [20] Information Processing Systems --- Open Systems Interconnection: Basic Reference Model. International Organization for Standardization and International Electrotechnical Committee, 1984. Interational Standard 7498. [21] J. Postel. User datagram protocol. Request for Comments (Standard) STD 6, 768, Internet Engineering Task Force, August 1980. [22] J. Postel. Transmission control protocol. Request for Comments (Standard) STD 7, 793, Internet Engineering Task Force, September 1981. (Obsoletes RFC761). [23] R. Srinivasan. Binding protocols for ONC RPC version 2. Request for Comments (Proposed Standard) 1833, Internet Engineering Task Force, August 1995. [24] R. Srinivasan. RPC: remote procedure call protocol specification version 2. Request for Comments (Proposed Standard) 1831, Internet Engineering Task Force, August 1995. [25] R. Srinivasan. XDR: external data representation standard. Request for Comments (Proposed Standard) 1832, Internet Engineering Task Force, August 1995.
Re: mobile orthogonal to wide-area wireless
All of this and a great deal more is discussed in various old books, such as: - Internetwork Mobility - The CDPD Approach Taylor, Waung and Banan Prentice Hall 1996 ISBN: 0-13-209693-5 Hope this helps. ...Mohsen On Wed, 18 Oct 2000 23:04:39 -0400, Keith Moore [EMAIL PROTECTED] said: I would rather have one address for a wireless WAN interface and another address for a wireless LAN interface -- which seems to be doable today -- much more than I want to wait for the solution with "Mobile IP" address traversal to become commercially available. No, what you want is a serial number. Or at least what you describe is a serial number. An address is very different. Keith the word "address" is used in so many different ways that any Keith argument of the form "x is/is not an address" tends to be Keith nothing more than an argument about which definition of the Keith word "will be master" (to quote Humpty Dumpty) Keith users don't care about whether their mobile device has one address Keith that follows it everywhere or whether it changes addresses as Keith it moves. however, depending on their needs, they might care about Keith their applications continuing to stay connected while they're mobile. Keith they might also care about running applications that are both mobile Keith and "always on". Keith any network stack that supports the latter two kinds of applications Keith will almost certainly employ (at least) two different sets of Keith things that could be called "addresses" - one which is stable Keith even while the device is mobile, and another which is less stable. Keith whether those two addresses look alike or different, whether Keith the technology used is "mobile IP" or something else , and Keith the level of the protocol stack at which the indirection occurs Keith - these are implementation choices. Keith of course, some implementation choices work better than others, Keith especially when it comes to interoperating with the wired Internet, Keith or in being able to support existing applications, or in being Keith able to switch from one communications medium to another. but Keith the implementation choice can quite reasonably be different Keith depending on the particular characteristics of the device and Keith its communications media, and also on the needs of its users. Keith Ketih
The LEAP Manifesto -- Executive Summary
The Lightweight Efficient Application Protocol (LEAP) Manifesto Shaping the Future of Mobile Wireless Applications Industry A Call to Action EXECUTIVE SUMMARY Mohsen Banan [EMAIL PROTECTED] Version 0.5 July 17, 2000 Copyright (c)2000 Mohsen Banan. Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Contents 1 Executive Summary 1.1 Technological Scope 1.2 Efficiency is the Key Requirement 1.3 Conventional Origins of Protocols 1.4 Expect the Unexpected 1.5 Our Solution 1.6 A Brief History of LEAP 1.7 Making Our Solution Widespread 1.8 Complete and Ready 1.9 Getting the Complete Manifesto 1 Executive Summary Until now, the Internet has been largely based upon simple protocols. However, the era of simple protocols is now over. The new Internet reality is that of wireless networks, providing service to legions of miniaturized, hand-held mobile devices. This reality places an entirely new set of requirements on the underlying communications protocols: they must now provide the power efficiency demanded by hand-held wireless devices, together with the bandwidth efficiency demanded by wide area wireless networks. It is now time for a new generation of protocols to be implemented, designed to address the need for performance, rather than simplicity. The industry-wide adoption of this new generation of powerful and efficient protocols will have enormous consequences. Protocols addressing the correct requirements will become the lynchpin of a huge new industry. The stakes are enormous, and ferocious competition is to be expected within all segments of the industry. All manner of wild claims and misrepresentations are also to be expected. At the time of writing, the main claimant to the protocol throne is the Wireless Applications Protocol, or WAP. However, WAP will eventually prove to be entirely inadequate to the role being claimed for it. We have designed a set of protocols, the Lightweight Efficient Application Protocols, or LEAP, which we believe is destined to displace WAP and become the de facto industry standard. These protocols, published as Internet RFC 2524 and RFC 2188, are designed to address all the technical requirements of the industry, and are oriented towards providing the greatest benefit to the industry and the consumer. This manifesto is about our vision of the future of the Mobile and Wireless Applications Industry. In the remainder of the manifesto we present the details of our vision, and we justify our claims. We justify our assertion that the industry needs a new generation of protocols, we explain why our protocols fulfil this need, and we describe how and why these protocols will achieve dominance. The protocols are free, open and in place. Open-source software implementations of the protocols are being made available for all major platforms. The combination of free protocols and open-source software ensures acceptance of the protocols in the Internet mainstream. There can be no stopping this. 1.1 Technological Scope Most of our discussion throughout this Manifesto is framed in terms of a particular technology, namely, Mobile Messaging. It is important to bear in mind, however, that Mobile Messaging is just one aspect of a broader technology: Mobile Consumer Data Communications. Mobile Consumer Data Communications refers to the general ability of an end-user to send and receive digital data at a hand-held device via a wireless network. This technology includes Mobile Messaging as a special case, but also includes other wireless data transfer capabilities such as general Internet access, web browsing, etc. Much of the discussion set forth in this Manifesto applies with equal force to all mobile data communications applications, not just that of messaging. However, it is currently well understood that the dominant application for mobile data communications is, in fact, Mobile Messaging, not web browsing or other Internet applications. Therefore throughout this Manifesto we will focus our attention on the messaging application. Though our discussion will be framed in terms of Mobile Messaging, the reader should bear in mind that the same principles apply to all forms of mobile data communications. 1.2 Efficiency is the Key Requirement -- Engineering is the art of making intelligent trade-offs between conflicting requirements. A perennial engineering trade-off is that which must be made between the need for simplicity, and the need for performance. In the case of wireless data communications, performance means such things as data transfer speed, power
Re: Multimedia EMSD? (was Re: Mobile Multimedia Messaging Service)
On Mon, 18 Sep 2000 01:55:21 -0700 (PDT), "James P. Salsman" [EMAIL PROTECTED] said: Those who want to build good things and move forward fast, can evaluate the merits of LEAP and participate in its evolution and enhancement. The starting point URL is: http://www.leapforum.org/ James Would you confirm, please, that the LEAP Efficient Mail Submission and James Delivery protocol (EMSD) is capable of MIME messages with multimedia James content? Confirmed. Please see sections 6.2.1 and 6.2.2 of RFC-2524, pages (58-62). James I am concerned that the string "multipart" does not appear on: James http://www.emsd.org/dataCom/emsd/emsdRfcs/emsdp-rfc/split/node10.html "multipart" as a string, is a value. Structure of the Body is through MIME. ...Mohsen.
Re: ESRO (RE: WAP and IP)
On Mon, 26 Jun 2000 08:23:41 +0200, Harald Tveit Alvestrand
[EMAIL PROTECTED] said:
Harald At 05:30 26.06.2000 +, Mohsen BANAN-Public wrote:
The current status, state and beginning date of that example
makes my point.
After 7 months of delay, caused by the IESG, ESRO was published
as an RFC in Sept. 1997.
Harald History note:
Harald ESRO (RFC 2188) was delayed, as far as I remember, because of lack of
Harald response from the authors to IESG comments; this turned out to be because
Harald the author either didn't get them or didn't think/understand that a
Harald response was needed.
Harald I remember some apologies at the time, and the document was published
Harald without making the changes that the comments (some mine) had asked for.
Completly Wrong!
One wonders how much of this ("as far as I remember") is intentional.
The complete record of my interactions with the IESG regarding ESRO,
INCLUDING ALL DATES, is on public record.
The entire communication record between the Authors, RFC-Editor and IESG
regarding ESRO are at: http://www.esro.org/communicationRecord/index.html
Also, the full text of the Complaint against the IESG and the RFC-Editor is
available at: http://www.esro.org/complaint-2188/one/main.html
Anyone may review these records to determine very quickly exaclty who
was responding promptly, and who was causing the delay. I invite Mr.
Alverstrand to refresh his memory by reviewing these records.
He will quickly discover the following incontrovertible and historical
facts:
The ESRO RFC was submitted to the RFC-Editor on Jan 11, 97. Harald
Tveit Alvestrand's *ONLY* e-mail forwarded to the Authors was dated
8/18/1997. I responded to his e-mail on the same day I received it. In
all cases I responded promptly and as required to all comments and
queries from the IESG and the RFC Editor. As the record shows, it is
they who were the cause of the delay.
The fact that a lot went wrong in the case of publication of RFC-2188
is well-known. Steve Coya and Scott Brander have acknowledged that
there were a number of problems and have apologized for them:
Scott Bradner ... the iesg fucked up and I'm trying to fix the issue ...
Steve Coya You DO have a valid complaint, but not with the RFC Editors.
Scott Bradner ... As I said things slipped through
Scott Bradner the cracks and I am sorry that happened. ...
And then after all this, at the very last minute, without my knowledge
or approval, the IESG inserted their critical note in RFC-2188.
Harald ESRO was published without significant input from the IETF community, and
Harald has some aspects that I consider rather stupid (tied to a single UDP port
Harald number (4.6.3), use of a THREE-bit transport selector (4.4.1) and total
Harald lack of discussion of congestion control), but did not face significant
Harald opposition in the IESG.
An inability to understand the design of ESRO might be characterized
as rather stupid.
Other UDP ports can be used. There is nothing in the design of ESRO
that limits UDP port usage. This much is obvious. In fact EMSD uses
its own UDP port. Other Efficient Applictions can use other UDP ports
with ESRO. That was part of our design. There is no shortage of UDP ports.
On a per application basis, 8 transport selectors is more than
adequate. Look at EMSD to learn how that can be done.
Those are not scalability limitations. You simply did not understand
our design.
Discussion of congestion control in the ESRO context is
a complicated issue.
However, if we want to have a meaningful discussion of these technical
issues, the general IETF mailing list is not the right place. I have
gone over these issues with you and others several times before. If
you want to learn more, please subscribe to
mailto:[EMAIL PROTECTED] and ask your questions there.
Harald It's EMSD (RFC 2524) that was considered by the IESG to be bad enough that
Harald it was labelled with an IESG warning containing sentences like "makes EMSD
Harald completely unsuitable for end-to-end use across the public Internet", and
Harald seemingly earned the IESG the permanent enmity of Mohsen Banan.
The entire communication record between the Authors, RFC-Editor and IESG
regarding EMSD are at:
http://www.emsd.org/communicationRecord/2524Publication/maillist.html
Based on a severe case of Not-Invented-Here, the IESG attempted to
prevent the publication of EMSD (RFC-2524). Despite their efforts to
quash it, I successfully demonstrated to the RFC-Editor that EMSD
meets the requirements of RFC-2026 and should therefore be
published. The RFC-Editor's own characterization of the IESG note is
that it was "punitive." The insertion of the IESG note in RFC-2026 has
no legitimate or procedural basis whatsoever, and is in complete
violation of the scope and purpose of IESG's role.
To say I have "permanent enmity" towards the IESG is absurd. When
s
Now: A Lesser IESG Is A Better IETF -- Was: RE: WAP and IP
On Mon, 26 Jun 2000 08:04:34 +0200, Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= [EMAIL PROTECTED] said: After 7 months of delay, caused by the IESG, ESRO was published as an RFC in Sept. 1997. Patrik There have already been enough discussions on the IETF list about Patrik ESRO. See the archives. Patrik You seem to (once again) ignore the problems with making protocols Patrik interoperate. Patrik The rest of this discussion exists in the IETF mailing list archives. There is one remaining issue relating to ESRO which is worth pointing out. On Nov 10 1998, the IETF Chair -- Fred Baker [EMAIL PROTECTED] -- said: --- From: Fred Baker [EMAIL PROTECTED] To: Mohsen BANAN [EMAIL PROTECTED] Cc: IETF Mailing List [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], RFC Editor [EMAIL PROTECTED], Internet Architecture Board [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO) Date: Tue, 10 Nov 1998 06:50:00 + Message-Id: [EMAIL PROTECTED] This is to advise you that I have received your note, and expect to rep= ly for the IESG. The basis of that reply will be RFC 2026. Fred Baker IETF Chair --- I expected the IETF Chair, as representative of the IESG, to be as good as his public word. However, more than a year and a half later, I have yet to receive a reply. Did I miss something? Where is the promised reply? - Equal access to RFC Publication Service Patrik This is not possible, as a review process is guaranteeing the quality Patrik of the work published. For the various tracks, different reviews are Patrik done. For informational (such as ESRO) the RFC-Editor is deciding Patrik whether something is good enough, and asks for input from the IESG. Patrik Issues which were discussed heavily regarding your two protocols are: Patrik - Congestion control Patrik - Ability to gateway to/from existing standards Patrik - Internationalization issues Patrik - Security If you want to understand the design of EMSD and contribute to its evolution, join mailto:[EMAIL PROTECTED] Patrik See IESG note in the beginning of RFC 2524. Patrik All new protocols have to address those issues, as the experience we Patrik have with the protocols we have today gives that those issues Patrik (probably) were not addressed enough in those. Because we made that Patrik mistake once, we don't want to make the same mistake again. So, the Patrik IESG asks all people which write new protocols to address the issues Patrik above (and some others). In his e-mail Fred Baker said that IESG's response to my complaint would be based on RFC-2026. In other words, the IETF Chair is stating that the IESG operates according to RFC-2026. With respect to Non-IETF Informational RFCs the purpose and scope of the IESG review and "IESG Note" is well defined in RFC-2026. Untill this is changed, as an IESG member you are obligated to follow those procedures. What you have written above is in conflict with those procedures. I design my protocols my way. I don't need to be told by the IESG what is the right way and what is the wrong way and what requirements my protocols should be addressing. You and the rest of the IESG may not understand my design and may not like my design. With respect to Non-IETF Informational RFC publication, the scope of your involvement is limited to the situation in which there is conflict with existing IETF work. Because the IETF has nothing to offer in the area of Efficient Application Protocols, no conflict exsist. And therefore, according to RFC-2026 you had no legitimate authority to insert that IESG Note. The notion that the IESG/IAB has any sort of authority to guard the health of the "Internet" is simply bogus. When such self-proclaimed guardianship becomes the basis for obstructionism in the Non-IETF Informational RFC process, we have a serious problem. Over the past week, my goal has been to focus on "The WAP Trap", "The Search For Efficient Mobile Messaging Protocols", "LEAP: One Alternative To WAP" and "The Free Protocols Foundation". There has been a great deal of interest on the part of the Internet Technical Community in all of the above. Part of the above topics may have been considered a challenge of sorts to IETF/IESG/IAB's monopoly on protocols. The model that I and many others have adopted for working outside the IETF/IESG/IAB, but based on RFC publication, use of IANA, and patent-free Working Groups, is demonstrating certain deep problems. These problems are deep rooted. Others on this list have said that IETF stands for Innovation Extermination Task Force. That IETF is a Cult ... Many are concerned that IESG/IAB have become instruments of big business and standards politicians. Part of the cure lies in the notions of "Separation of Powers", "
The Non-IETF Informational RFC Publication Fiction
In 1997, D.J. Bernstein wrote a short note titled: RFC submission: a case study The full text of that note is available at http://cr.yp.to/proto/rfced.html D.J. Bernstein concluded his case study with the following paragraph. It's well known that the IETF is no longer the primary source of progress in Internet engineering. The only respectable activity left for the IAB, IESG, and IETF is to report what others have done. So I don't find it at all surprising that the IAB and IESG claim to have an open document series. Unfortunately, the claim is a lie. Unfortunately the situation has become even worse since 1997. The Non-IETF Informational RFC Publication process has now become quite Complex. It now has a Real component and an Imaginary component. The Imaginary component is that the process operates according to Section 4.2.3 of the Internet Standards Process (RFC-2026), where the RFC-Editor is an independent entity and where the scope and purpose of the IESG review is limited to what that section spells out. The Real component is that IETF/IESG/IAB is well on its way towards becoming a cult violating all published procedures. IETF/IESG/IAB now claims full ownership of the RFC Publication process and quashes whatever may want to compete with it or that it does not like. IETF/IESG/IAB often inserts notes in Non-IETF Informational RFCs which go above and beyond the scope and purpose of IESG review. IETF/IESG/IAB often regards the RFC-Editor as merely its agent. IESG/IAB has become a group of irresponsible volunteers who consider themselves accountable to no one. All concerned in this fiction: IETF/IESG/IAB cult leadership, the cult members themselves, various behind-the-scenes puppeteers, and Internet groupies appear perfectly happy with both the Real and Imaginary components of this Complex setup. I would also be happy if they would just acknowledge that the Imaginary part is in fact imaginary. ...Mohsen.
Re: The Non-IETF Informational RFC Publication Fiction
On Tue, 27 Jun 2000 15:48:50 GMT, Bob Braden [EMAIL PROTECTED] said: Mohsen Mohsen The Real component is that IETF/IESG/IAB is well on its way towards Mohsen becoming a cult violating all published procedures. IETF/IESG/IAB now Mohsen claims full ownership of the RFC Publication process and quashes Mohsen whatever may want to compete with it or that it does not Mohsen like. IETF/IESG/IAB often inserts notes in Non-IETF Informational RFCs Mohsen which go above and beyond the scope and purpose of IESG Mohsen review. IETF/IESG/IAB often regards the RFC-Editor as merely its Mohsen agent. IESG/IAB has become a group of irresponsible volunteers who Mohsen consider themselves accountable to no one. Mohsen Bob Mohsen, Bob One of the advantages of becoming a geezer is that you get to say what Bob you REALLY think. However, good taste prevents my telling you in public Bob what I REALLY think about your message. Bob I would like to remind you that, had the RFC Editor been "a mere Bob agent" of the IESG, your EMSD RFC 2524 would not have been Bob published at all. That is true. In the case of RFC-2524, the RFC Editor did demonstrate independence. I believe I also played a significant role in establishing the RFC Editor's independence based on my insistence on doing it by the book. Complete communication records related to publication of RFC-2524 are available through http://www.emsd.org/ In the case of RFC-2188, the RFC Editor did *nothing* and just waited for the IESG for more than 7 months. That is well documented. I have heard of various other reports of IESG's interference. See DJB's case study for example ... My exact words were: Mohsen IETF/IESG/IAB often regards the RFC-Editor as merely its agent. ^ That is why I said, "often". ...Mohsen.
RE: WAP and IP
On Sat, 24 Jun 2000 08:38:38 +0200, Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= [EMAIL PROTECTED] said: Patrik At 00.31 + 00-06-24, Mohsen BANAN-Public wrote: IETF/IESG/IAB folks keep saying TCP is good enough for everything. Patrik We don't. Patrik See for example SCTP described in draft-ietf-sigtran-sctp-09.txt and Patrik applied to many applications which for example have to do with Patrik telephony signalling. The current status, state and beginning date of that example makes my point. After 7 months of delay, caused by the IESG, ESRO was published as an RFC in Sept. 1997. Patrik You can also have a look at the proposed charter for the Blocks Patrik eXtensible eXchange Protocol (bxxpwg) WG which might help Patrik applications designers get around some problems with TCP. Patrik Patrik Patrik Area Director, Applications Area As far as Efficient Application Protocols go, the examples that you cited are in my eyes a day late and a dollar short. There is work out there which is way ahead of where you seem to be. In the early stages of formation of an industry (such as Mobile Applications) competition amongst open and patent-free protocol specifications is of benefit to all. I am all in favor of creating a free market for such protocol specifications. This involves *equal* access to all protocol support organizations including: - Equal access to RFC Publication Service - Equal access to IANA - Equal access to patent-free support facilities - Equal access to announcement and information distribution facilities. Such an approach can lead to better containment of IESG/IAB/... and stop, in practice, the drift towards becoming a cult. In the area of Efficient Application Protocols and alternatives to WAP let's all put on the table what we have got and build on that. ...Mohsen
RE: WAP Is A Trap -- Reject WAP
On Wed, 21 Jun 2000 11:05:43 -0400, "Brijesh Kumar" [EMAIL PROTECTED] said: Brijesh PS: By the way, ReFLEX is perfectly fine for two way messaging Brijesh applications. Mohsen No. Mohsen Mohsen ReFLEX is not perfectly fine. Mohsen Mohsen It is not IP based. Brijesh Hi Mohsen, Brijesh What kind of argument is this? You used the words "ReFLEX is perfectly fine for ...". I could have challenged that claim based on any of several points that you yourself mentioned. I chose the IP argument because it is the most powerful and least obvious one in the case of ReFLEX. ReFLEX is not IP based and it could have been IP based. Brijesh If it is not IP based it is not good ! This is an emotional response, Brijesh not a technical one. Using the same arguments, the whole phone system Brijesh isn't good because it has nothing to do with IP (or at least was true Brijesh till VoIP came), and same is true of all G2 TDMA, CDMA and GSM Brijesh cellular systems (and don't forget AMPS, CDECT and many other wireless Brijesh standards). The networks that you have mentioned above were in place before IP's power became clear. That is a legitimate excuse for their non IP nature. I would say the knee of the curve was in 1992. ReFLEX on the other hand can not use that excuse because it came after 1992. ReFLEX's Narrowband PCS licenses came out in 1995. The remaining excuse for ReFLEX not being IP based is efficiency. It is very feasible and reasonable to build a highly efficient IP based slow wireless network. An initial such attempt using the Narrowband PCS spectrum (same as ReFLEX) was called pACT. The failure of pACT was due to ATT's business withdrawal in 1997 -- not technology. pACT could have been real competition for ReFLEX. Derivatives of pACT related work are in use in bandwidth constrained environments. The last leg of IP in wireless environments can be made highly efficient. In this day and age, citing efficiency as a rationale for building a non-IP based network is a lame excuse. Later you said: On Thu, 22 Jun 2000 11:39:11 -0400, "Brijesh Kumar" [EMAIL PROTECTED] said: Brijesh Let us take case of a CDPD device that has a IP address. CDPD has one Brijesh of the largest coverage in US and is geared for data communication. Brijesh Now CDPD works at 19.2 Kbps, and uses spare capacity from AMPs Brijesh channel, and when no channel is available that a device looks for Brijesh voice gaps in other channels to send data. I am one of the primary architects of the CDPD Specifications -- starting with rev. 0.3 in Dec. 92. I would like to believe that the main reason why CDPD is IP based is because of my involvement. Prior to my involvement it was not IP based. Brijesh With these kind of losses TCP Brijesh throughput tanks!. So we need a wireless medium aware version of TCP Brijesh or some hacks for TCP to be efficient under losses (see relevant Brijesh literature). Others (Steve Deering, Vernon Schryver, ...) have already pointed out that above layer 3, wirelessness is irrelevant. When it comes to wirelessness, above layer 3 the name of the game is "EFFICIENCY" -- and all dimensions of it. There is a place for something else in addition to TCP, but not for the reasons that you mentioned. More on this later. ...Mohsen.
Re: WAP Is A Trap -- Reject WAP
On Tue, 20 Jun 2000 19:02:39 +0100 (BST), Lloyd Wood [EMAIL PROTECTED] said: Lloyd And from that anti-WAP polemic: Mohsen We gratefully acknowledge the assistance of the Mohsen following persons in the preparation and review of Mohsen this document: Andrew Hammoude, Richard Stallman, Mohsen Bill Frezza and Rob Mechaley. Lloyd it's rms's 'do not use Tcl because I say so' all over again! Please target ALL your criticisms of "The WAP Trap" to it author, Mohsen Banan. I wrote that paper. The paper represents my positions. The heart of "The WAP Trap" revolves around patented protocols. RMS's involvement in the Free Protocols Foundation is centered around the harm of patented protocols. That is consistent with his track record and leadership on this issue. Do you have anything against patent-free protocols and in favor of patented protocols? If not, then you, RMS and I are on the same side of this issue. Lloyd will be quite happy if WAP fails on its own merits, thankyouverymuch. WAP will fail on its own merit. The main issue here is "patents" and "protocols". Most of the discussions on the IETF list so far has been techie-talk. I also want to worry about the bigger picture. Should we just wait for the next WAP, where businessmen and marketeers pull another fast one on the industry? My paper says that we can take certain steps to prevent that. ...Mohsen.
Re: idea for Free Protocols Foundation
On Wed, 21 Jun 2000 10:17:25 -0700 (PDT), "James P. Salsman" [EMAIL PROTECTED] said: James The Free Protocols Foundation is correct in their position. James The amount of misrepresentation in the industry is becoming James absurd. Most of it is bait-and-switch, but beyond the James consumers hurt by it, shareholders are sure to be, too. As founder of the Free Protocols Foundation (FPF), of course I could not agree with you more. Most of the feedback that we have received about the general concept of Free Protocols has been very positive. However, up to now the policies and procedures that we propose have not been widely reviewed. Soon after this note, I will send a copy of the FPF Policies and Procedures to this list for review. Those of you interested in pursuing this concept further are invited to participate in the mailing lists set up at FPF web site at http://www.freeprotocols.org/ or to send your subscription request to mailto:[EMAIL PROTECTED] I am willing to carry the ball for the FPF cause for a while and can certainly benefit from the participation of others in this non-profit organization. Those of you wishing to contribute towards this cause in any way, can drop me note. Regards, ...Mohsen.
Free Protocols Foundation Policies and Procedures -- Request For Review
I request that you review the attached document and email us your comments to: mailto:[EMAIL PROTECTED] This is what I consider a reasonably complete version of the policies and procedures which is likely to bring a lot of good in the area of Internet protocol development. If the Free Protocols Foundation policies become better understood and known, then traps such as WAP have less of a chance to be successful. Those of you interested in pursuing this concept further are invited to participate in the mailing lists set up at FPF web site at http://www.freeprotocols.org/ or to send your subscription request to mailto:[EMAIL PROTECTED] Thank you in advance for reviewing this document and for your comments, suggestions and ideas. ...Mohsen. The Free Protocols Foundation Policies and Procedures www.FreeProtocols.org Version 0.7 May 10, 2000 Copyright 2000 Free Protocols Foundation. Published by: Free Protocols Foundation 17005 SE 31st Place Bellevue, WA 98008 USA Permission is granted to make and distribute verbatim copies of this document provided the copyright notice and this permission notice are preserved on all copies. Contents 1 Introduction 1.1 The Free Protocols Foundation Mission 1.2 The Patent Debate 1.3 How Patents Affect Protocols 1.4 Difficulties Relating to Software and Protocol Patents 1.5 Terminology 1.5.1 Definitions 1.6 About the Free Protocol Policies and Procedures 1.7 About this Document 2 The Protocol Development Process 2.1 Phases of Development 2.1.1 Initial Protocol Development 2.1.2 Global Parameter Assignment 2.1.3 Protocol Publication 2.1.4 Patent-Free Declarations 2.1.5 Industry Usage 2.1.6 Maintenance and Enhancement 2.1.7 Endorsement by a Standards Body 2.2 Role of the Free Protocols Foundation 2.3 Comparison to Standards Organization Processes 2.3.1 Centralisation vs. Decentralization of Responsibility 2.3.2 Coordination of Activities 2.3.3 Selective vs. Egalitarian Patent-Freedom 3 The Free Protocols Foundation 3.1 General Philosophy 3.2 Purpose, Activities and Scope 3.3 Other Activities 4 Free Protocol Development Working Groups 5 Patent-Free Declarations 5.1 Author's Declaration 5.2 Working Group Declaration 6 Patents, Copyright and Confidentiality - Policy Statement 6.1 Policy Statement Principles 6.2 General Policy 6.3 Confidentiality Obligations 6.4 Rights and Permissions of All Contributions 6.5 FPF Role Regarding Free Protocol Specifications 1 Introduction 1.1 The Free Protocols Foundation Mission --- Software patents pose a significant danger to protocols. In some cases patents become included in protocols by accident -- that is, without deliberate intentionality on the part of the protocol developer. In other cases, however, an unscrupulous company or organization may deliberately introduce patented components into a protocol, in an attempt to gain market advantage via ownership of the protocol. In either case, the protocol can then be held hostage by the patent-holder, to the enormous detriment of anyone else who may wish to use it. The inclusion of software-related patents in protocols is extremely damaging to the software industry in general, and to the consumer. The mission of the Free Protocols Foundation is to prevent this from happening. We have defined a set of processes which a protocol developer can use to work towards a patent-free result, and we provide a public forum in which the developer can declare that the protocol conforms to these processes. As described below, it is not possible to provide an absolute guarantee that any particular protocol is truly patent-free. However, the Free Protocols Foundation processes allow a developer to provide some public assurance that reasonable, good-faith measures have been taken to create a patent-free protocol. In some cases, standards organizations, such as the IESG, make use of their own processes for developing patent-free protocols. However, these processes are available only for the organization's own internal use. The Free Protocols Foundation makes the same general processes available to any protocol developer. Its processes allow any company, organization or individual to develop patent-free protocols, without requiring the developer to be part of a formal standards organization. At the Free Protocols Foundation we strenuously oppose the creation and promotion of patented protocols. By providing clear mechanisms and assurances of patent-freedom, our goal is to make it abundantly clear to the industry at large whether a particular protocol is, or is not, patent-free. 1.2 The Patent Debate
RE: WAP Is A Trap -- Reject WAP
On Tue, 20 Jun 2000 10:30:31 -0400, "Brijesh Kumar" [EMAIL PROTECTED] said: Brijesh It is an open secret that wireless industry is a closed cartel of Brijesh three super heavyweights (Motorola, Ericsson, and Nokia) and two heavy Brijesh weights (Lucent and Nortel). There is no role for any smaller Brijesh organization in the set up. Hope God give you wisdom to accept this Brijesh truth with cheerfulness, as many other small companies in the wireless Brijesh industry have accepted ;-). I don't want that "wisdom". I want to challenge the status quo based on the power of truly open protocols, the Internet end-to-end model and free software. The WAP Trap paper is just a beginning ... What you call super heavyweiths, I call dinosaurs. Those "heavyweights" who have placed their bets on WAP, are now caught in their own mess. WAP introduces the Phone Company -- equipped by the likes of Phone.Com -- as a fictitious middle man acting as a gate-keeper. While gate-keepers are an integral part of the tele-com model, they have no place in the data-com world. I full agree with Phil Karn when he says: On Tue, 20 Jun 2000 12:36:47 -0700 (PDT), Phil Karn [EMAIL PROTECTED] said: Phil One thing missing from most block diagrams of WAP is the chute on the Phil bottom of the carrier's WAP gateway pouring out money. It's safe to Phil say that this chute is WAP's primary reason for existence. Phil WAP has gotten as far as it has (which isn't very far) only because Phil cell phones are closed, proprietary devices. The end user has no Phil choice which software or protocols it runs. The vendors make that Phil decision for you. Phil ... Phil The Internet end-to-end model will once again prevail, putting the Phil cellular service providers back into their proper place as providers Phil of packet pipes, nothing more. And life will be good again. :-) As for, Brijesh PS: By the way, ReFLEX is perfectly fine for two way messaging Brijesh applications. No. ReFLEX is not perfectly fine. It is not IP based. ...Mohsen.
Re: WAP Is A Trap -- Reject WAP
On Wed, 21 Jun 2000 04:59:15 +0859 (), Masataka Ohta [EMAIL PROTECTED] said: The Internet end-to-end model will once again prevail, putting the cellular service providers back into their proper place as providers of packet pipes, nothing more. And life will be good again. :-) Masataka IP over NAT is, in no way, end-to-end. Point taken. NAT is not end-to-end. End-to-end is good karma. Masataka WAP and IP over NAT are equally bad. We have two sets of problems and layering helps here. At layer 3, we need to make things end-to-end. At layer 7, the WAP approach is simply the wrong approach. We need competition in the efficient appliction protocols space. As you pointed out more than a month ago: Masataka To make the competition fair, the important questions are: Masataka Is it fair if providers using iMODE or WAP are advertised Masataka to be ISPs? Masataka Is it fair if providers using NAT are advertised to be ISPs? Masataka My answer to both questions is Masataka No, while they may be Internet Service Access Providers and Masataka NAT users may be IP Service Providers, they don't provide Masataka Internet service and are no ISPs. Which in my thinking is equivalent of saying that WAP is at best an Internet gateway model. Which is consistent to my position in The WAP Trap paper ...
