Subject: RE: WAP and IP

From: Vernon Schryver <[email-masked]>
Date: Thu, 22 Jun 2000 17:10:16 -0600 (MDT)

> From: Harald Tveit Alvestrand <[email-masked]>

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

That bears repeating, although few of the WAP enthusiasts and other
advocates of fix TCP for QOS and modern radio telephone links will hear.

Some of us remember that TCP was commonly and productively used over links
that were slower than the WAP targets and with loss rates almost as bad.
Do you remember SLIP and later PPP over 1200 to 9600 bit/sec non-error
correcting or even error-detecting telephone modems?  There were also the
activities that made KA9Q famous involving radio links much slower and
with worse losses than WAP enthusiasts fear.  I don't suppose they know
or care about the connection between KA9Q and the Phil Karn who recently
wrote here about WAP.

The notion of an automagic converter to 60x80 resolution for almost
any of web pages I see daily says all that needs to be said about WAP
outside the corridors of the telephants, and since the telphants are
saying it, the rest of us needn't belabor it.  To be convinced, read
the non-technical press, such as that gushy, non-technical technophile's
weekly column in Thursday's "Wall Street Journal."  (oops--I see
today's column was written by a stand-in...nevertheless)

Still, all of this talk about WAP is irrelevant on the main IETF list.
The IETF is to WAP as the ISO or ITU is to TCP, or if you prefer, as
the IETF was to TP4.  Only moribund standards organizations have the
time and energy to spare for critiques of the fun and games in other
standards outfits and industry consortia.  WAP will fail on its own
merits and without the let, leave, or hindrance of the IETF.

Vernon Schryver    [email-masked]

P.S.  who coined "telephant"?

---

From: Mohsen BANAN-Public <[email-masked]>
Date: 24 Jun 2000 00:31:17 -0000

>>>>> On Thu, 22 Jun 2000 17:10:16 -0600 (MDT), Vernon Schryver <[email-masked]> said:

  >> and display capabilities that WAP currently is claiming to be designed for.

  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-masked]

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-masked] 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 question is what will replace WAP, and what role can we play in
shaping the right replacement?

Will IETF/IESG/IAB play a significant role in shaping the future of
Efficient Application Protocols?

Is it unreasonable to say that in the area of Efficient Protocols
IETF/IESG/IAB is currently inexperienced and has little to offer?

Is it unreasonable to suppose that innovation and rapid progress on this
front might come from outside the IETF/IESG/IAB? After all, this is
what happened with the Web, PGP and many others.

We have put in place a framework where others who are interested in
working on a set of protocols which: 

  - have been published as Internet RFCs
  - conform full to the FPF patent-free principles
  - are maintained by open public working groups

The umbrella name for these protocols is:

  "Lightweight & Efficient Application Protocols (LEAP)"

The general interest forum for the protocols is:

    http://www.leapforum.org/

This work open. It is free. 
And it is taking place outside the IETF/IESG/IAB.

...Mohsen.

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 24 Jun 2000 08:38:38 +0200

>IETF/IESG/IAB folks keep saying TCP is good enough for everything.

We don't.

See for example SCTP described in draft-ietf-sigtran-sctp-09.txt and 
applied to many applications which for example have to do with 
telephony signalling.

You can also have a look at the proposed charter for the Blocks 
eXtensible eXchange Protocol (bxxpwg) WG which might help 
applications designers get around some problems with TCP.

    Patrik
    Area Director, Applications Area

---

From: Mark Atwood <[email-masked]>
Date: 24 Jun 2000 20:57:00 -0700

Mohsen BANAN-Public <[email-masked]> writes:
> 
> So why has QMTP... not been published as

Sir! I am shocked, *shocked*, that you would imply that non-technical
politics would influence the RFC process! (Your winnings, sir. (Thank
you.))

-- 
Mark Atwood   | It is the hardest thing for intellectuals to understand, that
[email-masked] | just because they haven't thought of something, somebody else
              | might. <http://www.friesian.com/rifkin.htm>
http://www.pobox.com/~mra

---

From: Mohsen BANAN-Public <[email-masked]>
Date: 26 Jun 2000 05:30:15 -0000

>>>>> On Sat, 24 Jun 2000 08:38:38 +0200, Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]> said:

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

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 26 Jun 2000 08:04:34 +0200

>The current status, state and beginning date of that example

You are extrapolating the time it takes to get consensus around a 
document in a working group with people stating that TCP is good 
enough?

>After 7 months of delay, caused by the IESG, ESRO was published

There have already been enough discussions on the IETF list about 
ESRO. See the archives.

You seem to (once again) ignore the problems with making protocols 
interoperate.

The rest of this discussion exists in the IETF mailing list archives.

>    - Equal access to RFC Publication Service

This is not possible, as a review process is guaranteeing the quality 
of the work published. For the various tracks, different reviews are 
done. For informational (such as ESRO) the RFC-Editor is deciding 
whether something is good enough, and asks for input from the IESG.

