ArchiveOrangemail archive

Server-Initiated HTTP


hybi.ietf.org
(List home) (Recent threads) (190 other Internet Engineering Task Force (IETF) lists)

Subscription Options

  • RSS or Atom: Read-only subscription using a browser or aggregator. This is the recommended way if you don't need to send messages to the list. You can learn more about feed syndication and clients here.
  • Conventional: All messages are delivered to your mail address, and you can reply. To subscribe, send an email to the list's subscribe address with "subscribe" in the subject line, or visit the list's homepage here.
  • Low traffic list: less than 3 messages per day
  • This list contains about 9,911 messages, beginning Oct 2009
  • 0 messages added yesterday
Report the Spam
This button sends a spam report to the moderator. Please use it sparingly. For other removal requests, read this.
Are you sure? yes no

WSTP? was: websocket WebSocket websockets Web Sockets ??????????

Ad
Greg Wilkins 1267256550Sat, 27 Feb 2010 07:42:30 +0000 (UTC)
All,

I think we need to agree on a standard form of the name for this
protocol.

W3C api document uses "Web Sockets API".

The hixie draft uses "Web Socket protocol" in text, but
headers like "WebSocket-Protocol"  (not "Web-Socket-Protocol").

We should decide if it 1 word or two, singular or plural,
camel case or not etc.


Actually, for that matter, do we have to use the name web sockets
at all?   It strikes me that it is a little bit of a legacy name
and does not really reflect anything meaningful in the protocol
space.   A socket is after all an API concept and not a protocol
concept.

It also is out of line with all the other protocols names that
we have: HTTP, FTP, SMTP, BEEP, SPDY, BWTP, XMPP


I'm wondering if we should not pick a new name that both
encompasses both the history and more common naming practises

Why not WSTP?   which can stand for Web Socket Transport Protocol,
ie the protocol serves as a transport for the Web Socket API.

Sure this does not fix that "Socket" is not really meaningful
for a protocol.  But the WS will be used mostly and is no more
or less accurate than the HT in HTTP is.

cheers
KOMATSU Kensaku 1267265186Sat, 27 Feb 2010 10:06:26 +0000 (UTC)
Hi Greg

