Talk:OSI model

Protocol Wars

I am not happy with the insertion of a mention of and link to Protocol Wars. Per my comments on the newly created page, I think the page is misnamed, and I am not yet convinced it is a notable subject in its own right. Why not have it as a sub section here, and isn't the lack of a subsection here an indication that editors have not seen it as notable?

I am happy to allow that page to develop without taking it to AfD or any other such issues, but until it is clear it is notable and stable (note that I think the page is misnamed for instance) I don't think we should link to it. I am happy to be over-ruled by other editors, and if none come forward, I would be content for you to request a WP:3O but at this point the challenged material should remain out of the article per WP:BRD. Thanks. -- Sirfurboy (talk) 15:27, 6 February 2020 (UTC)

Discussion continues at Talk:Protocol Wars#Notability ~Kvng (talk) 13:46, 7 February 2020 (UTC)

Open systems architecture merge

I've reverted the merge from Open systems architecture into a top importance article as controversial and needs discussion in my opinion.Djm-leighpark (talk) 03:22, 23 April 2020 (UTC)

Contentious merge

Djm-leighpark in what way is the merge I did a contentious merge? Please explain. Thank you. ---Steve Quinn (talk) 04:04, 23 April 2020 (UTC)

Steve Quinn - someone, namely me, and possibly others, regards it as contentious requires consensus to be obtained before such a merge. It is also the case that prior to a PROD you should have identified any possible merges; and to find a possible merge after a PROD was decline while commendable implies WP:PRODNOM may not have been properly followed. Per WP:MERGEPROP .. If the need for a merge is obvious, editors can be bold and simply do it. See How to merge below. This includes stubs whose titles differ only in spelling, for example. Note however that bold edits might be reverted, despite the work in implementing them. Articles that have been separate for a long time should usually be discussed first ...both articles pre-date 2006. Thankyou.Djm-leighpark (talk) 06:21, 23 April 2020 (UTC)

First of all, it is not my job to figure out to where I can possibly merge a page. There are a multitude of topics on Wikipedia and I'm not going to merge a page to place where it doesn't belong. The page has so little information that when I first looked at it I had no idea to where a merge was possible. So please don't tell me what I should and shouldn't do. Prodding is a normal editing action for a page that shows no sign of notability. It's a way to avoid WP:AFD.

This brings me to the second issue. The page has been tagged for lack of sourcing and for not meeting the GNG criteria since 2009. The fact is this page shows no signs of meeting notability criteria per GNG. Additionally, Wikipedia is not a manual (WP:NOTMANUAL) and it is not a directory (WP:NOTDIR). So, if a merge is reverted then all that's left is WP:AFD. Please take that into consideration. A merge saves all the information on that page. That's why a merge makes sense when the qualifications for a stand alone article are not met. Regards ---Steve Quinn (talk) 07:04, 23 April 2020 (UTC)

@Steve Quinn Following your request for a response on my talk page it is this: My view is anyone who wishes to propose a merge of Open systems architecture into this article is welcome to go through steps one and two at WP:MERGEPROP but should bear in mind this OSI model article is top importance level 5 and should not be disruptived with WP:UNDUE. If such a merger is raised I may or may not consider to participate as is my wont but will support any reasonable consensus. Thankyou.Djm-leighpark (talk) 10:27, 25 April 2020 (UTC)

If an article is not well developed, this alone does not make it a candidate to be merged into another seemingly related topic. Although I haven't researched the use of the term open systems architecture for its historical context and scope much, it seems or should be notable and in fact appears to be a topic of which the OSI model is an example or subset. Merging does not seem to be the appropriate solution here. Expand and source the article instead. Kbrose (talk) 12:46, 25 April 2020 (UTC)

I'd like to get a better understanding of what open systems architecture is an how it relates to OSI model before we proceed with any reorganization discussion. Open systems architecture is not well developed enough at this point to help me much. If no one is going to step up and improve Open systems architecture, perhaps it should be considered for deletion through WP:AFD. This was never a good WP:PROD candidate. ~Kvng (talk) 13:38, 28 April 2020 (UTC)

@Kvng: Pragmatically I suspect Open systems architecture (OSA), while not perfect, has been improved by my feeble efforts and Kbrose's better efforts and any merge into this article would be ill-advised. This is not really the place to discuss the OSA on the talk page of something else; but I very much a properly conducted WP:BEFORE ought to lead to decision not to bring to AfD; and should it end up there I would be surprised at a delete result. OSA was a arguably a AFD candidate at the point of dePROD; but following improvement and making more generic since is demonstrably more solid. Yes, OSA could be improved, but Wikipedia is a work in progress.Djm-leighpark (talk) 14:01, 28 April 2020 (UTC)