Issues which were discussed heavily regarding your two protocols are:

  - Congestion control
  - Ability to gateway to/from existing standards
  - Internationalization issues
  - Security

See IESG note in the beginning of RFC 2524.

All new protocols have to address those issues, as the experience we 
have with the protocols we have today gives that those issues 
(probably) were not addressed enough in those. Because we made that 
mistake once, we don't want to make the same mistake again. So, the 
IESG asks all people which write new protocols to address the issues 
above (and some others).

So, regarding the protocols you have proposed, it is not the case of 
"better or worse than TCP", it is about "does the protocols proposed 
address all issues we _today_ think a new protocol have to fulfil. 
That doesn't say that the protocols we use today would pass if 
created today. We should though not swap from something bad into 
another thing not solving the problems we know exists.

      Regards, Patrik

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 26 Jun 2000 08:23:41 +0200

>After 7 months of delay, caused by the IESG, ESRO was published

History note:

ESRO (RFC 2188) was delayed, as far as I remember, because of lack of 
response from the authors to IESG comments; this turned out to be because 
the author either didn't get them or didn't think/understand that a 
response was needed.
I remember some apologies at the time, and the document was published 
without making the changes that the comments (some mine) had asked for.

ESRO was published without significant input from the IETF community, and 
has some aspects that I consider rather stupid (tied to a single UDP port 
number (4.6.3), use of a THREE-bit transport selector (4.4.1) and total 
lack of discussion of congestion control), but did not face significant 
opposition in the IESG.

It's EMSD (RFC 2524) that was considered by the IESG to be bad enough that 
it was labelled with an IESG warning containing sentences like "makes EMSD 
completely unsuitable for end-to-end use across the public Internet", and 
seemingly earned the IESG the permanent enmity of Mohsen Banan.

                        Harald

--
Harald Tveit Alvestrand, EDB Maxware, Norway
[email-masked]

---

From: Mohsen BANAN-Public <[email-masked]>
Date: 27 Jun 2000 14:56:28 -0000

>>>>> On Mon, 26 Jun 2000 08:23:41 +0200, Harald Tveit Alvestrand <[email-masked]> said:

  >> After 7 months of delay, caused by the IESG, ESRO was published

  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-masked] 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
someone experiences delay, double-dealing, misrepresentation and
mistreatment by an organization, it is hardly surprising that they
complain loudly. Based on logic similar to yours, one can then claim
that I seemingly earned the permanent enmity of the IESG and the IESG
Note in RFC-2524 is the IESG's way of dealing with my complaint.

At this point I have no compelling reason to interact with the IESG at
all. My protocol specifications have been published, and I intend to
continue moving forward with their implementations regardless of what
the IESG does or claims. I'll keep you posted as more and more
implementations of LEAP become widespread.

...Mohsen.

---

From: Mohsen BANAN-Public <[email-masked]>
Date: 27 Jun 2000 15:26:52 -0000

>>>>> On Mon, 26 Jun 2000 08:04:34 +0200, Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]> said:

  >> After 7 months of delay, caused by the IESG, ESRO was published

  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-masked]> -- said:

-------
From: Fred Baker <[email-masked]>
To: Mohsen BANAN <[email-masked]>
Cc: IETF Mailing List <[email-masked]>, [email-masked], [email-masked],
        RFC Editor <[email-masked]>, Internet Architecture Board <[email-masked]>,
        [email-masked]
Subject: Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
Date: Tue, 10 Nov 1998 06:50:00 +0000
Message-Id: <[email-masked]>

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-masked]

  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 and Balances". The model proposed in the Free Protocols
Foundation Policies and Procedures provides more detail on our
thinking.

Some starting points for improvement include:

  - Complete and total independence for the RFC-Editor function.
    My experience has been that this is simply not the case.

  - Containment of IESG obstructionism in the RFC publication process.

  - Promotion of competition amongst RFC-published protocols.

At this time, it is not my goal to actively champion such reforms.
Therefore my near term active participation in this mailing list is
likely to be limited.

However, I do want to present the LEAP Development Model as a case
study that others may wish to consider and emulate. To that end, it is
likely that when we are ready, I will play a more active role in this
cause.

In the meantime I'll remain hopeful that positive change can come from
within IETF/IESG/IAB and will be watching the IESG/IAB evolution
towards real responsibility with interest.

...Mohsen.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 28 Jun 2000 12:13:53 +0200

>with ESRO. That was part of our design. There is no shortage of UDP ports.

my comment was that the spec didn't say this, it said that ESRO used port 259.
your reply acknowledging this is in 
http://www.esro.org/communicationRecord/rfc2188Publication/msg00020.html 
(nice of you to provide the archive, btw).

The published RFC did not clarify this point.

My note was dated Aug 17, 1997; the RFC was published on Sept 9, so you 
probably decided that pushing it out the door was more important than 
addressing my concern in the RFC.

btw, the dustup over ESRO did lead to a number of tightenings of the 
procedures for informational publication. I hope we do better now; while I 
personally don't think the protocol is very useful, the procedural foulup 
was inexcusable.

                 Harald