I think "WSTP" is a good idea. This name involving part of HTTP, so
it also suggests that "this protocol has a relationship with HTTP" for
new comers. :-)
( That'll be very confortable when we present in some technical-seminar or so. )

BTW, protocol name is often used as schema name.
    HTTP => http://foo/bar, FTP => ftp://foo/bar2
So, in this scenario, I think specificaton has to change schema name, like other
protocols.
( ws => wstp, wss => wstps? )



Best regards
Kensaku
---
Kensaku KOMATSU
http://code.google.com/p/websocket-sample/
2010/2/27 Greg Wilkins : > > > All, > > I think we need to agree on a standard form of the name for this > protocol. > > W3C api document uses "Web Sockets API". > > The hixie draft uses "Web Socket protocol" in text, but > headers like "WebSocket-Protocol" (not "Web-Socket-Protocol"). > > We should decide if it 1 word or two, singular or plural, > camel case or not etc. > > > Actually, for that matter, do we have to use the name web sockets > at all? It strikes me that it is a little bit of a legacy name > and does not really reflect anything meaningful in the protocol > space. A socket is after all an API concept and not a protocol > concept. > > It also is out of line with all the other protocols names that > we have: HTTP, FTP, SMTP, BEEP, SPDY, BWTP, XMPP > > > I'm wondering if we should not pick a new name that both > encompasses both the history and more common naming practises > > Why not WSTP? which can stand for Web Socket Transport Protocol, > ie the protocol serves as a transport for the Web Socket API. > > Sure this does not fix that "Socket" is not really meaningful > for a protocol. But the WS will be used mostly and is no more > or less accurate than the HT in HTTP is. > > cheers > > > > > > > > _______________________________________________ > hybi mailing list > > https://www.ietf.org/mailman/listinfo/hybi >
Thomson, Martin 1267397246Sun, 28 Feb 2010 22:47:26 +0000 (UTC)
An argument for consistency could just as well be used to maintain the existing name.  Do you actually know what BEEP stands for?

I don't see the name as a particular problem - I've come to live with worse.  On the contrary, the name has a certain value.

--Martin
> -----Original Message----- > From: [mailto:] On Behalf Of > Greg Wilkins > Sent: Saturday, 27 February 2010 6:45 PM > To: > Subject: [hybi] WSTP? was: websocket WebSocket websockets Web Sockets > ?????????? > > > > All, > > I think we need to agree on a standard form of the name for this > protocol. > > W3C api document uses "Web Sockets API". > > The hixie draft uses "Web Socket protocol" in text, but > headers like "WebSocket-Protocol" (not "Web-Socket-Protocol"). > > We should decide if it 1 word or two, singular or plural, > camel case or not etc. > > > Actually, for that matter, do we have to use the name web sockets > at all? It strikes me that it is a little bit of a legacy name > and does not really reflect anything meaningful in the protocol > space. A socket is after all an API concept and not a protocol > concept. > > It also is out of line with all the other protocols names that > we have: HTTP, FTP, SMTP, BEEP, SPDY, BWTP, XMPP > > > I'm wondering if we should not pick a new name that both > encompasses both the history and more common naming practises > > Why not WSTP? which can stand for Web Socket Transport Protocol, > ie the protocol serves as a transport for the Web Socket API. > > Sure this does not fix that "Socket" is not really meaningful > for a protocol. But the WS will be used mostly and is no more > or less accurate than the HT in HTTP is. > > cheers > > > > > > > > _______________________________________________ > hybi mailing list > > https://www.ietf.org/mailman/listinfo/hybi
Greg Wilkins 1267430365Mon, 01 Mar 2010 07:59:25 +0000 (UTC)
Thomson, Martin wrote: > An argument for consistency could just as well be used to maintain the existing name. Do you actually know what BEEP stands for? > > I don't see the name as a particular problem - I've come to live with worse. On the contrary, the name has a certain value.
I'm not opposed to keeping the name.... but which one? Web Sockets WebSockets Web Socket WebSocket Websocket I just though that WSTP would be a simpler way to avoid those multiple names when precision is needed, but still allow us to use any of the above in text. cheers
Ian Hickson 1267433575Mon, 01 Mar 2010 08:52:55 +0000 (UTC)
On Mon, 1 Mar 2010, Greg Wilkins wrote: > Thomson, Martin wrote: > > An argument for consistency could just as well be used to maintain the existing name. Do you actually know what BEEP stands for? > > > > I don't see the name as a particular problem - I've come to live with worse. On the contrary, the name has a certain value. > > I'm not opposed to keeping the name.... but which one? > > Web Sockets > WebSockets > Web Socket > WebSocket > Websocket
The spec is intended to define how to open "a Web Socket", so that you can "use Web Sockets to implement" something. The protocol is thus the "Web Socket protocol". The DOM object that uses this is called "WebSocket", and for consistency I've used that camel case spelling for all other Web-Socket-related identifiers (such as the Upgrade keyword, or header names). If there's an inconsistency in the spec, please let me know so I can fix it. If there's an inconsistency in e-mails or blog posts or whatnot... I don't think that really matters. :-)
Greg Wilkins 1267435986Mon, 01 Mar 2010 09:33:06 +0000 (UTC)
Ian Hickson wrote: > If there's an inconsistency in the spec, please let me know so I can fix > it.
Ian, the spec is indeed inconsistent and uses "Web Socket", "WebSocket" and even "Websocket". This is not just in the document, but on the wire as the The Upgrade request uses "WebSocket", while the 101 response uses "Web Socket". If the normal name is "WebSocket" then the use of "Web Socket" should be removed from the document and 101 response. If the normal name is "Web Socket", then the upgrade should be to "Web-Socket" and the headers "WebSocket-Protocol, WebSocket-Origin and WebSocket-Location should all start with "Web-Socket-". There is also inconsistency with http://dev.w3.org/html5/websockets/ which uses the plural. This kind of stuff is really important for avoiding bugs and interoperability. I've for years dealt with the fallout from a similar oversight where JSESSIONID is the cookie, but jsessionid is the URL parameter. So do think there is a need to fix this consistency, and unfortunately that will effect what goes on the wire (at least for the response reason). So if we are changing, then as with all naming changes, they are easier the sooner you make them. So if there is a desire for a more significant name change - now is the time. So, I raise the appropriateness of "Socket" in the name - specially now that the API and protocol have been split. The use of "Socket" makes perfect sense for the API, as a socket is the end point. But it makes no sense for a protocol. If we were to switch to WSTP, we would: + be able to fix the inconsistencies in the current draft + save 6 bytes in headers and response lines (yipee!!!!) + look more like a "normal" protocol name + maintain an association with WebSocket API via the WS part + Have a clear on the wire distinction between implementations working on the current WHATWG WebSocket draft and those implementing the future IETF WSTP/1.0 standard. Of course good implementations can be forgiving in what they receive and can accept either WSTP/1.0 or Web Socket or WebSocket at least for a while. (Note that this was going to have to happen once multiple versions occur anyway). cheers
Ian Hickson wrote: > On Mon, 1 Mar 2010, Greg Wilkins wrote: >> Thomson, Martin wrote: >>> An argument for consistency could just as well be used to maintain the existing name. Do you actually know what BEEP stands for? >>> >>> I don't see the name as a particular problem - I've come to live with worse. On the contrary, the name has a certain value. >> I'm not opposed to keeping the name.... but which one? >> >> Web Sockets >> WebSockets >> Web Socket >> WebSocket >> Websocket > > The spec is intended to define how to open "a Web Socket", so that you can > "use Web Sockets to implement" something. The protocol is thus the "Web > Socket protocol". The DOM object that uses this is called "WebSocket", and > for consistency I've used that camel case spelling for all other > Web-Socket-related identifiers (such as the Upgrade keyword, or header > names). > > If there's an inconsistency in the spec, please let me know so I can fix > it. If there's an inconsistency in e-mails or blog posts or whatnot... I > don't think that really matters. :-) >
Maciej Stachowiak 1267436739Mon, 01 Mar 2010 09:45:39 +0000 (UTC)
My suggestion: let's have the normal name be "WebSocket" in all  
contexts, in APIs, in protocols and in English. The experience of  
"HTML5" vs "HTML 5" makes me think that names differing only by a  
space will needlessly confuse people.

  - Maciej