The article that is more closely associated with the OSA topic is Open system (computing) that I linked within OSI. But some historical research should determine whether or not OSA is still a more general concept, not only applicable to computing systems per se. Until that is completed, any merging seems premature. In any case, the discussion should not be continued here, but on the OSA talk page. Kbrose (talk) 14:35, 28 April 2020 (UTC)

SPDY protocol as example for Session Layer

In the text box "OSI model by layer", the SPDY protocol is mentioned as an example for a session layer protocol. However, SPDY does also compress HTTP requests. Compression belongs to the presentation layer (layer 6) in the OSI model. This is however not explained in the text below. It should be made clear that it is not always possible to clearly relate an existing protocol to a single dedicated OSI layer. — Preceding unsigned comment added by Tobias.hossfeld (talk • contribs) 19:49, 28 November 2020 (UTC)

HTTP is an SESSION layer protocol in OSI Model

The RFC, especially one line in the introduction, does control what layer the protocol is in - the function of the protocol does. HTTP does control and manage the connections between computers. it redirects, closes, opens with CONNECT- it is the first layer that transfers data. It is a session layer protocol in the OSI Model. ** it is Application in the "Internet protocol suite" model **

Above that is HTML, XML, REST, etc. in the presentation layer.

There is even a link IN THIS PAGE that describes this: https://en.wikipedia.org/wiki/OSI_model#Comparison_with_TCP/IP_model Abbotn (talk) 12:21, 5 August 2021 (UTC)

Creating and maintaining connections to computers is absolutely *not* what GET does. A connection is already established, or you couldn't sent GET in the first place. Strangerpete (talk) 17:00, 5 August 2021 (UTC)

To clarify my comment, a server may well support some form of redirect or relay, but that still is not GET 'maintaining a connection', GET requests a resource. As for session, Stack does a decent job explaining and summing it up - https://stackoverflow.com/questions/38596488/in-which-layer-is-http-in-the-osi-model Strangerpete (talk) 17:07, 5 August 2021 (UTC)

In response to you correcting "GET" to "CONNECT", the connection still has already been established. You can't send a 'connect' until a connection to the server is already made. This is basic HTTP here... Strangerpete (talk) 17:13, 5 August 2021 (UTC)

GET, HEAD, POST and CONNECT will all create or reuse connections. Abbotn (talk) 17:21, 5 August 2021 (UTC)

We clearly have fundamental differences in understanding how the protocol works, and what is suggested by OSI as a session, so I'll just leave it alone after this point, and let others discuss this. GET does not create connections, this is a gross simplification; the server on the other end might support tunneling or relaying, but thats irrelevant - HTTP is used over an already established connection. Every link you've sent in talk and summaries, all say the same thing, it is widely regarded as stateless and application-layer.

Even in your snarky reply, "Here's a website that got it right - naturally it's for developers - the only people who should be having these discussions. https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview " your source material not only states that its application-layer, but proceeds to explain "A connection is controlled at the transport layer, and therefore fundamentally out of scope for HTTP."[1].

The real final word is the RFC though, which does indicate OSI layer: "HTTP is a stateless request/response protocol that operates by exchanging messages (Section 3) across a reliable transport- or session-layer "connection" (Section 6). "[2], key word being "across". And Section 6 says "HTTP messaging is independent of the underlying transport- or session-layer connection protocol(s)"[3] Strangerpete (talk) 23:42, 5 August 2021 (UTC)

Unless I've missed something, what an RFC says is irrelevant for the definition of the OSI model. Regarding what HTTP does, consider a client program that sends a GET request. The program would ask the operating system to establish a connection with the remote server using the TCP protocol to connect to a particular port number at a particular DNS host name or IP address. If that's successful, the operating system returns an identifier to the program which the program uses to send the GET and receive a response. The HTTP procedure of sending a command and receiving a response is handled by the application program (normally a web browser). The operating system handles the TCP/IP procedures of connecting, transferring, error retries, etc. What layer you want to call that is a personal choice but "application" fits reality. By the way, there is no need to use references on a talk page—just use a link. Johnuniq (talk) 03:29, 6 August 2021 (UTC)

