W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2011

[whatwg] Websockets: dropped packets? (Jonathan Chetwynd)

From: Bob Gezelter <gezelter@rlgsc.com>
Date: Mon, 30 May 2011 07:41:55 -0700
Message-ID: <20110530074155.ef1fc80126c74c6c202a919c41c7bb0b.ce0e19c98a.wbe@email03.secureserver.net>
Harald,

Point taken. Having spent a lot of time with the different versions of
the Postel Mail specifications, I got my citation incorrect.

The appendices to RFC 821, however, well prove my point. As noted
directly in Section 1, Introduction:

 "SMTP is independent of the particular transmission subsystem and
   requires only a reliable ordered data stream channel.  Appendices A,
   B, C, and D describe the use of SMTP with various transport services.
   A Glossary provides the definitions of terms as used in this
   document." [RFC 821, Section 1] (Note: I did not check the
intervening versions between 772 and 821 to see precisely when it
appeared)

Appendices A, B, C, and D provide examples of SMTP bindings for various
underlying transports (TCP, NCP, NITS, and X.25 respectively).
There are no implications that this list is exhaustive.

Similarly, in my comments on the WebSocket protocol, there are no
reasons why a similar approach would be inappropriate, or place a
burden on anyone. I do not have access to my notes at this instant, but
as I recall, the only TCP-related dependencies related to the
scheme specifier at the beginning of the URL (e.g., ws:, wss:). IMO,
these, together with other TCP/HTTP dependencies, belong in an appendix,
or since, there is a high likelihood of entropy, in a separate RFC
appropriately titled (e.g., WebSocket Protocol over HTTP/TCP).

This would clarify the heart of the WebSocket protocol from the details
of the transport binding. It would also clarify starkly those details
that are specific to the TCP/HTTP binding, and which may be unnecessary
or inappropriate in the context of a different transport.

- Bob Gezelter, http://www.rlgsc.com

> -------- Original Message --------
> Subject: Re: [whatwg] Websockets: dropped packets? (Jonathan Chetwynd)
> From: Harald Alvestrand <harald at alvestrand.no>
> Date: Sun, May 29, 2011 8:06 pm
> To: gezelter at rlgsc.com
> Cc: whatwg at lists.whatwg.org
> 
> 
> On 03/31/11 14:53, Bob Gezelter wrote:
> > Jonathan,
> >
> > The WebSocket protocol currently presumes TCP as the underlying 
> > transport.
> >
> > TCP connections are an uninterrupted stream. If a packet is lost, the
> > connection will be aborted.
> >
> > I do not believe that the TCP dependency is truly necessary or 
> > beneficial.
> > WADR, it would be far more appropriate to specify the needed 
> > characteristics
> > of the underlying transport. As an example, the earliest versions of MTP
> > (RFC 772) -- the predecessor of SMTP have successfully taken this 
> > approach
> > to specification.
> Just to chime in on an old thread here, since it was referenced in Ian's 
> recent response:
> 
> After reading RFC 772, I believe you are presenting it falsely. It 
> specifies a dependency on "either TCP or NCP", where NCP is the Arpanet 
> protocol preceding IP (RFC 772 is from September 1980; NCP was turned 
> off in the Arpanet on Jan 1, 1983).
> 
> RFC 821, SMTP, which was the first (and so far only) successful mail 
> protocol on the Internet, did a little more separation, because it 
> specified an explicit mapping on TCP/IP (RFC 821 appendix A), as well as 
> mapping to other protocols. Later versions (RFC 2821, RFC 5321) simply 
> said "see RFC 821 for alternative mappings", and only specified the 
> TCP/IP mapping.
> 
> AFAIK, all other specifications that reference SMTP refer to the TCP 
> mapping only, in many cases (ref RFC 1123) making requirements that only 
> make sense for TCP, and it's the only one that's seen real deployment.
> 
> I believe the premise is false, so it should not be a surprise that I 
> believe the conclusion is erroneous.
> >
> > In a recent posting to my blog, Ruminations, I suggested that the 
> > WebSocket
> > protocol specification be segregated into multiple RFCs, to separate the
> > TCP-related implementation issues from the underlying protocol.
> >
> > - Bob
> > +--------------------------------------------------------------------------+ 
> >
> > | Robert "Bob" Gezelter                       E-Mail:  
> > gezelter at rlgsc.com  |
> > | Robert Gezelter Software 
> > Consultant                                      |
> > | 35-20 167th Street, Suite 215               Fax:       (on 
> > Request)      |
> > | Flushing, New York  
> > 11358-1731                                           |
> > | United States of America                    
> > http://www.rlgsc.com         |
> > +--------------------------------------------------------------------------+ 
> >
> >
Received on Monday, 30 May 2011 07:41:55 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:33 UTC