On Mar 1, 2010, at 1:35 AM, Greg Wilkins wrote: > > > Ian Hickson wrote: >> If there's an inconsistency in the spec, please let me know so I >> can fix >> it. > > > Ian, > > the spec is indeed inconsistent and uses "Web Socket", "WebSocket" > and even "Websocket". > > This is not just in the document, but on the wire as the > The Upgrade request uses "WebSocket", while the 101 response > uses "Web Socket". > > If the normal name is "WebSocket" then the use of "Web Socket" should > be removed from the document and 101 response. > > If the normal name is "Web Socket", then the upgrade should > be to "Web-Socket" and the headers "WebSocket-Protocol, > WebSocket-Origin and WebSocket-Location should all start > with "Web-Socket-". > > There is also inconsistency with http://dev.w3.org/html5/websockets/ > which uses the plural. > > > This kind of stuff is really important for avoiding bugs > and interoperability. I've for years dealt with the fallout > from a similar oversight where JSESSIONID is the cookie, but > jsessionid is the URL parameter. > > > So do think there is a need to fix this consistency, and unfortunately > that will effect what goes on the wire (at least for the response > reason). > > So if we are changing, then as with all naming changes, > they are easier the sooner you make them. So if there > is a desire for a more significant name change - now is the time. > > So, I raise the appropriateness of "Socket" in the name - specially > now > that the API and protocol have been split. The use of "Socket" makes > perfect sense for the API, as a socket is the end point. But it makes > no sense for a protocol. > > If we were to switch to WSTP, we would: > > + be able to fix the inconsistencies in the current draft > + save 6 bytes in headers and response lines (yipee!!!!) > + look more like a "normal" protocol name > + maintain an association with WebSocket API via the WS part > + Have a clear on the wire distinction between implementations > working on the current WHATWG WebSocket draft and those > implementing the future IETF WSTP/1.0 standard. > > > Of course good implementations can be forgiving in what > they receive and can accept either WSTP/1.0 or Web Socket or WebSocket > at least for a while. (Note that this was going to > have to happen once multiple versions occur anyway). > > > cheers > > > > > > Ian Hickson wrote: >> On Mon, 1 Mar 2010, Greg Wilkins wrote: >>> Thomson, Martin wrote: >>>> An argument for consistency could just as well be used to >>>> maintain the existing name. Do you actually know what BEEP >>>> stands for? >>>> >>>> I don't see the name as a particular problem - I've come to live >>>> with worse. On the contrary, the name has a certain value. >>> I'm not opposed to keeping the name.... but which one? >>> >>> Web Sockets >>> WebSockets >>> Web Socket >>> WebSocket >>> Websocket >> >> The spec is intended to define how to open "a Web Socket", so that >> you can >> "use Web Sockets to implement" something. The protocol is thus the >> "Web >> Socket protocol". The DOM object that uses this is called >> "WebSocket", and >> for consistency I've used that camel case spelling for all other >> Web-Socket-related identifiers (such as the Upgrade keyword, or >> header >> names). >> >> If there's an inconsistency in the spec, please let me know so I >> can fix >> it. If there's an inconsistency in e-mails or blog posts or >> whatnot... I >> don't think that really matters. :-) >> > > _______________________________________________ > hybi mailing list > > https://www.ietf.org/mailman/listinfo/hybi
Ian Hickson 1267436972Mon, 01 Mar 2010 09:49:32 +0000 (UTC)
On Mon, 1 Mar 2010, Greg Wilkins wrote: > > the spec is indeed inconsistent and uses "Web Socket", "WebSocket" and > even "Websocket". > > This is not just in the document, but on the wire as the The Upgrade > request uses "WebSocket", while the 101 response uses "Web Socket".
This is actually consistent with what I described in my previous e-mail.
On Mon, 1 Mar 2010, Maciej Stachowiak wrote: > > My suggestion: let's have the normal name be "WebSocket" in all > contexts, in APIs, in protocols and in English. The experience of > "HTML5" vs "HTML 5" makes me think that names differing only by a space > will needlessly confuse people.
Ok.
Greg Wilkins 1267437973Mon, 01 Mar 2010 10:06:13 +0000 (UTC)
Ian Hickson wrote: > On Mon, 1 Mar 2010, Greg Wilkins wrote: >> the spec is indeed inconsistent and uses "Web Socket", "WebSocket" and >> even "Websocket". >> >> This is not just in the document, but on the wire as the The Upgrade >> request uses "WebSocket", while the 101 response uses "Web Socket". > > This is actually consistent with what I described in my previous e-mail.
Ian Must you always adopt the "it's already perfect" stance and then fight everything every step of the way? Even your email wasn't consistent: "I've used that camel case spelling for all other Web-Socket-related identifiers" But I'll take your "OK" to Maciej as meaning that the draft will be changed to use "WebSocket" in all contexts. Great! cheers
Anne van Kesteren 1267438208Mon, 01 Mar 2010 10:10:08 +0000 (UTC)
On Mon, 01 Mar 2010 11:08:56 +0100, Greg Wilkins wrote: > Even your email wasn't consistent: > > "I've used that camel case spelling for all other Web-Socket-related > identifiers"
Isn't that just English grammar rules? http://en.wikipedia.org/wiki/English_compound...
Gurkan Erdogdu 1267430995Mon, 01 Mar 2010 08:09:55 +0000 (UTC)
Hello;