Sorry, fixed my references to links. I also originally suggested to the OP that this be a discussed over at Talk:Hypertext_Transfer_Protocol since its not relevant directly to OSI, is a move possible? I agree an RFC is absolutely irrelevant to defining the OSI model, but an RFC is definitely relevant in terms of what HTTP was designed and intended for within the scope OSI model. While transport/session/application might be blurry today it clearly was not back then, they are very specific in language what HTTP isn't responsible for, and reuse that language over 15 years of updates. My concern about appropriate labeling comes since the OP's definition of session-layer would include PPP, Bluetooth, Javascript, AOL instant messenger, and any other application or protocol that maintains a session of any sort at any level of implementation. Strangerpete (talk) 10:00, 6 August 2021 (UTC)

If you mean could we move this discussion to another page, yes we could, but no, there is no need. That's because this will peter out soon. You know the score already but I have to link to a fantastic FAQ by the really talented Robert Graham. It's about network sniffing but has an enlightening section on OSI: [4]. I have never seen a more insightful description of the OSI model. Scroll down to the table showing the seven layers and read what it says about the Session layer—excellent stuff. It includes HTTP as an example of the Application layer. Johnuniq (talk) 10:28, 6 August 2021 (UTC)

Circular reference?

This text "It was published in 1984 by both the ISO, as standard ISO 7498..." has a link on the "ISO 7498" term that redirects back to this page.

A bit navel-gazingly redundant, eh? — Preceding unsigned comment added by 203.173.153.83 (talk) 20:12, 9 November 2021 (UTC)

Not any more, it doesn't. It also doesn't have a link to X.200, as that also just redirects here. Guy Harris (talk) 21:16, 9 November 2021 (UTC)

ISO Definition

first (maybe second) sentence mentions ISO, but without describing the acronym. It would be helpful to have it described 50.92.161.150 (talk) 20:20, 26 September 2022 (UTC)

Layer 5 (Session) Claims DNS incorrectly

DNS is resolved in Layer 7 (Application) but Layer 5 (Session) sections second sentence claims this is where it is done. It is not mentioned in the Layer 7 (Application) description. However in the main article for Layer 7 (Application) DNS is referenced as being part of that layer, correctly. As well as in the main article for Layer 5 (Session) DNS is correctly not mentioned. 103.91.192.50 (talk) 03:14, 10 April 2024 (UTC)

Some WP:OR going on there, apparently – corrected, thanks! --Zac67 (talk) 05:55, 10 April 2024 (UTC)

SNA

I've updated the chart to correct some errors and to show the mapping of SNA layers to OSI layers. In the processed, I've stumbled on a few issues.

1. SDLC and Twinax are not layers, but should they be shown as examples of the DLC and physical layers?
2. NCP is not a layer but it does implement some SNA layers. Should there be a reference somewhere?
3. Should it show S/370 channels and Token ring as DLC examples -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:37, 25 September 2024 (UTC)

1. I'd say that SDLC is a DLC-layer protocol (especially given the name :-)) and that Twinax#IBM includes both physical and DLC layers.
2. The NCP and processors that run it are front-end processors, which are implementation details. Its page appears to say even less about layers above the DLC layer than does the SNA page.
3. Token ring's physical layer as a physical layer, and its and MAC layer + 802.2 LLC as the DLC layer, yes. If channel-to-channel connections are used as SDLC links, yes as well. Guy Harris (talk) 22:27, 25 September 2024 (UTC)

By the way, what is the "DLC" protocol referred to in a pile of Microsoft documentation and in the second paragraph of the Data Link Control page? From what I found when searching, it looks as if it might refer to putting higher-level SNA packets into LAN frames using IEEE 802.2 LLC rather than into SDLC frames on a serial line. The 802.2 page shows a Service Access Point value of 4 for "SNA Path Control"; at least as I read the SNA layer diagram on page 3 of Systems Network Architecture Technical Overview, Path Control is the layer above Data Link Control, and it sounds as if it roughly corresponds to the network layer ("PATH CONTROL routes data between source and destination and controls data traffic in the network."), so SDLC would be at the Data Link Control layer, with a serial line being the Physical Control layer. Other combinations would include Token Ring (or Ethernet/FDDI/other LANS supporting 802.2 LLC) physical layers being at the Physical Control layer and their MAC layer plus 802.2 LLC being at the Data Link Control layer.

(Systems Network Architecture should probably have more information from that document used to indicate what the layers are.) Guy Harris (talk) 08:42, 26 September 2024 (UTC)