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 coming together, the domain notation's backwardness is becoming more visible and significant. - ... Since it
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 addresses do not justify
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: 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", "Independence Of Protocol Support Organizations", "Competition", and "Checks
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 ...
