JPALME@qz.qz.se (Jacob Palme QZ) (12/10/90)
I am a little confused on the usage of ports in abstract protocol specifications. Why is the communication between two agents split into different ports? What is the advantage? Is this purely an abstract notation, or does it mean that if a UA wants to connect to more than one port on a Service Agent, then multiple connections have to be opened. If the latter, why is this an advantage? One advantage with ports might be do make access control easier, if only some UA-s can access some ports which provide some kind of privileged access. But if this is the reason for organizaing the protocol into ports, then why has X.500 different ports for search and retrieval? Can the same operation occur via more than one port?
ala@lucid.COM ("Alyson L. Abramowitz") (12/11/90)
Date: Mon, 10 Dec 1990 16:20:52 +0100 From: Jacob Palme QZ <JPALME@qz.qz.se> Subject: Ports in Abstract Protocol specs To: ISO/CCITT Group Communication <ISO-GC@qz.qz.se>, mhsnews@uninett.no, eu-mhsnews@uninett.no Mmdf-Warning: Parse error in original version of preceding line at ICS.UCI.EDU Autoforwarded: true I am a little confused on the usage of ports in abstract protocol specifications. Why is the communication between two agents split into different ports? What is the advantage? Is this purely an abstract notation, or does it mean that if a UA wants to connect to more than one port on a Service Agent, then multiple connections have to be opened. If the latter, why is this an advantage? A port is totally an abstract notation which can be a useful mechanism both for modeling and for conformance. In general, however, it has really not been used for much in X.400 and (particularly) X.500. At the end of the last Study Period there was a suggestion to get rid of the ports from X.500 (I can't remember if we wanted to make it all one port or just get rid of them entirely). It came down to not being worth the fight for a purely documentation issue. So that is why there is a statement in X.500 about ports not being related to conformance. One advantage with ports might be do make access control easier, if only some UA-s can access some ports which provide some kind of privileged access. But if this is the reason for organizaing the protocol into ports, then why has X.500 different ports for search and retrieval? Yes, that has been a suggestion. Group some operations together and put them as one level of access and others (say administrative operations) as another level of access. Another philosophy suggests that this is really an interface issue and all you need to do is provide a different user interface where priviledged copmmands/operations are not available and that ports aren't necessary to accomplish this. X.500's ports were done before conformance was considered. They were grouped by similar function rather than anything else as I remember. At this point the ports are purely historical and should not be taken as having any inner meaning. Can the same operation occur via more than one port? Sure. Hope this helps explain one of the more obscure parts of OSI. Best, Alyson
eskovgaa@uvcw.uvic.ca (Erik Skovgaard) (12/11/90)
The different ports in the Directory actually has a historical
background. They originally envisioned that DUAs would come
in different flavours, some capable of Read operations only, some
(more sophisticated) could do Search operations and others could
do Modify operations.
The ports were envisioned to be implemented as different Application
Contexts, but they subsequently decided that an X.500 product must
implement all three ports, thus, we only have one flavour of DAP.
I am not sure, why X.400 is divided the same way, but it helps
the understanding of the object-oriented description technique.
You may also note another difference between the service
descriptions of X.400 and X.500. In X.400, the service of the UA
to the User is describer (in very abstract terms), in X.500 the
DUA service to the end-user is not described.
....Erik.
------------------------------
Erik Skovgaard
PSC (Pacific) Inc.vcerf@NRI.Reston.VA.US (12/24/90)
Jacob, I can try to answer your question about the purpose of ports in abstract protocols on the basis of the design work done on TCP and UDP (the connection and connectionless service protocols of the TCP/IP protocol suite). Our initial model was that communication was between cooperating processes in distinct machines. We assumed that there would be more than one process in each machine so that a communication service operated in common at the operating system level would want to be able to distinguish among "associations" by their port identifiers. Actually, we said that a particular communication was identified by a pair of socket identifiers (a socket was a host address and a port number). It was possible for a process to have several TCP connections going at once with other processes, each connection uniquely identified by the PAIR of sockets on either end. A single socket identifier could be used on one side to associate with distinct sockets on many different machines (so one process could be talking to many others). By extension, a single process on machine A could be communicating with many processes on the same machine. Everything was symmetric so it was even possible (and is common) for a process to talk to other processes on the same machine (ie all processes are housed on the same computer). By keeping the "associations" distinct, one can apply flow control on each separately, so that the behavior of one process on the system need not interfere with the behavior of another, in terms of TCP flow control, for example. Vint Cerf