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=40057&pub=tt&categoryid=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?
>>>>> On Fri, 02 Mar 2001 15:35:02 +0700, "Rahmat M. Samik-Ibrahim" <[EMAIL PROTECTED]> >said: Rahmat> Mohsen BANAN-Public wrote: >> Did you follow the discussions that I initiated on >> a similar set of topics on the [EMAIL PROTECTED] >> mailing lists about two years ago? Rahmat> Nope, but what was the conclusion? Where (URL) is it archived? That thread is part of the [EMAIL PROTECTED] archives. You can use the date and subject of my previously included message to refer to the rest of that discussion. Separately, I'll email you a segment of my own archives of that thread. Rahmat> Basically, my question was because of IAB's assertion Rahmat> in RFC-2826 "IAB Technical Comment on the Unique DNS Root" Rahmat> ( http://www.faqs.org/rfcs/rfc2826.html ) That document does not say much other than - DNS has these limitations - We should live with it - IAB can't (or does not want to) move forward What I am proposing keeps DNS names unique at all times, and allows for existance of multiple root server clusters. The solution relies on viewing the problem not as just a DNS problem but as a DOMAIN NOTATION limitation and problem as well. We can easily extend the Domain Notation and solve the problem. Time is not on the side of those who want to live with the DNS limitations. Legitimacy of the root server cluster comes from the users who point to them. Large communities of users (AOL, Chinese government, Microsoft, ...) can easily extend the name space and they can even extend the Domain Notation. If such efforts diverge, we'll end up with a real mess. Remember Halloween, remember "Embrace and Extend", remember "Instant Messaging", ... I propose that instead of waiting, we do something about it. See my previous message. In this case, scarcity in the DNS implementation gene pool (i.e., bind) can be viewed as an asset. I would love to hear from the bind team why what I am proposing can not be workable. >> Bob Allisat <[EMAIL PROTECTED]> followed up on that idea... Rahmat> I am not aware that he is interested in the technical aspect Rahmat> of DNS. Correct. Participation of Bob Allisat in this mailing list was often as a "User Advocate". As a tough user advocate, he looked at what I had proposed and supported it. That was of significance to me. The DNS-ng solution should revolve around allowing the user to choose amongst competing root server clusters and naming authorities. Once that concept has been recognized, the rest of the technology is real simple. Rahmat> Perhaps, we should discuss this in private. What I have in Rahmat> mind is somewhat of an "address book" that is publicly Rahmat> accessible, perhaps through an ordinary DNS. Since it is Rahmat> publicly accessible, it can be shared/adopted by others. Okay. I'll follow up privately soon. ...Mohsen.
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 coming together, the domain notation's backwardne
Re: TCP for Transaction (T/TCP) protocol
> On Fri, 12 Jan 2001 13:25:09 -0500, "Hung Pham" <[EMAIL PROTECTED]> said: > On Fri, 12 Jan 2001 20:25:39 + (GMT), Lloyd Wood <[EMAIL PROTECTED]> >said: Hung> Hello; Hung> I'm interested in the "TCP for Transaction or T/TCP" protocol, Hung> basically this protocol collapses the TCP three way handshake to a Lloyd> five-way, if you remember the two at the _end_ of the connection... Hung> single message to reduce latency overhead. Lloyd> while increasing processing load and opening the door further to Lloyd> effective denial-of-service attacks, since buffers must be allocated Lloyd> for data immediately by the receiver before the sender is verified. The problem domain which T/TCP attempts to address is clearly valid. However, I agree that T/TCP's approach of being bundled with TCP is not effective and pragmatic. There are various other protocols (including ESRO -- RFC-2188) which address the same problem space as T/TCP. A survey of these protocols and my assessment of where they fail is included in the article: ESRO: A Foundation for the Development of Efficient Protocols = available through: http://www.leapforum.org/LEAP/Manifesto/article/ESROcomponent/one/index.html The segment related to mention of other protocols in the reliable RPC (transactions / reliable connectionless transports) problem space is reproduced below in plain text format. Those interested in further discussing this topic are invited to join the relevant mainling lists at http://www.esro.org/ and http://www.leapforum.org/ ...Mohsen. -- 2 Other Related Protocols == The overall model of ESRO is similar to and consistent with many existing protocols. The distinguishing characteristic of ESRO is its efficiency. Also, the scope of ESRO is very narrow and well defined. The options and selections that it provides for are few and clear. A brief comparison of ESRO to other similar protocols is provided in the sections below. 2.1 RPC Remote Procedure Call (RPC) is specified in RFC-1831 [24] and RFC-1833 [23]. The RPC specifications define a remote procedure model that is essentially the same as ESRO. However, the notation of RPC uses a syntax which is quite different from that of ESRO. RPC can rely on a connection-oriented or a connectionless transport mechanism. When using the connectionless mechanism, the retransmission and reliability issues are considered to be beyond the scope of the RPC specification. RPC is usually used in combination with External Data Representation, XDR (RFC-1832) [25]. When using RPC over UDP, no meaningful reliable transport mechanism is defined. For this reason use of RPC over UDP has been limited to LANs. 2.2 ROSE - Remote Operations Services Element (ROSE) is specified in [7] and [8]. ROSE is a complete and heavyweight traditional OSI application which assumes availability of all of the underlying OSI layers. The ESRO protocols can accomplish short operations with much less overhead than ROSE. 2.3 WAP's WTP -- The Wireless Appliction Protocol (WAP) includes a layer which is similar to ESRO, called ``Wireless Transaction Protocol'' (WTP) [1]. The WTP specification was published after ESRO was published, and is similar in functionality to ESRO. In many ways WTP can be considered to be patterned after ESRO; however, WTP is in fact a step backwards. The clear and simple Remote Operations model of ESRO is renamed as ``Wireless Transactions'' in an inappropriate context. The notation specification conventions are not used, and the state machines are not as robust. More importantly, the WTP specifications are not stable, have not been published as Internet RFCs, and have not been declared to be patent free. As early as 1995, those involved in the development of WTP were made aware of LSROS and ESRO. The only reason we know of for their re-specification of WTP, rather than re-use of ESRO, is the WAP Forum's desire for control. More details on the problems of the WAP Forum's approach are provided in the article The WAP Trap [18]. 2.4 T/TCP -- Transaction/TCP is specified in [5] and [6]. T/TCP is a backwards-compatible extension of TCP which provides efficient transaction-oriented service in addition to virtual-circuit service. Use of T/TCP often involves replacing existing TCP implementations. This non-evolutionary aspect of T/TCP is one of the reasons why T/TCP has not been widely adopted. Various lessons can be learned from why T/TCP has not been widely adopted. 2.5 RDP Reliable Data Protocol (RDP) is specified in [11] and [10]. RDP can be considered to be a specialized TCP, specified for particular circumstances in which some of TCP's facilities are needed. One of the reasons why RDP has not been heavily used is because the set of specialized circumstances that it addr
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
Re: Topic drift Re: An Internet Draft as reference material
> On Sat, 30 Sep 2000 20:52:53 -0400, Eric Brunner-Williams <[EMAIL PROTECTED]> >said: >> And what WG? Internet Drafts were and are generated by Individuals w/o >> benefit of an associated WG. Eric> Precisely my point to Grenville. Furthermore, the author may have nothing to do with IETF. The author may just want to circulate an idea to the Internet technical community for informal review or the author may want to publish a none IETF RFC. Seperation of powers, checks and balances, definition of scope of responsibility and accountability are the concepts that are missing from the IETF. In cults, even simple things get mixed up. RFC and Internet-Draft (not IETF-Draft) publication and archiving should be responsibilities of the RFC-Editor. Too bad the RFC-Editor Complex is mostly Imaginary and very little Real. I agree with some of Mike's observations: > On Sat, 30 Sep 2000 09:14:25 -0400, "Mike O'Dell" <[EMAIL PROTECTED]> said: Mike> ... Mike> instead, people decided to continue insisting that Mike> reality was as they desired, not as it is. Mike> until this get fixed, worrying about any one Mike> incident is worse than pointless - it continues Mike> the denial. And to those who want to address protocol patent related issues: Is it too wild to suggest that the patent issue can be seperated from protocol development and the publication of the proctocol specification? Something other than IETF which can specialize in promoting and protecting patent-free protocols could perhaps keep its own repository of I-Ds and other docs for that particular purpose. Based on separation of responsibilities we can easily create a highly dis-centralized and healthy Internet technical community. In that environemnt, an ill defined entity such as the IETF can then stick to protocol development (not publication, not patent-freedom, not commenting on work of others, not ...) and compete with others in the Internet technical community in the area of patent-free and RFC published protocol development. A lesser IETF/IESG/IAB makes a better Internet. ...Mohsen.
RE: Multimedia EMSD? (was Re: Mobile Multimedia Messaging Service)
> On Mon, 18 Sep 2000 12:04:10 +0300, [EMAIL PROTECTED] said: petri> Hi, petri> We don't need yet-another mail delivery protocol by some new forum. petri> We have already e.g. SIP which is capable of carrying MIME messages, petri> including multipart petri> and which supports capability negotiation. If you want to go after the Mobile set of requirements, then you need to deal with "Efficiency". See "The Efficiency of EMSD" paper in The LEAP Manifesto -- http://www.leapforum.org/ -- for details. If you think that Efficiency is not relevant in the Mobile Multimedia Messaging Service problem space, then you don't need yet-another mail delivery protocol. Grep for the word "Efficient" on the title of RFC series and see what you get. ...Mohsen.
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: Mobile Multimedia Messaging Service
To: The Internet Technical Community > On Sat, 16 Sep 2000 17:44:56 -0700 (PDT), "James P. Salsman" <[EMAIL PROTECTED]> >said: James> (1) End-to-End Internet Services for Mobile Devices James> Scope: Specifications and interoperability guidelines for James> end-to-end mobile IP connection and transport services required James> for support of standard Internet messaging ... The beauty of the Internet End-to-End model is that people don't have to wait for the IETF to create a working group, a charter, a chair, , blessings, to move forward. Remember the web (http, ...)? What was IETF's role in Internet's main modern application? As far as the domain of Internet services for mobile devices go, the key issue is "Efficiency". Completely outside of the IETF but in the tradition of Internet technical community which includes: - Stable and wide publication (RFC publication) - Patent-Free Specification - Open working group protocol development and maintenance A large body of work exists which addresses the Mobile Messaging area. It is called LEAP: Lightweight and Efficient Application Protocol. To fully describe our vision of the Mobile Messaging industry, there is a 200 page document called: "The LEAP Manifesto" The LEAP Manifesto addresses every topic so far touched on in this thread -- and a great deal more. Those who believe in the IETF's exclusivity in protocol development can start from scratch and form yet another working group, write yet another charter, and go and talk, ... 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/ The main current areas of work for LEAP are: - Efficient Security Services - Compact Markup Languages - Portation of the reference implementation to additional platforms Those interested are invited to join the relevant mailing lists. In the early stages of formation of an industry, competition amongst open protocols is healthy. ...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.
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.
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", "Independence Of Protocol Sup
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 le
LEAPing Over WAP
Attached is a short description that introduces LEAP: Lightweight & Efficient Application Protocols as an alternative to WAP. The full description is part of the LEAP Manifesto. -- LEAP: One Alternative to WAP Mohsen Banan <[EMAIL PROTECTED]> Version 0.3 June 23, 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. 1 Introduction Over the last few years, data communications has expanded dramatically and forcefully into the wireless environment. A major new Internet reality is that of wireless networks, providing service to legions of miniaturized, hand-held mobile devices. This reality has placed 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. Existing Internet protocols do not adequately meet these requirements. Therefore a new generation of efficient protocols is needed, to satisfy the demands of wireless applications. At some point, the wireless data communications industry must agree on a single set of protocols that satisfies its requirements. 1.1 The WAP Trap -- In April 1998, a business association called the WAP Forum published the Wireless Application Protocol, or WAP. WAP is a set of specifications for wireless data communications using hand-held devices such as mobile phones and palmtop computers. The WAP specification provides the users of these devices with mobile data communications capabilities such as web-browsing and e-mail. In a previous article entitled The WAP Trap [4], however, we have argued that WAP is utterly unfit for its claimed purpose. 2 The Need for Efficiency == 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 efficiency, and bandwidth efficiency. The 1980s and 1990s were the decades of simple protocols - protocols such as the very aptly named Simple Mail Transfer Protocol (SMTP), and Simple Network Management Protocol (SNMP). A great deal of the success of these and other Internet protocols can be attributed to their simplicity. However, things have changed. Network communications has now expanded into the wireless and mobile data communications arena, and wireless applications demand efficiency. The move to wide-area wireless has significantly shifted the location of the ideal engineering balance between simplicity and performance - moving it away from simplicity, and towards performance. We therefore need a new generation of high-performance, efficient protocols, to cater to the demands of wireless applications. The point is sometimes made that the need for efficiency in the wireless arena is a temporary one -- that advances in wireless engineering technology in the form of third generation (3G) systems will eliminate existing bandwidth limitations, obviating the need for efficient protocols. As long as the capacity of wireless networks remains finite, however, the need for efficiency will persist. Efficient usage is an inherent requirement for any finite resource, therefore the requirement for efficient bandwidth usage and battery longevity will remain. Thus far, professional protocol and standards producing associations, most notably represented by the IETF, have failed to produce an acceptable specification. The IETF continues to represent the tradition of simple protocols, a tradition which wireless communications has now made obsolete. 3 LEAP: The Lightweight & Efficient Application Protocols == It is now time for a new generation of protocols to be implemented, designed to address the need for performance, rather than simplicity. The Lightweight & Efficient Application Protocols, or LEAP, are designed precisely to address this need. LEAP is the general framework for a set of high-performance, efficient protocols which are ideal for mobile and wireless applications. LEAP is designed to address the technical requirements of the wireless data communications industry, and is oriented towards providing the greatest benefit to the industry and the consumer. The LEAP protocols are patent-free, and open-source implementations of the protocols are being made available for a variety of devices and message-center platforms. The protocols are thus ready and available, and can be quickly distributed and implemented as a viable altern
Seeking Open Mobile Messaging Protocols -- Efficient E-Mail
Existing SMTP/IMAP/TCP technology is not well suited for
mobile and wireless environments where bandwidth and
capacity are always limited and precious.
More efficient protocols are needed to address the new
reality of mobile and wireless networks. I am seeking
open protocols which are better suited to address the
requirements of mobile and wireless networks.
The key functional requirements for the protocols that
I am seeking are:
- Provide for the submission and delivery of short
(4 kilobytes or less) Internet e-mail messages
with the same level of functionality (or higher)
that the existing SMTP protocols provide.
- Provide the same (or better) level of reliability
and security that the existing SMTP protocols provide.
- Make reasonable trade-offs between specification complexity,
implementation complexity, extendibility, scalability and efficiency.
- Provide the required efficiency characteristics. These include:
minimizing the number of transmissions, minimizing the number of
bytes transmitted, minimizing the latency of message
submission and delivery.
The protocols I seek are intended to be used primarily
in IP based wide area wireless environments (e.g., CDPD)
The devices used have a wide variety of form factors and
platforms.
Timely delivery ("push") to unconscious carry devices
similar to the two-way paging model is also an important
goal.
The origin of the open protocols that I am seeking can
be any individual, company, or organization, provided:
- The protocols are intended to be patent-free and are
declared as such.
- They are published as stable specifications and are
readily and permanently available to anyone.
RFC publication is the prefered method.
- Participation in the maintenance and enhancement of the protocols
is public, open and free. The maintenance process must
also be such as to maintain the patent-free nature of the protocols.
The absence of a set of open protocols satisfying these requirements
has led to the adoption of patented protocols such as WAP, and the
appearance of closed systems such as BlackBerry (tm).
I consider the availability of open alternatives in this
area to be of benefit to the consumer and the industry.
If you are aware of any protocol specifications which
address the above mentioned requirements please send me
--
Mohsen BANAN mailto:[EMAIL PROTECTED]
--
a note. I will compile the results, then make publicly available.
Please feel free to distribute this request wherever appropriate.
Thank you.
Mohsen BANAN
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 +0000 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 and IP
> On Thu, 22 Jun 2000 17:10:16 -0600 (MDT), Vernon Schryver ><[EMAIL PROTECTED]> said: >> From: Harald Tveit Alvestrand <[EMAIL PROTECTED]> >> ... >> >Add to >> >that even if there was enough bandwidth, small screen's on some of the >> >today's devices can't meaningfully display all contents of modern web >> >sites. >> >> Neither can Lynx, a popular text-mode browser. >> >> The fact is that the Internet was developed *in* and *for* the bandwidth >> and display capabilities that WAP currently is claiming to be designed for. >> It just scaled well. Vernon> That bears repeating, although few of the WAP enthusiasts and other Vernon> advocates of fix TCP for QOS and modern radio telephone links will hear. Perhaps the I* (IESG/IAB...) folks suffer from a similar hearing problem. Please listen: There is a genuine need for a reliable efficient transport that accommodates *short* and *occasional* exchanges. There are many occasions where UDP is too little and TCP is too much. IETF/IESG/IAB folks keep saying TCP is good enough for everything. And they interfere with the work of others addressing the efficient applications domain. RFC-2188 (Efficient Short Remote Operations) is one solution to this problem space. http://www.esro.org/ deals with this topic in detail. Much of the design rationale and trade-offs made in the design of ESRO may not be obvious to those who are not willing to dig deep enough. Those who want to discuss or challenge the ESRO design can join the esro-spec mailing list by sending a message to mailto:[EMAIL PROTECTED] ESRO addresses the same problem space as WTP. It may be worthwhile mentioning that WAP's WTP appears to be related to previous work that was published as LSROS (Limited Size Remote Operations) by the CDPD Forum in 1995. I personally participated actively in the development of LSROS. Efficient application protocols is a new topic for most. Go to your favorite RFC repository and search for "efficient" in the title field. See what you get. We are now moving beyond "Simple Protocols," and "Efficient Protocols" are in big demand. Much work has already been done on this front and there is no need for the IETF/IESG/IAB to re-invent things just because the source of the work is not under their control. While the right implementations of TCP are just fine for transfer of larger pieces of information in most (if not all) wireless environments, transfer of occasional short messages is a different matter. In order to make some of this to fall into place, let me offer a concrete example. Let's consider the problem space of Mobile Messaging over wireless IP networks. Let's try to submit and deliver 10 short but important email messages per day over a wide area wireless network. This in fact is a very real problem. Given the existing SMTP/IMAP/TCP technology the best you can do is a minimum of 9 PDU exchanges per submission/delivery. Not very good at all. The next step is what Dan J. Bernstein has done with QMTP and QMQP which gets to a minimum of 5 PDU exchanges. That is as good as it gets when using TCP. So why has QMTP... not been published as an RFC? I understand Dan Bernstein did submit it for publication. In order to do anything beter than 5 PDU exchanges we need something other than TCP. The combination of ESRO and EMSD can do the job in 3 PDU exchanges most of the time. EMSD (Efficient Mail Submission and Delivery) has been published as RFC-2524. More information on the above example is available at http://www.emsd.org/ In wide area wireless environments, where capacity is always limited and precious, these 9-to-3 or 5-to-3 factors are significant enough to justify something other than TCP for short and occasional exchanges. Furthermore, one can not afford 9 bytes to encode "Subject: " in wide area wireless environments. Those days are over. Those who want to understand how EMSD and ESRO deal with congestion control, flow control, scalability, and so on, should join the above mentioned relevant mailing lists. Vernon> Still, all of this talk about WAP is irrelevant on the main IETF list. I have always considered [EMAIL PROTECTED] as a public forum of the Internet technical community. Any consideration other than that is likely to push things more in the "cult" direction. Without anybody's interference the discussions of the past few days have been evolving from WAP into a perfectly valid and legitimate topic of obvious general interest to the Internet technical community. That topic is Efficient Application Protocols. Vernon> The IETF is to WAP as the ISO or ITU is to TCP, or if you prefer, as Vernon> the IETF was to TP4. Only moribund standards organizations have the Vernon> time and energy to spare for critiques of the fun and games in other Vernon> standards outfits and industry consortia. WAP will fail on its own Vernon> merits and without the let, leave, or hindrance of the IETF. Agreed. The
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 AT&T'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.
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: 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.
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 ...
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.
WAP Is A Trap -- Reject WAP
[ Please distribute this as widely as possible, wherever appropriate. ] The WAP Trap An Expose of the Wireless Application Protocol Mohsen Banan <[EMAIL PROTECTED]> for: Free Protocols Foundation http://www.FreeProtocols.org Version 1.6 May 26, 2000 Copyright (c) 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 Wireless Application Protocol (WAP) 1.2 Characteristics of Successful Protocols 1.3 About this Document 1.3.1 Alternative Formats 1.3.2 Acknowledgments 1.3.3 Conflict of Interest Disclosure 2 WAP - A Procedural Fraud 2.1 Not Open in Terms of Development and Maintenance 2.2 No Assurance of Availability and Stability 2.3 Not Patent-Free 2.4 No Legitimacy as a Standard 3 WAP - A Technical Failure 3.1 User Interface Assumptions 3.2 Extreme Accommodation to Existing Networks 3.3 Excessive Re-Invention in the Name of Wireless 3.4 Vulnerable Wireless Transport Layer Security (WTLS) 3.5 Bungled Protocol Number Assignment 4 WAP - A Basic Misconception 4.1 The Wrong Answer Initially: Mobile Web Browsing 4.2 The Right Answer Initially: Mobile Messaging 4.3 Unsupported Claims 4.3.1 Not Device-Independent 4.3.2 Limited Web Browsing Capabilities 4.3.3 Existing Technology Adequate 4.3.4 Voice Interface Adequate 5 Conclusion: WAP is a Trap 6 Preventing the Harm of WAP 6.1 Reform the WAP Forum 6.2 Spread the Word about the WAP Fraud 6.3 Reject WAP at Engineering Level 6.4 Reject WAP at Consumer Level 6.5 Adopt an Alternative to WAP 7 LEAP: One Alternative To WAP 1 Introduction The new Internet reality is that of wireless networks, providing service to legions of miniaturized, hand-held mobile devices. This places an entirely new set of requirements on the underlying communications protocols -- they must provide the power efficiency demanded by hand-held wireless devices, together with the bandwidth efficiency demanded by wide area wireless networks. At some point, the wireless data communications industry must agree on a common set of standard protocols that satisfies these requirements. Unfortunately, the road to an industry standard is a rocky one. The wireless industry is populated by a number of disparate constituencies and self-interests. Among these constituencies are the technical community, with its fundamental mandate to create sound engineering solutions, and the business community, ultimately driven by the pursuit of profit and marketplace advantage. The differing agendas of these constituencies frequently bring them into conflict. In this confusing environment it can be very difficult to distinguish between developments that are genuine, enabling technologies, and those that are ill-conceived wild-goose chases. 1.1 The Wireless Application Protocol (WAP) - Into this chaotic arena comes WAP. On April 30 1998, a group of business interests published a set of specifications referred to as the Wireless Application Protocol, or WAP. WAP is a specification for wireless data communications using hand-held devices such as mobile phones and palmtop computers. Use of the WAP specification allows mobile devices to communicate with the Internet or an intranet, providing the users of these devices with mobile data communications capabilities such as web-browsing and e-mail. The WAP specification was developed by the WAP Forum, an industry association of wireless device manufacturers, service providers, and software companies. The WAP Forum was founded in June 1997 by three mobile phone manufacturers (Ericsson, Motorola and Nokia), together with the US software company Phone.com (formerly Unwired Planet). The WAP specification is largely the product of these four founding companies. Further information about the WAP Forum can be found at its website at http://www.wapforum.org/. The Wireless Applications Protocol purports to be just what the doctor ordered: a set of standards that will unify the wireless data applications industry. WAP presents itself as an open, license-free standard for wireless Internet access. It claims to be a well-designed engineering construction, allowing free interoperability among wireless industry vendors. It claims to be an enabling technology that will catalyze the development of the wireless industry, to the ultimate benefit of the industry and the consumer. As we will argue in this article, however, WAP satisfies none of these claims
Re: Do we have a formal way to send a one-line 'email' which is it's own subject?
> On Fri, 16 Jun 2000 11:56:57 -0700, "Dave Miller" <[EMAIL PROTECTED]> said: Dave> not chat :) Then, I assume what you are looking for is an Efficient Mail Submission and Delivery Protocol (EMSD) which is optimized for short messages. Look at RFC-2524 and RFC-2188. EMSD is roughly 5 times more efficient than SMTP for short messages that fit in a one-line 'email'. More on this later. ...Mohsen. P.S. What do you want this for?