I am a keen observer of this group.  I have started to work on similar
topics while implementing Bayeux Protocol over JMS Topics. (enough ad :)
back to topic!)

For name+1 for the WSTP. Web Socket Transport Protocol, it is a cool name!

--Gurkan Erdogdu
Apache OpenWebBeans PMC Chair
gurkanerdogdu.blogspot.com
2010/2/27 Greg Wilkins > > > All, > > I think we need to agree on a standard form of the name for this > protocol. > > W3C api document uses "Web Sockets API". > > The hixie draft uses "Web Socket protocol" in text, but > headers like "WebSocket-Protocol" (not "Web-Socket-Protocol"). > > We should decide if it 1 word or two, singular or plural, > camel case or not etc. > > > Actually, for that matter, do we have to use the name web sockets > at all? It strikes me that it is a little bit of a legacy name > and does not really reflect anything meaningful in the protocol > space. A socket is after all an API concept and not a protocol > concept. > > It also is out of line with all the other protocols names that > we have: HTTP, FTP, SMTP, BEEP, SPDY, BWTP, XMPP > > > I'm wondering if we should not pick a new name that both > encompasses both the history and more common naming practises > > Why not WSTP? which can stand for Web Socket Transport Protocol, > ie the protocol serves as a transport for the Web Socket API. > > Sure this does not fix that "Socket" is not really meaningful > for a protocol. But the WS will be used mostly and is no more > or less accurate than the HT in HTTP is. > > cheers > > > > > > > > _______________________________________________ > hybi mailing list > > https://www.ietf.org/mailman/listinfo/hybi >
Ad
Home | About | Privacy