Paul Bryant's Networking Correspondence
Dear Wolfgang,
I have pleasure in enclosing the latest draft of the Y/11 Y/12 functional standard.
Version 6.0 is the latest that has been distributed to the working group and 6.1 and now 6.2 are my private redrafts on the basis of comments received since the last working group meeting. I have issued 6.2 for your group to comment on as I think there will only be minor changes before it is issued for voting - but I may be wrong.
Since 6.2 has and will not be issued to Y/11 Y/12 working group I would prefer it not to be distributed except to those who may wish to comment in the near future as the definitive version 7.0 will be issued very shortly. Can I impress on you that Jan Van Herp is pressing for a final document by the 19th of this month and so an early response is essential if your comments are to be taken into account now rather than at the December voting meeting. I apologize for the ridiculously short time scale and for failing to send this to you last week (copying delays).
I look forward to your comments.
With best wishes
Paul Bryant.
Dear Dave,
I have pleasure in enclosing the latest version of the Y/11 Y/12 functional standard which defines how PADs should work.
This document will be voted on in December. Any comments must be with me before the end of this month for consideration for the final voting paper and before the start of December for final comments.
After December and if the vote is positive I shall be looking to encourage manufacturers to conform to the standard and I expect it to be used in procurement exercises. I would expect that JNT will be adopting it probably as part of the strategy for migration to ISO protocols.
So far most comments have been from the PTTs, the national standards bodies, and our own Character Terminal Implementers Group and little input from suppliers. I hope this means that suppliers are happy with the content and will conform to it in due course.
I look forward to any comments you (and your experts) may have. I am sorry that I have given you so little time to comment but you will have had earlier drafts which are not all that different.
With best wishes
Paul Bryant.
Dear Janet,
Some time ago one of your staff was kind enough to comment on the Y/11 Y/12 functional standard. This standard is now complete and will go for voting in December after a final edit. I am sending you the final draft and would value any comments for inclusion in the voting document if received this month or for consideration at the voting meeting if the deadline is not met. I am afraid I lave lost the name and address of your expert who spoke to me.
If the vote in December is positive I shall be encouraging manufacturers to conform to it and I would expect it to be used in procurement exercises. I also expect it to be adopted by JNT probably as part of their ISO migration plans.
I look forward to your comments. It seems to be a long time since we met last since I now have no longer any involvement with your computers - however I hope all is well in Dunstable.
With best wishes
Paul Bryant.
Dear John,
Some time ago you were good enough to comment on the Y/11 Y/12 document. The final document is now almost ready and I enclose a copy of almost final version. You will see that is has undergone considerable change in detail but little in terms of concepts.
If you would like to comment further I will try and incorporate changes in the version voted on or is received after the deadline (towards the end of the month) I will raise them at the final voting meeting.
I was most grateful for your earlier comments and I hope you will find that this version takes your views into account.
With best wishes
Paul Bryant.
This meeting was to concentrate on the work of the working groups. It was therefore a little disappointing that more group chairmen were not in attendance. In fact ITEAGS has settled down to a fairly static membership with attendance on this occasion being a healthy 10.
The administration as far as ITEAGS is concerned seems to be working well with the paperwork flowing copiously although there are still too many papers tabled at the meeting. There has been, or will be, some improvement in the staffing level with the temporary appointment of a Greek to the team. Since he only joined that day the effect has yet to be felt.
I feel that the meeting was very aware of the problems within the project - possible ISO work, COS, NBS, quality of ENVs, CEPT/CEN relations, and so on - although it is clear that these problems will take some time to solve.
SOGITS has adopted the M-IT-01/02 which means that ITEAGS can relax on that front apart from the 'massaging' of M-IT-02 as needed.
There was some concern at the speed with which the Americans could get together, produce documents and proceed to implementation whereas our activities seemed very slow. However there were no suggestions as to improvements in our procedures.
There is some improvement in that the information concerning meetings is getting to the right people and that documents are flowing better. One cannot help feeling that the radically different working methods of the two organizations is always going to cause operational difficulties.
It was suggested that it may be appropriate to define a new method of working called 'procedure C'. This would be a working group containing both CEN/CENELEC and CEPT members. These thoughts did not proceed to produce any definitive proposals but it could be a method of producing better ENVs quicker and with less concern over possible reaction from the other organization.
There was some concern as to how CEN/CENELEC should organize its comment on CEPT functional standards. Some common position is needed rather than a set of possibly contradictory comments from the CEN/CENELEC member bodies. This is considered to be a very serious problem in the light of the possible negative votes on some ENVs. There were thoughts that a pre CEN/CENELEC meeting should be held before a CEPT voting meeting to brief the observers.
The work of the groups was reviewed but in several cases it was disappointing that no reports were available in written form or from those present at the meeting.
There was concern at the content and style on ENVs. Some better guidance is needed. A earlier document on layout and content had been very useful but now needed extending in the light of experience. Of particular concern was the form of conformance statements - these should be capable of being used for conformance testing.
There was a feeling (Pouzin of CEPT) that the ENV for the private MHS would be the de facto functional standard and that the public one would align itself with it but that this may take a year. There are thought of some future work that the private group would like to do and the decision was that the group should put up a proposal rather than decide to unilaterally continue their work.
Token ring is progressing and a draft for voting should be available in December. I am a little confused as to the exact procedure for introducing a new work item and also giving it some priority.
The character working group (the chairman was present) is still ailing. It is clearly a difficult area and although there has been some useful progress it does not look like satisfactory ENVs will come quickly. There is some doubt as to whether satisfactory ENVs are possible.
Recognizing the fast developing nature of communications it is thought that ENVs should be supplemented by bulletins as required and not by revising the ENVs which should have lives of the order of 2 years. The bulletins would comment on changes to the base standards and how these affected the ENV. They would also include clarification if problems are identified in the ENV.
Some time was spent on the revision of these documents but there is nothing of interest to report.
CEN/CENELEC is unwilling to publish a list of members of the working groups as the membership changes very frequently. They will shortly publish the list of chairmen which should be useful. Thus it would appear that BSI should maintain a list of its members of the working groups if appropriate.
There will be an open meeting on 12-13 November. The last one considered M-IT-01 in some detail. The plan seemed to be to follow a similar pattern. I was fairly keen that the meeting should also appraise the progress of the project so far and thus have a rather broader objective. This seemed to be well taken although there was little time left to do any detailed planning.
The EARN President has received many comments on the recent application of South Africa to join EARN. These exhibit a wide range of views. In the light of these views the Executive felt unable to make a ruling and have referred the issue to the full EARN Board of Directors which will meet 29/30 October in Berlin. The UK view, as expressed in Memorandum P/EH/32 of 9 September 1986 from Jean Melville, has been registered.
1. Minutes of 7th RCCC meeting held 19 December 1986. 2. Matters arising. 3. Network and communications strategy (RCCC/P28/87, RCCC/P29/87). 4. LAN progress (RCCC/P30/87). 5. Any other business. 6. Date of next meeting.
Dear David,
SERC has consulted Paul Hare ESSD of the UK Foreign and Commonwealth Office concerning the recent application of South Africa to join EARN.
I am advised, that in the present sensitive climate and in view of the European Community guidelines, not to support this application. The Foreign and Commonwealth Office would expect, in view of the European Community directive, that if EARN Board of Directors have been briefed by their authorities, they would also be opposing the application but they recognize that this consultation may not always take place in an organization not constituted by formal agreement. The position of the UK Board of Directors member is therefore:
It should be noted that the UK wishes to have its opposition registered which is without prejudice to any further action should the Board of Directors elect to support the application.
The UK position on the application from South Africa should not be seen as a precedent for applications from any other applicant.
May I ask you to register the UK position on the South African application?
Yours sincerely
Paul Bryant.
Dear Arthur,
Thank you for your letter of 22 September 1986 (F/FF/137).
I have no objections to the additional wording now included in the agreement by IBM and I am now happy with the document.
May I now ask you to proceed with the signing of the agreement?
Thank you for your help in furthering this project which I am hoping will be of great benefit to my users.
Yours sincerely
Paul Bryant.
I have investigated the reported problems with the CERN switch. The fact are very different and the conclusion is that we wasted our valuable time on this matter which should have been dealt with by service line. However these are the facts.
The CERN switch does run SERC software but it is also reliable. Contrary to by statement it does IPL correctly after a power fail. There have been no complaints over its performance as far as my information is concerned. It appears that the terminals in question (my guess) are gaining access to Rutherford via CERN INDEX via the GEC workstation and via the switch. This workstation does fail from time to time and sometimes it fails to get the time from the network on IPLing itself and thus terminals gaining access by this method loose their service. Thus the story about putting in the time has some substance. The failure seems to be squarely on the GEC workstation which in any case is scheduled to be removed and replaced by a PAD/printer. It should be possible to gain access to Rutherford via other machines connected to the network and INDEX (some of the VAXes) and hence the inability to get to Rutherford may be due to ignorance of other routes or lack of ids on those machines. I hope this clears up the problem and I think that only the publicity for alternative routes through CERN is needed.
Present:- I Brackenbury IBM P Bryant RAL
A Burraston RAL P Girard RAL
B Marks IBM B Robinson IBM
C Setford IBM
Apologies:- R Cooper JNT N Dunlop IBM
P Girard and C Setford were present.
For 'address reversal' read 'domain reversal'.
All matters arising are dealt with below.
The agreement should now have been signed by A E Millington of SERC. [Note. The letter from P Bryant appears to have gone astray but A E Millington has now sent the document - 15 October].
Rutherford is currently in a recruitment exercise and, although the advertisement did not include the EARN support post, if there is a suitable candidate he will be offered a position. Otherwise the post will be included in the next trawl. The boards for the current trawl are to be held in the week commencing 27 October. The date of the next trawl depends on the success of this one and will probably be in a month or two.
RAL were asked for details of their recruitment procedures and these are detailed in an appendix.
The mail statistics collection code is now in place. The records are put into a general purpose accounting file, The code to select the records from the file is not written. Unfortunately the person dealing with this activity has recently left and the new person is still learning. A selection of about 200 records will be sent to P Hilton of IBM. Action: A Burraston.
The collection of statistics is achieved via a general purpose accounting file so that the scheme for producing various reports can be done automatically. Otherwise the running of these programs would have to be done by the group.
P Bryant stated that he would like about a months worth of figures before 1st April 1986 in order to produce the cases for funding in 1988/89.
FTP statistics should be available from about December.
I Brackenbury wanted statistics as soon as possible so that a history of use could be built up. Unfortunately no guarantees could be given when regular collection could begin as the requirements on staff can alter fairly rapidly depending on RAL requirements. Currently only the total throughput of the gateway is recorded.
3 or 4 sites are now operating the X.400 code. Zurich, RUNIT, Nijmegen, and hopefully by now CERN. Ireland is still waiting for a Series one. QZ has staff problems. Nothing has been heard from Montpellier. The UK has come across a number of problems and is seeking help from Heidelberg.
So far only information on setting up the system is available. There will be a brief discussion at the EARN technical meeting in Berlin. At Berlin a meeting for a full X.400 meeting will be set up.
P Bryant tabled the draft papers for the forthcoming UK EARN users meeting. The section on the IBM/RAL agreement was redrafted. IBM felt that the IBM/RAL meeting should discuss the topic of all academic international gateways. RAL felt that the meeting should only discuss networks in the context of EARN as the meeting has no jurisdiction on other matters and a public statement to discuss these wider matters could be considered as undue interference in them. It was agreed to add the phrase limiting the range of topics to those effecting EARN.
This item was not taken.
This item was not taken.
This item was not taken.
Wednesday 3rd. December 1986. Rutherford Laboratory.
Recruitment exercises are organized for divisions by the personnel department as required by the various divisions.
Most recruitment is at the lowest levels of Scientific Officer and Higher Scientific Officer. This is normally for new graduates or for those with a few years experience. Recruitment at higher levels is for specific posts and specific advertisements are normally issued. Advertisements at the lower levels are normally for a variety of posts. A number of the more urgent requirements are specifically mentioned in an advertisement.
After an advertisement has been published in a number of journals and papers and the replies have been received these are circulated to the Group Leaders having vacancies. From this a short list is produced and the selected candidates are invited for an 'open day' when they can discuss the jobs on offer and the division can undertake a further selection. A first informal view as to which posts candidates will go to is made,
Those candidates who wish to proceed and which a group still wants are then invited to a formal board. The board is chaired by a senior member of the division aided by a technical expert. A further board member comes from another division to ensure that candidates come up to an acceptable level. A civil service commissioner is also present to ensure that the recruitment standards are uniform across all government institutions.
The candidates are assessed on two counts. First - are they suitable for the grade. Second - are they suitable for the post. Once the list of successful candidates is complete informal discussions take place to assign candidates to posts, this may reduce the list to those successful candidates, those classed as reserve candidates and those not required. Offers are then issued. When the acceptances have been received there may be some further rearrangement of people to posts.
Users of the CRAY computer installed at Rutherford Laboratory would ideally like very high speed access to make best use of the facility.
The reasons for the requirement are:-
There are four possible existing communications mechanisms:- !!!!!!Are there any others!!!!!!!
There are a variety of proprietary network products but their use on a wide scale is discouraged since operation will depend on the continued support of the product by a single source.
Advantages:-
Disadvantages:-
Note that it would be possible to operate SNA over JANET to allow IBM equipment to be located remotely or for IBM to IBM communications of a high functional quality. This would be less efficient than using IBM lower layers due to JANET transmission blocks being smaller. If the IBM lower layers (not possible over JANET) are used then the higher line speeds of up to 64K will provide a good IBM 3270 service.
An even better performance and range of services can be obtained using a product such as PIXNET via 2M Megastream links. Full advantage of such a connection really requires an IBM computer at the remote end. It does allow channel to channel communications and the remote user would have a service almost the same as the local user. Use of this equipment on a wide scale may be inadvisable as its continued support depends on a single company.
Advantages:-
Disadvantages:-
Note that as with SNA DECNET can operate over JANET but at a reduced efficiency due to the smaller block size.
Advantages:-
Disadvantages:-
Note that these protocols, which originated in ARPA, are being used in the American NSF super computer project.
Advantages:-
Disadvantages:-
Notes
For remote high speed, interactive, high quality graphics TCP/IP is the only solution. This is the only way in which such activities can avoid the use of the front ends which would impair performance. The support of such a network would be a major undertaking depending on the number of sites to be supported. It is difficult to give accurate costs without some idea of the size and topology of such a network.
The use of IBM or DEC network methods will not provide a high quality interactive service to the CRAY but rather a high quality service to the front end for the rather more traditional edit/run/display types of activity. This 'high quality' of service must be evaluated against the improving quality of service provided by JANET and the improving quality of service provided by IBM and DEC. In the case of JANET the use of higher speed lines and the possible impact of full screen methods such as SSMP must be considered. SSMP is the recently developed Simple Screen Management Protocol which can provide 3270 or VT200 services on a wide variety of devices and is available under VM/CMS and VMS. In the case of the manufacturers one can expect reductions in equipment costs, improved devices (for example VT200 instead of VT100), and the ability to take advantage of higher speeds (for example IBM 3725 instead of IBM 3705). There is unlikely to be any improvement in the proprietary protocols provided but one can see considerable improvements in the JANET protocols as ISO is introduced and manufacturers support them.
It is most important to note that once it has been decided to use a network or networking methods other than those used in JANET then there is a heavy cost to pay in terms of private lines to be maintained, equipment to be purchased and by no means least the manpower to run such systems.
From a national point of view the provision of a private network can be viewed as undermining JANET and can be guaranteed to attract adverse criticism from some parts of the community.
!!!!!!Note that there are products for putting DECNET onto IBM computers and SNA on VAX computers and I have not investigated these. I suspect they would not provide 3270 into a VAX or VT200 into an IBM or, indeed, any high quality cross range interactive facilities.!!!!!!!!!
The Cashmore proposal with respect to mail is, with some caveats, possible - in fact, half of it exists NOW and my student is working on it.
Basically he wants, what we in the trade call, a 'mail relay'. As you know, the GEC already provides a mail relay. For example, I can send mail to B.W.Davies@RL - this gets sent to the GEC which converts it to the obnoxious and totally opaque form BWD@RL.IB. Isn't this just what he wants in principle? Clearly this will work for mail originating in JANET as Cashmore@RL can be converted by the GEC to XYZ%EARNADDR@UK.AC.RL.EARN which is the sort of form he objects to. BUT note it would not be possible EVER to send to Cashmore@EARNADDR which is what he really wants as this would mean registering EARN addresses such as EARNADDR in the much loved Name Registration Scheme and this is not welcome just now (or ever). He could, of course, put code in his own machine is recognize @EARNADDR and translate it himself to the 'standard' form but I do not think the VAX has the same superior and flexible code that we have in the GEC. You may also have twigged that if Cashmore had such code in his own Oxford machine he could get whatever effects he wanted irrespective of us.
The reverse direction is not possible by this route since he would have to hurdle the gateway (his main gripe) before he could get to the GEC and thus the best we could offer would be Cashmore@RL.AC.UK (instead of his hated XYZ@VAX.OXFORD.AC.UK which uses the much talked about NRS name in the reverse order).
Before giving up, remember, we are attempting to move the facilities in the GEC for mail relaying into the IBM so we can 'big E' the GEC. It would then be fairly trivial to make such a facility available on the EARN side of the gateway as well as the JANET side although this had not been planned. In that case Cashmore@AC.UK would work (getting better!). BUT this will in no way improve the JANET to EARN situation as the block is the NRS. He suggested that he would like the form Cashmore@UKACRL as UKACRL is the EARN name of the IBM. This needs thought. Just now it would not work as UK.AC is the EARN name for the IBM for 'mail' and UKACRL is for low level addressing. Thus mail which is sent to the IBM to UKACRL will certainly get to users on the IBM BUT will avoid going through the mailer and thus we do not have the opportunity of catching the mail and relaying it. It would, I think, be possible to register UKACRL for mail as well as AC.UK but I am reluctant to do it as it makes life confusing for the user having two names which seem identical. Incidentally, the name AC.UK was chosen so that the remote EARN user could use the form such as @VAX.OXFORD.AC.UK which is the reverse NRS name which remote and our mailer can deal with. I would not be happy with allowing @VAX.OXFORD.UKACRL which has no registered meaning and would take a lot of parsing in the mailer.
The work to put in the relay function is being done by a student and as he has only been at it a week I do not know his capabilities I cannot predict a delivery date. Off hand I would say end of March but don't quote me.
Now for the nasty side of it. Management. We will have to find the resources to manage the tables. You will recall that we have not even got the mechanisms for keeping people on site in the GEC table automated. Where is the effort for maintaining the tables for these new additions. Also, I haven't the faintest idea how many people will want to put entries in the tables. If it is a dozen then no sweat. If it is 1000 then we have a BIG problem. Also remember that we are putting about a man into EARN unfunded although SERC is probably the biggest user of EARN. (Thought- how about charging 10 pounds a year per entry!). My own view is that there will only be one entry - Cashmore's. But I am biased as I understand how the gateway operates and how EARN and JANET name registrations work.
Cashmore is wrong in thinking EARN has a long future. It depends whether BT, DTI and CEPT will extend the license and whether I can find the funds (I hope Cashmore will be putting his hand in his pocket). Also, at the recent Board of Directors meeting it was suggested that EARN migrate to ISO by first migrating to SNA - this will certainly cause CEPT to 'twitch' - it has already made JNT 'twitch' - I am in a continual 'twitch' over it.
To make things clear -
For JANET-EARN traffic we allow
Cashmore@EARN.SOMEWHERE or Cashmore%SOMEWHERE@UK.AC.RL.EARN (not recommended but needed to pacify some mailers).
We can allow with only administrative effort
Cashmore@RL
There can be no improvements by work at Rutherford.
For EARN-JANET traffic we allow
Cashmore@VAX.OXFORD.AC.UK or Cashmore%UK.AC.OXFORD.VAX@AC.UK (Not recommended - again to pacify)
With small effort we could allow
Cashmore@VAX.OXFORD.UKACRL or Cashmore%UK.AC.OXFORD.VAX@AC.UK (These are confusing to me)
We will be able to allow
Cashmore@AC.UK We could allow Cashmore@UKACRL
NOTE that the NRS forms I have shown can be any acceptable form - long or short - or where there is no ambiguity elements can be dropped example Cashmore%OXFORD.VAX@AC.UK is OK.
So much for mail. For file transfer the picture is not so good. The protocols on the two sides of the gateway are so different that fairly nasty things have to be done. In brief the protocols do not admit to the existence of a relay function. The way it could be done is as Cashmore suggests. Each gateway user would have to have an account on the IBM and then the file would be sent to that account as if it were the final destination. Every so often a job would start under that account which would pick up the files from the reader and send them on there way. Not all that difficult to achieve. If we had to cater for a few people then no problem. If 1000 people wanted to use such facilities then we need 1000 accounts with jobs automatically starting now and again. This sounds a lot of resources. It would also delay file transfers and would need a lot of storage. (Remember - the gateway deals with 500M bytes a month). So who pays for the accounts and who sets up the system for each user individually? Of course such a system could only deal with a small fraction of users. Remember there are at least 500,000 users of EARN and a not dissimilar number of JANET users - not that they would all want to use such a facility - but there is potential. Incidentally, this scheme could also be used for mail but the code needed would be much more complex.
BUT we already have an EXEC which we freely distribute round EARN which allows the user on a VM/CMS machine to type:-
FTP some file TO Bryant AT uk.ac.rl.gb
This fairly easy to use - the one liner above says it all!
So what do we do? Or shall I put it another way - how much are you prepared to spend? To my mind there is no great problem and only Cashmore and a small number would want to use it. Thus a high expenditure project would seem inappropriate which rules out the scheme outlined for file transfer. For mail we could give Cashmore the facility he wanted, not publish it, and hope no one else found out about it.
I am sorry this is so long but it is a complex question.
The letter from Anne is apparently a 'set up' so we need to take care.
The official situation I would like to see is that mail problems are dealt with in the first instance by the 'site' on which the machine resides. The site should then escalate the problem to other sites if required. In practice it is often clear where a problem is and the user should not feel inhibited from approaching the seat of the problem.
We, as the competent (that's a joke) authority for communications on this site must take some responsibility for mail problems thought to reside on this site. Thus we should accept complaints about GEC mail and pass them to the competent technical people, which in the case of the GEC is Informatics division.
Turning to Anne's letter. If there are problems between Rutherford provided computers on a campus and other machines then the campus should investigate such problems. If the problem is identified to be one with Rutherford provided code then we should accept responsibility. We should expect the managers of the Rutherford provided computers to liaise with the site and Rutherford to solve problems. In general there should be direct communication between the support organization in Rutherford for a machine type and the remote manager. Escalation to CCD management should be a rare occurrence.
I agree with Anne that we should make our position clear. Our position must be agreed across our site probably via RCCC. We must avoid at all costs becoming responsible for mail on other peoples patches.
The reasons why mail gets lost are many:-
The IBM looses its spool. (No solution).
The Glasgow GEC was incorrectly not registered for mail in the NRS and so it was not possible to mail to it for a time. The novice sender may well interpret this as a 'black hole'. (Now solved).
On the GEC exhaustion of disc space can loose mail. (Bug).
On EARN the black hole is a way of life as only 50% of computers have mail systems and mail incorrectly addressed will 9 time out of 10 vanish. (Working to make mail systems more common).
On VAX mail is lost if the disc allocation is exceeded. (Bug).
On VAX mail which is automatically forwarded over DECNET it is reliably lost. (Bug).
Network failure for a long period will cause some machines to give up trying to send some mail but this should be reported to the sender but the sender does not always understand such messages. (Fact of life).
I have no idea how much mail is lost. I suspect from my own experience that it is no more than 1 percent.
Lastly- there is no magic wand to make mail totally reliable. There are lots of small jobs and most of these are beyond our expertise to solve.
CEN/CENELEC is the European standards institute set up by the European Commission. CEPT is the advisory body for the European PTTs.
'Functional standards' are standards which define how one or more 'base standards' (ISO standards, CCITT recommendations and so on) are used in combination to meet a particular requirement. Functional standards fall roughly into groups -
The classification of profiles was first defined by SPAG and this has been adopted by the functional standards project.
In principle equipment can be certified for conformance with one or more functional standards. It should also be possible to use then in procurement activities.
The definition of the functional standards project is in a document known as 'Memorandum M-IT-02' which has been adopted between CEN/CENELEC and CEPT.
The technical program is in 'Memorandum M-IT-02'. This document is updated from time to time as the project proceeds.
The other documents are the functional standards documents themselves.
There are, of course, a vast pile of working documents.
CEN/CENELEC information technology activities are controlled by SOGITS (Senior Officers Group Information Technology Standardization).
ITSTC (Information Technology Steering Committee) deals with the political aspects of the functional standards activity and is manned/womanned by members of CEN, CENELEC, CEPT and EFTA.
ITAEGS (Information Technology Ad hoc Experts Group) deals with the technical aspects of the program and is composed of the chairmen of the working groups and some other experts.
The working groups are composed of ether CEPT representatives and a CEN/CENELEC observers or delegates from the CEN/CENELEC member bodies (BSI, DIN etc) with observers from CEPT.
Each functional standard is allocated to CEN/CENELEC or CEPT depending on whether the topic is of major interest to one group or the other.
ITAEGM (Information Technology Ad hoc Experts Group in Manufacturing) is a sister group to ITAEGS and is interested in MAP functional standards.
There are an abundance of other organizations in the functional standards business. There is the NBS workshop, COS, TOP, MAP, SPAG and maybe others. Although all these organizations are not all equivalent there is a clear need to rationalize the situation. The general opinion seems to be that ISO should become interested in the work and organize it on an international basis. Currently this proposal is immature. Until and unless such an activity is in place the CEN/CENELEC CEPT work will continue. None the less, the work of the other groups is carefully monitored to ensure some level of harmony.
The functional standards project started in Spring of 1985.
The functional standards which are complete or in draft form follow. The descriptions of each functional standard have been abbreviated and may give an inadequate view of an activity. For full details please consult M-IT-02.
A221 Basic Teletex A311 User Agent and Message Transfer Agent (public X400) A3211 Full service capability (private X400) Q213 Teletex character-coded text Q217 Videotex character-coded text T31 Permanent access to PSDN (transport service) T32 Switched access to PSTN T41 T.70 Case T42 Connection Orientated Case T611 CSMA/CD connection orientated network service T6211 CSMA/CD connectionless network service, single LAN T6212 CSMA/CD connectionless network service, multiple LAN R21 LAN/LAN relay connectionless network service Y11 X.29 over X.25 Y12 X.28 (PSDN character mode access)
Future work is expected or is started as follows:-
A111 Simple file transfer (unstructured) A112 Positional file transfer (Flat) A113 Full file transfer (Hierarchical) A122 Positional file access (flat) A123 Full file access (hierarchical) A231 Group 4 facsimile (digital and OSI) A312 Private UA - ADMD (P3 P2) A314 Teletex terminals to ADMD (P5) A323 MTA-MTA (Intra-PRMD) (P2 P1) A325 Mailbox service access (P7) Q111 Processable teletex Q112 Basic document processing: character content Q113 Basic document processing: mixed content Q114 Advanced document processing: mixed content Q121 Telex-compatible documents Q132 Teletex-compatible documents Q211 Teletex character-coded text Q213 Word processing character-coded text Q311 Upward scrolling line mode displays Q321 Fixed viewport page mode displays S11-33 16 Character and control repertoire specifications T21 Telephonic circuit connection network service permanent T22 Telephonic circuit connection network service switched T612 Token bus connection network service T613 Token ring connection network service T722 Token bus multiple LAN T623 Token ring multiple LAN R11 LAN-LAN connection network service relay R12 LAN-WAN connection network service relay R22 LAN/WAN/LAN connectionless network service relay C111 Teletex on PSTN C112 Teletex on PSDN C113 Teletex on CSDN C114 Teletex on ISDN
The functional standards program has now produced a useful first set of documents. These have been produced in haste to meet an urgent demand and are known to be less than perfect. Since this is the first attempt at such standards this is not surprising. But, as the project has progressed the production of functional standards has improved and developed as experience has been obtained.
The functional standards have an expected life as CEN/CENELEC 'pre-standards' of two years after which they become standards or be reviewed. They will not be modified during that period although supplementary information may be published.
Functional standards should ensure that interworking of various manufacturers products is possible. It gives a firm base from which implementors can work. It also provides help and guidance to purchasers who have to install networks of heterogeneous equipment.
CEN/CENELEC is anxious to receive feed back on all aspects of the documents.
The Y/11 Y/12 are functional standards which may be applied to a packet mode DTE, a PAD, and a start-stop mode DTE. Or in other words they tell you how to use the CCITT X.3, X.28, and X.29 recommendations.
The functional standard attempts to make the best possible use of the recommendations. No attempt has been made to ensure that existing or proposed equipment conforms to it. In particular public PADs are unlikely to conform as they are now provided.
The packet mode DTE (or host) is required to work in one of five profiles. A profile is a particular set of the X.3 parameters. The DTE must offer one or more of the profiles and it is allowed to change between profiles using certain rules. The DTE is only allowed to change parameters in a number of well specified ways.
The five profiles are:-
The functional standard requires PADs to implement all the CCITT parameters and their values both mandatory and optional. This is to ensure that the PAD will work effectively with any packet mode DTE regardless of whether it conforms to the functional standard.
The functional standard concludes with a tutorial on the reasons decisions were taken plus some useful comments on implementation issues.
The functional standard is due to voted on December 8the. Unfortunately there is a certain amount of contention which is centered on whether one should have taken care to make as much existing equipment as possible conform. You will have wait for the results of these further discussions.
If the vote is positive then the next job is to approach the manufacturers to ask when they expect to provide conformant equipment. Already some initial approaches have been made but so far little feedback has been received. This will be pursued more vigorously if the vote is positive. It will also be pursued on a Europe wide basis. It is hoped that COSINE will take some part in this since our community has a strong interest in a uniform service Europe wide.
CEPT has expressed concern over the content of the Y/11 Y/12 functional standard (FS). This document explains the Y/11 Y/12 working groups reasons for the decisions which CEPT questions and suggests some solutions. Should any solution be considered acceptable which requires significant changes then it would seem appropriate for the working group to reconsider the FS and to re-submit it for a vote as the CEN/CENELEC member bodies would need time to reconsider these changes.
The principle concern seems to be that the functional standard excludes many PADs from being able to claim conformance. This is indeed indisputable.
At its first meeting the working group decided three important issues which it has maintained throughout:-
It is assumed, as there is no comment to the contrary, that CEPT is happy with the philosophy applied to the DTE equipment and thus no comments on this aspect of the FS are included here.
There are a number of options which can now be taken to accommodate the CEPT position which may not be exhaustive.
The easiest option is to exclude the PAD from the FS. This would dilute the effect of the FS on the DTE since many PADs would be unable to take advantage of the sub-options 3,4 and 5. It may prevent interworking for DTEs which insist on using these sub options. The customer for private PADs would be unable to ensure that PADs he purchased could interwork with his DTEs without extensive investigation of the PADs. There may be pressure on the PTTs to provide PADs which interwork with DTEs providing sup-options 3, 4, or 5 and there would be no document defining how this should be achieved. There is considerable benefit in insisting that PADs conform to X.28 to give a common user interface which is not currently the case particularly with private PADs. I am of the opinion that this option would receive considerable opposition from the group.
A more satisfactory option would be to only demand features in the PAD which are needed to support the 5 sub-options defined in the FS. This would not meet the CEPT concern as it would still require many of the optional features. A draw back would be that non conformant DTE equipment may want to take advantage of these omitted optional features. A further draw back of minor importance is that if at some future date the FS is extended to include the use of further optional features then the existing PADs would immediately become non conformant which I suspect would be unacceptable.
A half way option is to give the PADs sub-options which match the sub options of the DTEs. Thus the customer could purchase DTE and PAD equipment which offered the same sub-options. In an open systems situation this would not be convenient as there is no way of knowing what equipment will interwork with other equipment without some research which is counter to the object of encouraging interworking.
A second, and in my view, less important concern of CEPT is that the document references OSI. It is unclear exactly what is referred to but it is thought to concern comments on the X.25 facilities included for the support of the ISO network service. This was done for three reasons. First, for compatibility with T/31. Second, to avoid any ambiguity as to what an implementation should include. Third, and most important, to allow the use of the extended address facility. It is observed that the CCITT recommendations do not admit to traffic crossing a concatenated set of networks. This is a real requirement as there are now many private networks gatewayed onto other public or private networks and terminal traffic needs to traverse these gateways preferably automatically. This can be done if X.28 allows the input of an extended address. It should be noted that a submission from BT to extend X.28 is likely to be accepted by CCITT for the 1988 recommendations. If the CEPT concern is about ISO references then it should be remembered ITEAGS has recommended that ISO references should be given in preference to CCITT ones.
The last CEPT concern is that Y/11 Y/12 should not include comments on X.25 but should reference T/31. This has been discussed in another context by ITEAGS. They concluded that an FS should be complete with respect to its mandate and only reference the base standards. There are two reasons. First, the higher level protocol should demand only the features it needs from the lower levels and various higher levels may have different needs. Second, if an FS references another FS then the first FS can only be regarded as valid when the first one has been accepted, also changes in one FS will effect the other. This was thought undesirable.
An interesting observation is that an FS for an X.25 network could be inferred by the FS T/31 and Y/11 Y/12 complicated the issue by having to consider both FSes. To my mind the correct solution to this problem is to apply an FS to the X.25 network. Clearly such an FS would have a strong effect on T/31 and Y/11 Y/12. It must also be remembered that an X.25 network should be expected to carry rather more services than those defined by T/31 and Y/11 Y/12. For example, it is reasonable for X.25 to carry SNA traffic conforming to X.25. Thus one expects the network itself to have a rich set of features just as one expects a PAD to have a rich range of facilities as compared with the DTEs.
Lastly, the main interest of the group, and of the project, is to encourage interworking.
The EARN Technical Group was set up by the EARN Board of Directors as a vehicle for discussion of technical matters concerned with the operation of the EARN network.
The Group is led by the EARN Technical Coordinator who is a Board appointee and sits on the EARN Executive Committee.
The working methods of the Technical Group have been developed informally by the Coordinator in discussion with the Board, the Executive, and the members. The current activities are:-
The initial meeting was attended by nominees from each Board member plus invitees from suppliers and from BITNET.
Subsequent meetings has been advertised to the Board members and to previous participants and no attempt has been made to check credentials but the right to reject applicants in the interests of keeping meetings small has been retained but never used.
The mechanisms are deficient in that there is no way of preventing attendance by people thought undesirable.
So far meetings have been fairly un directed and have considered a wide variety of topics.
It is proposed that in future the technical meetings concentrate on questions posed by the Board of Directors. Thus, the Board of Directors would draw up the technical meetings agenda. If this procedure is adopted then attendance at the meetings should be limited to those willing to contribute to the particular discussions.
This procedure has the disadvantage that the meetings could no longer be used for educational purposes and for informal discussion to the extent they are now. (Estimates are that 50 percent of members are observers in that they do not actively participate. It is also unclear how participants from BITNET could continue to be invited unless interested in the topics.
An alternative proposition would be to continue to allow fairly free attendance but to divide the group into working parties to address specific questions. It has become clear that with an attendance of 30 it is exceeding difficult to make any technical progress.
The EARN distribution list EARNTECH@CEARN has membership from anyone who asks. Subsidiary distribution lists are possible but little if any use has been made of them.
The system has worked well although from time to time the language has become a little rude and has caused complaints. Its main draw back has been the large amount of material that lands in the mail boxes of members.
Experience with conferencing systems suggests that this may be a better vehicle for the technical group but this needs some study.
To some extent the Technical Meetings is an opportunity for the members of the electronic distribution list to meet physically.
The Technical Group is self financing in that members will in general meet any costs in attending meetings. The costs of attendance will be kept to a minimum by organizing them at member sites.
I have put down a few ideas for the conduct of meetings. Would you have a look at the document and suggest any improvements please and we will then put it to the Board.
Dear James,
I enclose three documents:-
1. The papers from CEPT.
2. A paper from John Power which is an informal contribution.
3. Proposed changes to Y/11 Y/12 which are a set of proposed changes based on John Power's paper and from discussions within the 'UK academic transition to ISO' group.
4. Comments on the CEPT document.
I have produced document 3 in order to speed the drafting process should the meeting wish to incorporate any on the changes. They should not be regarded as reflecting any opinions of members.
Document 4 was produced as input for a possible meeting with CEPT as Jan Van Herp has been trying to get a meeting to discuss the CEPT views but I think it has all been left too late as every date has been impossible for some people. It seems a waste not to distribute the paper after all the effort to pen it. Perhaps you would look at it and decide.
I shall be in Brussels from 17-19 November so I guess we shall have no further opportunity to talk about the papers before you mail them to the working group (?) the expected participants (?).
It is going to be an exciting meeting!
With best wishes
Paul Bryant.
IBM.PB366
SCIENCE AND ENGINEERING RESEARCH COUNCIL
RUTHERFORD APPLETON LABORATORY
COMPUTING DIVISION
Proposed changes to Y/11 Y/12
issued by
P Bryant
13 Nov. 1986
I have received a few informal comments on Y/11 Y/12 and as a result have a number of proposed changes for the meeting to consider. The proposals do not necessarily reflect any views of the participants but are produced to speed drafting should the meeting wish to adopt them. The changes are classified as 'editorial', 'clarification', 'minor correction', and 'major correction' in order of severity.
1. Sections 6.3, 6.4, and 6.5 - editorial.
The use of the word 'working profile' is not correct as the section is considering changing between methods of working and not parameter minor changing while a sub-option is in use.
Propose to change all occurrences of 'working profile(s)' in these sections to 'sub-option(s)'. Delete 'defined in sub-option' in first and second paragraphs of 6.4. Delete 'defined in sub-option' in paragraph 3. Delete 'defined by the sub-options' in 6.5 first paragraph.
2. Section 6.4 - minor correction.
A case has been made for parameter 10 to be alterable by the packet mode DTE to accommodate some graphics applications.
Propose to insert ',10' between '5,' and '15,'.
3. Sections 6.3, and 6.5 - minor correction.
If a sub-option is entered which has not been used before the functional standard states that parameters which would normally be set are left unchanged. This could lead to problems if these have been set to some unacceptable values for the new sub-option. The suggested solution is for the packet mode DTE to read all parameters which are packet mode DTE independent at call initialization for the sub-options to which the DTE claims conformance. These are used when a sub-option is entered for the first time to set any packet mode DTE independent parameters that may be necessary.
Propose to modify last sentence in first paragraph of 6.3 by deleting 'not' and adding 'to their values read at call initialization'. Add new first paragraph to section 6.5 'At call initialization the packet mode DTE shall read all parameters which are packet mode DTE independent for the sub-options to which the packet mode DTE conforms.'
4. Section 6.8 - editorial.
PAD to PAD operation has been considered by some to be undesirable and the NOTE should be extended to give this view.
Proposal is to add to the end of the NOTE. 'PAD to PAD operations are provided for device to device operation and are not considered desirable. It is recommended that where such activities are required the called system should be a packet mode DTE even though the application is a device.'
5. Section 6.10.1 - major correction.
It has been pointed out that 'extended frame sequencing numbering' is required for use on some LANs and satellite circuits.
Triple X and X.25 over LANs and satellite circuits should be covered by further functional standards. No changes proposed.
6. Page 29 - comments on Parameter 7. Editorial.
The text is considered to be unclear.
Propose the section be replaced by - 'Various packet mode DTEs have different strategies when a break signal is received and therefore may have to manipulate the parameter controlling the break signal to meet their requirements. There may also be a desire to make a remote terminal resemble a local one as closely as possible. Thus the parameter is packet mode DTE dependent.'
7. Page 28 - comments on Parameter 2. Editorial.
The correct control of half duplex terminals depends on other parameters as well as parameter 2 and this is not made clear.
Propose to add sentence after first sentence - 'Note that the correct control of a half duplex terminal also requires other parameters to be considered, for example, parameter 13 will no longer send a LF to the terminal as the CR is not echoed, thus the packet mode DTE will have to generate any required LF.
8. Major correction.
When the PAD has data to send to the start-stop mode DTE it is unclear from X.28 whether it should be delivered if the editing buffer is not empty. Users have stated that they would prefer any such delivery to be delayed until the editing buffer is empty.
It can be inferred from X.28 (see section 4.3) that data should be delivered as soon as possible as there is no mechanism for the eventual output of that data should the editing buffer be non empty and the user elect not to initiate a forwarding condition or cancel the input. However the evidence is not strong.
If delivery were to be delayed then X.28 would have to be extended to incorporate a timer (Tx) which would be reset every time a character was entered into the editing buffer and on expiry of the timer delivery would be made. It would also have to be defined what should be done with the characters already in the editing buffer (note that even if delivery is made as soon as received by the PAD, X.28 is deficient in not defining this).
Since new protocol is required it would be inappropriate to add this material to the functional standard but it would be appropriate to add it to the Annex A. Two proposals are put forward for the Annex.
Proposal one is to add - 'Characters received by the PAD from the packet mode DTE shall be delivered as soon as received. If the editing buffer is not empty the PAD shall transmit the line deleted PAD service signal (or format effector?) followed by the characters waiting for delivery. The content of the editing buffer shall then be output.
Proposal two is to add - 'Characters received by the PAD from the packet mode DTE shall be delayed until either the editing buffer is empty or after a timer Tx has expired. Tx is reset each time a character is added to the editing buffer. Tx shall be 60 seconds. If delivery takes place when the editing buffer in not empty the PAD shall transmit a line deleted PAD service signal (or format effector?) followed by the characters waiting for delivery. The content of the editing buffer shall then be output.
9. Annex C C2 - editorial
Replace 'full address' by 'address' and remove underlining.
A list of documents distributed is appended. The document numbering is the authors. References are of the form (RW?).
RARE (RW7) is embarking on a EUREKA project COSINE (RW8,RW10). The Workshop was the first event where all the people involved in the project met.
The first day (RW1) was taken up with introductions from the participating organizations and by survey presentations of various aspects of communications in Europe.
The second day was dedicated to working sessions of the various working groups, WG1 through 6.
The last morning summed up the results of the working sessions and concluded the workshop.
For CEN/CENELEC CEPT functional standards there was some discussion as to how the COSINE community could contribute to the activity. Ideally they would like to attend working group meetings and it was unclear as to whether this would be possible.
The talks were either covering well known material or documents were provided.
H Huenke and M Carpentier explored the thinking behind the COSINE project and how it fitted into the rest of the Community's policy. Nothing new came out.
K Rupt outlined the COSINE project (RW8, RW10).
B Carlson outlined the various academic network activities in Europe (RW3, RW4). The point made was that there are many networks but that all, or most, countries have plans to support ISO protocols. Migration is going to be difficult and take a long time. There are many gateways between various types of networking exist in many places.
P Linington outlined the outline plan for COSINE (RW10).
The CEC talked about the activities of the Commission. (RW2, RW6, RW9, RW11, RW12, RW13, RW14). The various projects were outlined.
D Gagliardi discussed CEPT and its activities (RW5). There was the suggestion that future bulk transfer services would be via ISDN rather than X.25. In later discussions there was quite a bit of discussion on the exact relationship between the two and it was clear that there was considerable ignorance on what ISDN would provide. It was clear that CEPT was very keen to cooperate with the academic community in particular for trying out new services. However the point was made that the academic community must differentiate carefully between research and service activities and not inflict experimental services on users who wanted reliable ones.
The CEN/CENELEC and SPAG activities were outlined.
As the Working Groups were in parallel sessions this report is compiled from documents and discussions. It was clear that the sessions were attended by people of mixed knowledge on the subjects. Hence the groups did an educational service in many cases and the technical progress was modest. There was a general point that there were few industrial participants and COSINE is most anxious to have close cooperations with them.
Managerial aspects. This was not well attended. I have no report.
FTAM (RW29). This groups is well advanced and has produced many documents (RW20). They are intent on using functional standards but on the other hand they are requesting the inclusion of recovery and restart mechanisms. They want to define a 'user interface' and would like this as an addendum to the functional standard. There is concern over the different approaches to network and transport services in Europe and America. It seems that relays of various sorts will thus be needed. FTAM would need a directory service and therefore name registration services which should be raised more generally. There was concern over the cost and bandwidth of public networks.
Triple X (RW29). The functional standard and its problems were outlined. The next stage, if the functional standard is successful, will be to approach manufacturers to ask if and when they intend to follow it.
MHS WG1 (RW19, RW21). This work is well advanced and is taking full account of the Functional Standards. The main thrusts are now to track manufacturers products, the provision of gateways, and directories. The group is now showing concern with user interfaces as manufacturers do not seem to be considering this activity. [Maybe, as with FTAM, an annex to the Functional Standards should be attempted].
Operations (RW22). Billing came in for study. The problems of billing are becoming well known. For example, the issues of who pays for returned mail, who pays for mail explosion, how do you return charges to users. The principle problem appears to be that there seems to be no model for accounting and control. This group was sympathetic to the PTT model that other networks/countries should accept traffic free of charge on the basis that traffic levels are about equal in both directions. Whilst this may be all right for PTTs it is more difficult for customers to accept such a procedure as they have to pay real money to the carriers for these services.
High speed services WG6. The group will study satellite and ISDN services. They have a number of customers waiting for these services. Pilot projects will be set up with industry to use the new technologies.
Full screen terminals and job transfer WG5 (PW25). The need for full screen services is unclear and only the UK has any firm plans to provide services using a standard (UK) protocol. VTP is insufficiently developed to provide services and this situations is not likely to improve quickly. Ideas of using FTAM for a service do not look promising. There was a call for resources to be put into taking part in the ISO work. It was reported that the UK were not impressed with the basic class of JTP being less advanced than their current provisions. It looks like there will be some work to define some interim (?) facilities based on FTAM.
This was a difficult meeting to describe as it was half political and half practical and I got the impression that half the delegates came for one purpose and half for the other.
As a political meeting it raised awareness of what the project was about, what its aims were and what its time scales were.
As a technical meeting it did allow the participants to have many informal discussions with their colleagues in other groups and many useful contacts were made. I do not think a great deal of technical progress was made but on the other hand I believe that the meeting did cause a stir of activity beforehand to prepare various documents and so it was useful.
There is some disquiet at the support of the project. So far the groups have operated unfunded but in this form they have made good progress. Unfortunately funds in most, if not all, European academic institutes are small which is meaning that many experts are finding it impossible to participate. Some cynics believe that the results of the project will be available before any funding appears.
The meeting was heavily dominated at the expert level by the academics and there was some disappointment with the level of participation by industry.
This section responds to the particular questions from DTI.
In all the sessions there was no real progress. The subjects were covered adequately from an educational point of view and the arguments offered were fairly familiar to the experts. To my mind there are two very basic failings:-
Although the sessions were well populated with approaching 20 people this is no indication that the 'real' working meetings are well populated. I suspect that areas away from the glamour of X.400 or FTAM are badly populated. Since there were very few representatives from industry it can be fairly safe to assume that all the working groups are entirely or mainly supported by academics which gives considerable cause for concern - not that COSINE should be dominated by industry but the two need to speak.
The JNT takes care that the various groups have UK academic representation. At this meeting I would say it was reasonable. Unfortunately the cost of travel does not allow generous representation. One must repeat that UK industry was not well represented (1 person).
We must ensure that our experts have no problem in finding finance to attend meetings. I believe that the JNT is currently ensuring this.
The deliverables are all paper. The cost currently appears to be zero to the project and travel costs to many organizations. One might add that you get what you pay for!
These were not discussed and the schedule should be obtained from the COSINE administration.
I take it that this means a service. Discussions did not lie in this direction. A general view seems to be that the most important deliverable is a tariff that the academics can afford. Current tariffs will not encourage traffic and also demand that organizations set up elaborate mechanisms to recover charges from users. It appears that there is little problem is obtaining X.400 implementations as a number have been identified. Triple X needs no comment. FTAM is probably the major deficiency.
The following documents were distributed. It is likely that I did not get a complete set. They are in no particular order but I am willing to supply copies on demand.
RW1 Agenda for the workshop of the European research network COSINE. RW2 Information technology standardization in the European Community. RW3 Overview of national research networks. RW4 Networking in Italy. RW5 Foils from CEPT presentation. RW6 RACE - description. RW7 RARE - information bulletin. RW8 COSINE information bulletin. RW9 The ESPRIT IES system. RW10 RARE's outline proposal for COSINE project. RW11 European policy in research and ESPRIT IES. RW12 COST11 activities. RW13 European Communities policy for telecommunications. RW14 The European telecommunications services policy. RW15 Directory systems subgroup (WG3) report. RW16 Directory information. RW17 THORN. RW18 MHS usage of directory services (WG1). RW19 COSINE message handling service (WG1) RW20 Several FTAM documents. RW21 Model for the operation of MH gateways. RW22 Network operation and management in X.25 (WG4). RW23 Full screen services (WG5). RW24 RW25 Y/11 Y/12 functional standard. RW26 CEN/CENELEC functional standard progress. RW27 COSINE policy group. RW28 Working session arrangements.
Present:- CEN/CENELEC J Van Herp Central secretariat R Rinald Olivetti R Lloyd ICL (Chairman ITEAGS) P Bryant Rutherford Laboratory (Chairman Y/11 Y/12) CEPT D Gagliari STET/Bruxelles (CEPT/CCH) L Tingstedt Swedish Telephone Administration (CEPT/CCH/SP) T Huebner Duchesbundespost (CEPT/CAC/NP) J De Heer Netherlands PTT W Roth Duchesbundespost G Moudiotis British Telecom Coppens RTT Belgium G Belloni PTT Italy
The meeting was called at the request of CEPT to consider the concerns expressed by CEPT with the draft Y/11 Y/12 functional standard. Mr. Gagliari was requested to chair the meeting.
The three concerns are:-
It was clear that the first concern was the principle one and most of the meeting was taken up with this.
A very detailed exploration of the philosophy behind functional standards and its application to Y/11 Y/12 took place as well as the CEPT concern. This led to considerable clarification on the respective positions.
A number of solutions to the problems were explored but no definitive one was agreed. It was agreed that the voting meeting scheduled for 7/8 December should be postponed and replaced by a joint CEN/CENELEC CEPT technical meeting which would attempt to resolve the issues and to further refine the document in the light of CEPT and other comments received. This should hopefully lead to a further voting meeting or if the situation cannot be resolved to further technical meetings.
Existing PTT PADs may not conform to the functional standard.
P Bryant explained the philosophy behind Y/11 Y/12 in that the technical group had decided to produce a functional standard that made the best possible use of the protocol and had paid scant attention to current public or indeed private PADs.
CEPT explained that they wished to follow a functional standard in this area but were in no position to make any rapid progress to one which demanded the amount of functionality in Y/11 Y/12. They conceded that given time it would not be unreasonable to progress to such PADs. They wished to avoid undue pressure from users to provide conformant services of that level of functionality before they were in a position to be able to supply them.
It is believed that the working group would be reluctant to match the functional standard to existing PADs as this would require a research exercise and in any case PTTs are liable to change their PADs as they see fit. In addition, such a functional standard would not enhance the quality of the service that the user would observe.
It was pointed out that there were basically two options. The first was to work on a technical solution which would probably satisfy neither party. The likelihood would be that other functional standards would suffer similar treatment to there detriment. The second was to attempt to find a solution that could be applied more widely.
In considering the second, and more desirable solution, it was noted that the principle concern of CEPT was the time it would take to conform to a functional standard and the exact content was a secondary concern. This leads to the conclusion that consideration should be given to the migration from the current position to a final and technically excellent situation. If this turns out to be acceptable on mature thought then it should be possible to devise suitable migration text.
Possible migration strategies would be, say, to define an interim class of PAD which would demand minimum functionality and only be available under CCITT 1980 recommendations. An alternative would be to include an annex along similar lines.
CEPT were also concerned that the PAD required more functionality that was required by any of the sub-options defined for the packet mode DTE. This is a further but minor issue that the technical group could address.
This issue was not discussed in detail and the exact objection is still unclear. It is probably an area where the technical group can make rapid progress.
The inclusion of text on X.25 was requested by ITEAGS. R Lloyd explained the reasoning behind the decision. In general there is no guarantee that the demands made on lower protocol layer are the same for a range of higher layers. It must also be remembered that the functional standards were not implementation guides and that the fact that each functional standard had its own text on its lower layers did not preclude the implementor using common code (or not) as he saw fit.
It was pointed out that the text of the X.25 sections in the two functional standards differed needlessly and that action should be taken to agree common text. It was also noted that the Y/11 Y/12 technical group had taken care that all statement made could be checked in equipment for conformance whereas T/31 contained text recommending certain items. This showed an interesting divergence of approach which is worthy of study.
The meeting suggested that it would be possible to overcome the fundamental concerns of CEPT without prejudicing the ultimate objectives of the technical group. Further, the procedure for achieving this may be useful in other areas.
The idea of joint CEN/CENELEC CEPT technical meetings on appropriate issues was welcomed and may lead to more rapid progress and the avoidance of this type of problem in other cases.
CEPT are concerned that current PTT PADs would not conform to the functional standards.
All current PADs are to the 1980 CCITT recommendations hence it is proposed that the functional standard should be unchanged with respect to the 1984 recommendations (that is - if option 1 is offered).
It is proposed that a PAD should be able to claim 'reduced' conformance. Reduced conformance indicates that the PAD offers at least the X.29 parameters which do not provide additional user facilities and their mandatory parameter values. Reduced conformance and option 1 are mutually exclusive. That is - a PAD conforming to CCITT 84 may not have reduced conformance.
The provision of parameters providing additional user facilities and optional parameter values shall not invalidate conformance. But note that it will still be forbidden to include any parameters, parameter values or features not in the CCITT 1980 or 1984 recommendations except as defined in the functional standard.
Packet mode DTEs not offering sub options 1 or 2 may be unable to interwork effectively with PADs with reduced conformance.
There will probably be a number of public PADs which will be unable to claim any conformance. It is known that some PADs include features not defined in the CCITT recommendations, also some PADs have faults which may inhibit conformance. There is no intention to allow such equipment to conform.
Proposed changes to Y/11 Y/12:-
Insert new second paragraph to section 6.1.
"A PAD not conforming to option 1 may claim 'reduced conformance' if:
a) some or all of the parameters providing additional user facilities are not provided
b) some or all of the optional parameter values are not provided."
Replace first sentence of first paragraph of section 6.6 by -
"A PAD not claiming reduced conformance shall support all additional parameters and all optional parameter values."
Replace second sentence of penultimate paragraph of A1 by -
"The functional standard is not primarily directed towards interworking with such implementations but is intended to ensure that implementations which conform to the functional standard will communicate effectively."
Insert new penultimate paragraph to A1 -
"Reduced conformance is only applicable to PADs conforming to the CCITT 1980 recommendations and allows such PADs not to provide the optional parameters and optional parameter values. Many current PADs do not provide these features and reduced conformance allows these PADs a level of conformance to the functional standard. This does not allow PADs which deviate from the recommendations to conform. The expectation is that new equipment and equipment conforming to the CCITT 1984 recommendations will provide all the features and reduced conformance will only be required until current equipment is phased out. It should be noted that packet mode DTEs which require to operate with sub options 3, 4, or 5 may be unable to interwork with PADs with reduced conformance."
Add new final paragraph to A16 -
"A conformant packet mode DTE may interwork with a PAD claiming reduced conformance if the existence of the parameters which provide additional user facilities and the optional parameter values are not demanded. This will always be the case if sub options 1 and 2 are used."
The exact concern of CEPT is not yet understood.
CEN/CENELEC do not consider that Y/11 should reference T/31 for text concerning X.25. They consider that a higher level protocol may well require different selections from the base standards of the underlying protocols. It would not be appropriate for one functional standard to have to take account of the requirements of another functional standard in selecting the facilities in the lower levels. There would be difficulties if referencing another functional standard which did not have a positive vote.
Since the X.25 text in Y/11 and Y/12 is derived from the text in T/31 it would seem appropriate to attempt to align the text as far as is possible. Y/11 Y/12 working group had concern that some of the statements in the T/31 text were incapable of a conformance test and these were thus amended. A dialogue has been started with T/31 to progress the matter.
CEPT have suggested that the PAD should only contain sufficient functionality to meet the needs of conformant packet mode DTEs.
Replace the first sentence of the first paragraph of 6.6 by:-
"A Pad shall support all additional parameters. A Pad shall support all optional parameter values except it need not provide the optional parameter values for parameters 1, 3, and 7, also parameter 4 need only provide the optional value of 1."
Note that full flexibility has been retained for the Packet mode independent parameters to retain maximum interworking with start-stop mode DTEs.
Dear Wolfgang,
At the recent meeting in Brussels Richard Lloyd went into the problems of one functional standard referencing another. Since it appears that this will not be possible there was a suggestion that we attempt to align the text of the two functional standards as closely as possible. Indeed we could put in footnotes where the text differ.
Originally my working group had intended to reference T/31 and when this was denied we took the T/31 text and amended it to meet the philosophy of Y/11. Hence the two texts are structured in a similar was which gives a good start. I have now looked through the two documents and examined the reasons for changes, these are listed below. I have classified them as:-
I have taken as T/31 base text T/CD 08-01 (Version 2). (Unfortunately I have mislaid the later version).
I have taken as Y/11 base text version 7.
* Y/11 page 18 - T/31 page 11 (text)
There are many changes which are necessary as follows:-
- all of section 8.1 is relevant to network service and so is irrelevant to Y/11.
- the heading of 6.9.1 in Y/11 is copied from the CCITT X.25 1984 recommendations as being the correct description of all the X.25 facilities used in the subsequent table
- paragraph 2 of 6.9.1 in Y/11 is a useful addition to stop DTEs failing a call if unknown facilities fields are included in a call.
- paragraph 3 is only of relevance to Y/11
- paragraph 4 has been added as this point was not made in T/31
- paragraph 5 was added to Y/11 to ensure that the old 32 semi-octet recommendation is not followed.
- paragraph 6 is needed in Y/11 as it is relevant to CCITT 1980 recommendations.
Table 1 T/31 - Table 2 Y/11 >
The tables have some significant differences. Y/11 took care to differentiate between facilities demanded, facilities which it would be possible to implement, and facilities over which an implementation has no control. A further classification ' not required' is provided to cover the facilities which is impossible to check for conformance. Y/11 found difficulty understanding the T/31 classification. For example - D-bit modification appears to be a subscription time choice and One-way logical channel outgoing et al are also subscription time options rather than a local choice. In addition Y/11 could see no difference between spc and spr as far as the implimentor is concerned. The five facilities for the support of the OSI network service were added for completeness and because the group considered that the called address extension should be supported.
Y/11 took the view that all facilities should be included which could be useful rather than providing a minimum of facilities. However this difference of approach seems to have resulted in only one difference- 'closed user group with outgoing access selection'. (Assuming class B and C).
Section 8.3 of T/31 is irrelevant to Y/11. Perhaps not absolutely true as Y/11 demands the support of the 'extended address' but in order to avoid getting involved in network service the format of this address was not specified.
Section 8.4 is also irrelevant for Y/11 in that it is considering what happens when a Type A system meets other Types.
Section 8.5 1 had no views from Y/11. 2 is irrelevant.
Section 8.6. Y/11 was unaware of any Y/11 test services and in any case they thought that such text should be in an annex since the statement is incapable of being tested.
Section 8.7 is irrelevant to Y/11.
The text in Y/11 6.10.1 and T/31 section 9.1 differs only in making multilink procedures optional. It is unclear whether they are illegal or optional in T/31.
Y/11 were unhappy with section 9.2 T/31 (6.10.2 Y/11). They felt that definitive values should be given or no comment made on the grounds that statements should be testable.
In section 9.2 it was unclear what the examples on the T1 timer added. It would have been useful to add timer values for all speeds.
In section 9.2 T/31 - 6.10.2 Y/11 the group felt some sort of range should be given for N2.
Yours sincerely
Paul Bryant.
At the recent UK EARN user group meeting the topic of the EARN future and its financing in the UK was raised.
The assumption is that EARN would either be closed down by DTI/CEPT/BT or would be allowed to continue for some time under the current conditions.
In the light of the situation it is now appropriate for CCD to issue a policy statement so that users can challenge our position or plan according to the policy.
Since the EARN service to the UK users started in October of 1985 the traffic has grown to 550 M bytes per month. The connection is about one third saturated before congestion will occur. It is unclear how far the traffic will grow since the rise in traffic has been erratic. Perhaps a ceiling of 1000 M bytes a month will be achieved.
The link does not appear to have been detrimental to the operation of the IBM computer. The spools have been kept reasonably small due to the good reliability of the connections.
A large number of academics now make use of the link. The operation is attracting good will towards CCD as the service is reasonably reliable, stable, and above all free. There has, to by knowledge, been few adverse comments from users although there has been adverse comment from the mail experts who are unhappy with the detail of how the gateway works and from a number of politicians who believe that such networks should not be encouraged.
IBM funding for the lines ceases at the end of 1987 but funds have been found to continue until the end of the 87/88 financial year assuming that the financial requirements do not change. There is no possibility of further IBM funding.
As a result of a recent decision by BT international the EARN lines from the UK no longer attract a volume sensitive tariff but only the normal leased line tariff. The leased line tariff is 1999 pounds per month for the UK end. The volume charge was 1.1 pence per thousand characters which is approximately the IPSS charge to Europe.
IBM funding is now agreed for a support person for 2 years from November. As yet no suitable candidate has been found.
The EARN Board of Directors has not yet decided on the future funding model for the network. Indication are that the UK will have to find finance for the total cost of the CERN line (about 25K pounds per year). The Dublin line will be financed entirely by Ireland. There may be a charge for EARN management but no decisions have yet been made. Suggestions are that a subscription of 250 pounds would be levied on each member site making about 12,500 pounds. Some time ago there was a proposal to set up a permanent EARN office with one or two staff. This proposal is now been shelved as a result of observing the hostility a similar idea in BITNET attracted. EARN management has been informed that the UK would be unwilling to consider any management charge until financial year 1988/89 on the basis that budgets until that time are now complete and changes would be difficult.
The possibility of re-routing the UK link to Montpellier instead of CERN is being considered as this will reduce the tariff to 18,000 pounds.
There is a possibility that some other countries may impose a volume tariff and in that case it is unclear how this would effect the UK.
Indications are that the running of the gateway on the current model is under a man year per year.
The license from DTI ends at the end of 1987. It states that an extension will not be with held unreasonably. It requires progress towards the use of ISO protocols. It seems likely that as long as EARN has shown some reasonable progress an extension to the license would not be with held but this is not certain.
CEPT also requires the network to migrate to ISO protocols and the use of public networks by the end of 1987. There are indications that CEPT understands the aims of EARN and as long as EARN is showing progress towards ISO its continued if temporary existence will not be opposed.
It is unlikely that EARN can migrate to ISO protocols or use of public networks by the given date due to lack of products from manufacturers.
Rutherford has donated a bit less than a man year per year to the project free of charge. From the SERC point of view this is not unreasonable since many of the users are SERC supported - in particular HEP who are now the major ones.
It is not reasonable for Central Computing Division to put in any additional effort without funding since the division is receiving nothing except good will from the activity. Of course, SERC may wish the division to continue to support or increase its support of the gateway but on past performance this seems unlikely and they would probably want any charges to be returned to the various boards or users.
The possibility of the closure of the network and the unlikely imposition of a volume charge make any heavy investment of effort into charging difficult to justify. Indeed, it would be reasonable to recover the cost of such effort from the charges thus increasing the charges to the user. The effort to implement charging would inevitably detract from improving the quality of the gateway and its service to the users.
The charging options are:-
4.1 The easiest method of meeting costs is to recover them from the major funding bodies such as SERC and the Computer Board. The exact division of costs could be based on the statistics collected during the previous periods. In particular the division of costs for the SERC portion could be allocated to boards in this way.
Management software to collect usage statistics is being produced which will be able to identify the major users and the traffic patterns. This software is not suitable for charging and has no control facilities.
4.2 It would be possible to introduce charging and control at the gateway but this would absorb about a man year to implement and would also have a high running cost in recovering the costs from the users. Also if the network remains in the main volume tariff insensitive the large UK users would be disadvantaged with respect to their European and American colleagues. It would not seem sensible to take this path.
4.3 An alternative model is to recover the cost by subscription from members. This could cause problems in that some sites are heavy users and other use it hardly at all. Thus the light users may be inclined to resign from membership to the detriment of their users.
5.1 It is recommended that funding should be sought for 50% of the costs from SERC and 50% from the Computer Board. Since the lifetime of the network is finite these funds should be sought on a year by year basis. The case put forward each year should be accompanied with a report on the operation of the network. This should state the traffic levels, identify the major users, and make comments on the usefulness of the service to the UK community. The first submission will be made by August 1987 for funds for financial year 1987/88. The request will be for a total of between 20 and 40 K pounds depending on EARN management requirements and possible reconfiguration of the network.
5.2 A policy statement should be issued as follows:-
The EARN gateway has been in operation from October 1986. The line costs up to the end of 1987 are being provided by IBM who are also providing finance for some user support. Rutherford Laboratory has provided about a man year of effort per year in producing the gateway and in management.
The gateway is providing a valuable service to the academic community world wide and in particular to the UK community and there is encouragement to continue the service after 1987 and before alternative services of a more permanent nature are provided.
In view of the low and bounded cost of operating the gateway and also the finite life expectancy of the network it is appropriate to seek central funding for the service rather than undertake expensive developments to provide control and accounting in order to reflect any charges to the users.
CCD intend to seek half the costs from the Computer Board and half from SERC. Rutherford Laboratory will continue to maintain and manage the service free of charge in recognition that SERC provides two thirds of the traffic.
Continued provision of the service depends the extension of regulatory licenses in various countries and of the tariffs remaining reasonable. Rutherford can give no guarantees that this situation will continue and users should take this into account in any use of the service that they plan.
The Group Leaders are invited to comment.
Although the project made a slow start there has now been good progress of late with 4 sites running the Heidelberg X.400 system and two others about to. Apart from the UK and Italy, which do not intend to run the system as supplied, it seems unlikely that any further sites associated with the project will now participate. Indeed, since work has now started on the final report it may well be difficult to introduce new sites if they are to participate usefully. This should not prevent the connection of new sites for other purposes.
Until recently it seemed as though the system had reached the end of its development. Now it is evident that Heidelberg are putting further resources into its development which gives cause for considerable optimism.
The meeting revealed that the group now has a very good and detailed understanding of the system and this encouraged a start on the drafting of the final report. There are still a number of areas where further work is needed and this has now been initiated.
Although a draft document will exist in January the final report will probably appear in April.
There will probably be two more meetings but since there are fewer participants and one of the meetings will coincide with the next EARN technical meeting there should be enough finance. The next meeting will probably be in Heidelberg to study the new developments.
Present Jim Staton IBM Heidelberg First morning only Christian ?? IBM Heidelberg First Morning only Paul Bryant Rutherford UK N Gunadhi Rutherford UK Heidi Berg-Hoff RUNIT Norway Hans Goosens Neimegan Holland Olivier Martin CERN Gerard Pittiloud Zurich Switzerland Bauch ?? TU Berlin First day only Apologies Ambrosino CNUSC Montpellier John Noland UCD Ireland
Jim Staton described progress.
The bomb damage had unfortunately stopped the production of tapes for the latest version of the system but they hoped to be operational very soon.
There are now 6 people working on the system at the ENC and 2 more will be joining the team shortly. This news was very welcome and showed that the system would be developed considerably in the future.
Although there was quite a lot of changes throughout the system the main discussion was about the user agent. This was originally based on PROFS. With the new versions of PROFS (version 2, PTF level August) the user interface had been improved. Note that PROFS documents cannot be handled. NOTE PLUS was being replaced by NOTE 400 which also was an improvement. This is now menu drive and has help screens. It can operate into X.400 or RSCS.
A further significant development will be to split the user agent into two so that a variety of user interfaces could be developed easily.
An important aspect is that the system is following the CEN/CENELEC functional standard which is also the aim of the RARE/COSINE activities.
No work is going on with respect to DISOSS but it is understood that discussions are taking place.
Interest in the Queens user agent has evaporated and it is understood that Queens is now more interested in a project with ICL.
A single operator interface is being provided to control the MTA, RTS and transport which should make things easier for operators.
The use of a 3725 with NCP-NPSI-VTAM-OSNS-OTSS is being looked at but as yet there are no firm plans or dates. This could be an attractive development.
A high priority is to improve the documentation and four documents will be provided:-
A problem in providing descriptions of the internal interfaces is that these are not very stable.
As a rough guide most of the coding for the improvements should be complete by the end of January and it will take 4 to 8 weeks to test it (say till end of March). This does not include OTSS.
There was a long discussion on gateways to RFC822 and how a service could be maintained during a migration and this is taken up later.
The Queens UA is in use. The new EAN has just arrived and interworking tests between the two systems should take place soon. There is currently a problem in that traffic from EAN arrives at the Series 1 minus its calling DTE address. Tests have been run to Zurich and Neimegan.
The Queens user agent is in use. New code has been installed at the same time as it was installed at CERN. However there are some problems talking to CERN which seems concerned with user names.
An interesting difference between the Queens UA and NOTE plus is that Queens reads all the mail off the reader before starting. In fact the new MAIL command for RFC822 also does this and it is to be preferred.
NOTE PLUS is in use. The site has a copy of the DEC X.400 and hope to run tests between the two systems in the next month. Apparently the VAX system is very expensive both in terms of money and CPU. Its user interface is the normal DEC mail interface and not very appropriate for X.400.
Only modest progress has been made. So far the strategy has been determined which is to provide a transport service in the existing X.25 package. Work has been delayed as the transport to session interface in the Heidelberg system has some documentation errors. This should be solved very soon.
The system first worked about two weeks ago after a visit form IBM. The latest version is installed.
The system is not yet working although all the hardware is now in place. They should talk to Berner Schults to sort out the remaining problems.
The system is installed but there is no Transpac line installed yet.
It has not been found possible to obtain equipment. It is likely that they will no longer participate.
It is thought that they will no longer participate. Paul Bryant will find out the situation.
It is believed that work has not yet started on putting the system over OTSS.
Mounting the system has been difficult. There has been some confusion over the exact hardware and software needed. It has often needed an expert to visit the site to sort out problems.
Once mounted the system has been stable.
This leads to the view that with better documentation it could be used by the less expert installations.
The principal difficulty has been to find the expert to fix the bug. This is really indicative of the fact that the ENC does not run a support organization. Thus if the system were to be used more widely some sort of support organization would be an advantage.
It is important that in any migration to X.400 over X.25 the services to the users should be maintained. This implies that there must be connectivity between the EARN NJE network and the EARN X.400/X.25 network.
There are several possibilities:-
It seems unlikely that the whole of EARN could be persuaded to migrate from RFC822. Also this protocol will be used on BITNET for a long time. Thus an X.400 to RFC822 gateway at the UA level is essential.
If X.400 is to be used over RSCS then there are two possibilities. The first is the Queens system and the second is to use the Heidelberg MTA over RSCS. It is unclear whether the latter path is possible and it is unclear whether the two approaches are compatible. None the less the procedure has the technical merit of providing a uniform service to machines on EARN RSCS and EARN X.25. It would be of no use to sites having no such system, that is, MVS and DEC sites.
RFC822 is not universally available on EARN. It is possible to communicate between X.400 and systems on EARN by the EARN users editing headers onto files destined for the X.400 world. This was used for the Hanover Fair demonstration.
The discussions suggested that since an X.400 RFC822 gateway would have to be provided - and could be provided to a high quality (see paper by Steve Kille), there was little advantage in encouraging X.400 over RSCS. Moreover, such a procedure would demand the provision of X.400 to RFC822 gateways within the current EARN network and this could increase traffic to no advantage and be a source of failure.
The discussion also suggested that nothing other than an X.400 to RFC822 gateway need be provided as all sites are capable of producing RFC822 mail even though this may be by means of a 'raw' editor. The IBM NOTE protocol is unsuitable for use with a gateway since it is unable to carry sufficient address information.
Gateways to UUCP, QZ, EUROKOM, Grey Book, and possibly others are desirable but the group did not feel that these were so important and would probably be provided by specialist sites or by double gatewaying.
It is gratifying that all known X.400 implementations aim to follow the CEN/CENELEC functional standard.
The group did not see how it could undertake a conformance test for the Heidelberg system. They thought that it would be more profitable to undertake interworking tests with other systems. These would give a high measure of confidence and would also isolate major faults rather than trivial ones.
A few comparisons of the time it took a message to pass across X.400 and across RSCS give some cause for concern. This is a complex issue as it involves the performance of a computer system and the performance of the network. Some further test will be run.
The final day set out the chapter headings for the report and who would write them. This is being distributed separately.
The requirements for the report also defined the work still needed and this is in the draft report.
On its own the Heidelberg system can not be used for migration. The principle problem is that X.400 is not suitable for file transfer and job transfer.
To be more specific, if X.400 is used for file transfer then the user would have to strip off the X.400 headings before use. If the file were a job then systems would have to be provided to do this automatically. One can expect that systems may also have problems returning job output. Although X.400 should be capable of transferring 8 bit bytes unchanged it is unclear whether the Heidelberg system could work in this mode.
Thus migration requires FTAM.
Migration would also cause the loss of 'messaging' but provide interactive services. Study of these aspects is outside the scope of the group.
The group is now fairly confident that in a migrated network the Heidelberg system could provide the mail system requirements for VM/CMS systems.
Any future work must depend on the exact migration strategy adopted by EARN. If an X.25 infrastructure is set up then the Heidelberg system could be of immediate use. If migration follows some other path then this may not be true. For example, a migration via SNA and IBM proprietary protocols would not seem to provide an early, if any, role for the system.
There are many sites which already have X.25 connections. In these cases it could be advantageous to encourage the use of the system towards the middle of 1987 when it will be more mature and with good documentation. This will be even more attractive if the system will operate over a 3725.
This document proposes text changes to Y/11 Y/12 to meet the CEPT concern that Y/11 Y/12 will cause current PADs to be non conformant to the functional standard.
NOTE, the proposed change will still prohibit PADs that do not conform to CCITT recommendations or which make some extensions to them to conform.
The proposal is to define for a PAD two classes of conformance-
"Basic" conformance coupled with conformance to CCITT 1980 implies that only the mandatory parameters and the optional parameters associated with them to be provided.
"Basic" conformance coupled with conformance to CCITT 1984 is different in that it requires all the parameters to be provide but only requires the parameter values demanded by the use of the sub-options.
The two meanings of "basic" may be confusing.
"Full" conformance with CCITT 1980 implies that all the 1980 parameters must be provided and all optional parameter values required to support all the sub-option.
"Full" in the case of 1984 implies that all parameters and all optional parameter values must be supported.
Again the different use of "full" may be confusing.
Page 12 section 6.1. Replace final 3 paragraphs by-
"The Y/11 profile for a packet mode DTE requires conformance to one or more of sub-options 1, 2, 3, 4, and 5. In addition the packet mode DTE shall conform to either sub-option 1 or sub-option 2 (see 6.2).
A PAD conforming to Y/11 shall claim either 'basic' or 'full' conformance (see 6.6)
A conformance claim for a packet mode DTE shall state:
a) the options and sub-options offered
b) the line speed range(s) offered
c) the X.25 packet level user facilities marked as optional in Table 2 and which are offered
d) which of X.21, X.21 bis, V.24, and V.35 are offered
e) the character set(s) offered (see ).
A conformance claim for a PAD shall state:
a) the options offered
b) the line speed range(s) offered
c) the X.25 packet level user facilities marked as optional in Table 2 and which are offered
d) which of X.21, X.21 bis, V.24, and V.35 are offered
e) the character set(s) offered (see )
f) whether basic or full conformance is offered. "
Page 17 section 6.6. Replace first paragraph-
"A PAD claiming basic conformance need only support all mandatory parameters and all the mandatory parameter values for them as specified in CCITT Recommendations X.3 (1980).
A PAD offering option 1 and claiming basic conformance shall support all additional parameters as specified in CCITT Recommendations X.3 (1984). In addition parameter 4 shall support the value 1 and parameters 16, 17, and 18 shall support values 0 to 127.
A PAD claiming full conformance shall support all additional parameters as specified in CCITT Recommendation X.3 (1980). In addition parameter 4 shall support the value 1 and parameter 16, 17, and 18 shall support values 0 to 127.
A PAD offering option 1 and claiming full conformance shall support all additional parameters and all optional parameter values as specified in CCITT Recommendations X.3 (1984).
Notwithstanding the above statements a PAD shall support at least one value of parameter 11 of 0 to 18.
Parameters and parameter values not defined in the CCITT Recommendations X.3 (1984) shall not be provided.
The provision of parameters and parameter values not demanded by the option offered or my conformance to basic or full conformance shall not invalidate conformance. "
Insert new penultimate paragraph to A1-
"The concepts of "basic" and "full" conformance for PADs has been introduced to allow many existing PADs to conform. With the CCITT Recommendations X.3 (1980), basic conformance only demands that the mandatory parameters and mandatory parameter values are provided. This will only guarantee that a packet mode DTE will be able to use sub-option 1 or sub-option 2 and so provide a lower level of functionality. Full conformance with the CCITT Recommendation X.3 (1980) and basic or full conformance with CCITT Recommendations X.3 (1984) will allow any of the sub-options to be used. The scheme has been adopted since equipment based on the CCITT Recommendations (1980) is expected to be phased out in the near future with that based on the newer Recommendations and it is not justified to encourage the upgrading of this equipment in any substantial way. However, there is a strong encouragement for equipment based on the CCITT Recommendations (1984) to offer a high level of functionality. "
Add paragraph to A16.
"Interworking with a PAD not offering option 1 and offering basic conformance may be limited to using sub-option 1 or sub-option 2. "
The International Standards Organization have produced the Open Systems Interconnection communications protocols. It has now become clear, that since these protocols contain many options and since the various protocols can be put together in many ways, that any two implementations are unlikely to interwork well if at all. Recognizing this problem various groups have started to produce functional standards which define how a set of protocols should be used to provide some specific function over some specific network technology. Adherence to such functional standards will ensure successful interworking between implementations from various sources. The development of functional standards is well advanced in Europe and are starting to be used in implementations and procurement activities.
After reading mathematics at Southampton University, Paul Bryant started his life in computing at AERE Harwell. He joined Rutherford Laboratory in 1965. In the 1970s he worked with many early communications systems to provide remote access facilities for academics. This led to the SERC X.25 network which was one of the first extensive X.25 networks being started in 1978. Since then he has worked on many aspects of networking in the academic world both in the wide and local areas.
There is a fundamental difference between the communications protocols developed by the International Standards Organization (ISO) and the proprietary ones developed by manufacturers, such as DECNET and SNA.
In the proprietary case protocols have been developed to match the equipment and the systems of the manufacturer and his customers. Thus, interworking is not a problem since the design and implementation of everything is under the control of a single organization. In the last analysis changes can be made to overcome difficulties that arise. Also arbitrary changes and extensions can be made by the manufacturer to meet new needs or disadvantage competitors. It may be that such protocols are not published to allow any competition.
In the ISO case protocols have been developed to meet the needs of a wide range of activities, some complex some simple. This has led to such protocols having a number of options and in general only a subset of such options would be available in any implementation. Unless implementations use the same options from a protocol they may not interwork. Thus, although the protocols may be stable this does not guarantee interworking.
The ISO protocols have a layered structure and in principle it should be possible to take a protocol from each layer, put them together to form a stack and so provide a specific application over some technology. This is not easy as there are dependencies between layers. In addition there are a very large number of ways of making a protocols stack and unless other suppliers use the same stacks interworking is unlikely.
Functional standards are aimed at overcoming these problems by defining what options shall be used and which protocols used in various situations. Thus, it is possible for two independent implementors to take a functional standard, implement it, and be certain that their products will interwork.
It must be noted that functional standards do not alter the underlying ISO standards or CCITT recommendations (known as base standards). They do not extend the base standards except where there is a severe problem and even then the aim would be to bring such deficiencies to the attention of ISO.
There are two byproducts of functional standards.
The first by-product is that the customer should be able to use a functional standard in procurement and therefore ensure that the set of products from various suppliers will interwork. Currently the customer has to study specifications from suppliers very carefully and possible negotiate with them for various changes. This is expensive, takes valuable expertise, and is liable to error.
The second by-product is that it is possible to undertake conformance testing against a functional standard for products. Thus a customer can have a guarantee that products will interwork and on non interworking action can legitimately be taken against a supplier to force a product to conform appropriately.
Whilst the use of functional standards for procurement and conformance testing may harm some suppliers who provide sub standard equipment those who comply and the users will be benefited.
Europe has special needs for functional standards.
Europe has a large number of computer manufacturers and there are clear indications that divided they are likely to make little impact on the world but together they should have better success. Although communications is only one part of the collaborations between them, it is probably one of the most important as it allows consortiums of manufacturers to bit for contracts.
The European Computer Manufacturers Association (ECMA) has long recognized the benefits of standards and been active in promoting European computing standards. They are no less active in their support of functional ones.
The European Community is anxious to promote trade within Europe. In computing this demands that standards are used throughout the community. Procurement within the Commission is another reason for functional standards support.
Europe has provided much of the support for ISO standards and it is natural for them to continue this interest into the implementation phase.
The first activity was called the Zander initiative in 1983. Professor Zander of the Hahn-Mietner institute in Berlin set up an activity to harmonize the use of protocols for academic use within the German academic network DFN. This was adopted by the European Commission and led to a series of meetings that produced the COS (Common use of OSI Standards) documents which were, in fact, probably the first functional standards although at that time the concept had not been developed. Four documents were produced:-
COS1 - Connection mode network layer COS2 - Transport layer COS3 - Local area networks COS4 - X.3, X.28, and X.29
ECMA became interested in the work and set up SPAG (Support of Protocols Applications Group). They produced the GUS (Guide to Use of Standards) document. The principle importance of the GUS was that it defined function standards and gave a classification for them which has been a great help in subsequent work.
The subsequent stage which started in 1985 was a joint agreement between CEN/CENELEC, the European standards organization, and CEPT, the advisory body for the European PTTs. The agreement was to produce functional standards and publish them as European pre-standards. These are known as ENVs. The initiative was from the European Commission. The document defining the agreement is known as HD 40001.
The final stage is the encouragement for ISO itself to initiate an activity. At this time the ISO work is in its preliminary stages but indications are that it will succeed.
The European groups are not the only ones to recognize the importance of functional standards.
The MAP project, initiated by General Motors, is in part a functional standards activity applied to the manufacturing area. General Motors were concerned that they had a large number of different systems controlling parts of their plants. They concluded that if their suppliers could be persuaded to produce products which could interface to a 'standard' network then there would be substantial cost savings and in addition equipment changes could be far simpler to undertake. They recognized that they needed standards and decided to adopt the ISO ones as far as possible and to produce functional standards and to apply then in their particular area. They took the work a lot further in making their suppliers conform to the standards and as they are a major procurer this had a strong impact. Since the inception of MAP many other organizations have joined the activity is supplying products and demanding products.
The TOP project, initiated by Boeing, is a similar one in office automation. So far this has not developed to the same extent. The potential benefits are very great since customers are now only too aware of the problems of interconnection after their experiences of the first generations of electronic office equipment which demanded proprietary network products and locked the customers into specific manufacturers products.
Recently the COS (cooperation in open systems) organization has been set up in the States which is the counterpart of SPAG. It is composed of manufacturers who are principally interested in the production of equipment and ensuring that their equipment is capable of interworking.
The counterpart of the CEN/CENELEC/CEPT work is the NBS (National Bureau of Standards) Open Systems Workshop. Although the basis of working is rather different the aim is the same. They have adopted a rather more informal method of working which has both benefits and drawbacks.
There is also activity is Japan and, no doubt, in other countries.
With all the various activities going on it is important that world wide functional standards are agreed rather than European, manufacturer, or any other sectional ones. None the less, the work currently going on is important to develop the initial input to ISO. It must be added that there is considerable cross membership between the various organizations and a desire to harmonize the various activities. The desire is very strong from the manufacturers who want to produce single products to satisfy all customers. The customers have a strong desire to be free to choose equipment from a world wide pool of products.
CEN/CENELEC was set up by the European Commission and is controlled by the Senior Officers Group for Information Technology Standards or (SOGITS) as far as functional standards are concerned. The next level of control comes from the Information Technology STeering Committee (ITSTC) which has representatives from both CEN/CENELEC and CEPT. This committee is responsible for the political direction of the exercise. At the next level there is the Information Technology Ad hoc Experts Group (ITEAGS). This group supervises the technical work of the working groups. It is manned by the chairmen of the working groups plus a few technical experts. It is here that the work items are proposed and progress charted. At the bottom level are the working groups themselves.
There is a memorandum issued by CEN/CENELEC known as M-IT- 01 which defines carefully the scope of the functional standards activity. The definitions of the specific functional standards is in a further memorandum known as M-IT-02. This has a supplement which defines how far the project has progressed and defines the future work items.
The working groups are of two types. The first are run by CEN/CENELEC and have observers from CEPT. Their output is eventually voted on by the members of CEN/CENELEC, that is the standards organizations of Europe such as AFNOR, DIN, and BSI. This is known as procedure A. The second are run by CEPT and have observers from CEN/CENELEC. They use the normal procedures for producing documents within CEPT. This is known as procedure B.
It has been found that on some occasions there has been disagreements between the two organizations on the output from groups. This has been overcome by having joint working meetings from time to time which seem to be able to resolve problems with a fair degree of ease.
A further group known as ITAEGM (Information Technology Ad hoc Experts Group in Manufacturing) has been set up which is like ITAEGS but deals with the use of ISO standards in manufacturing
There is a further group set up to consider conformance testing but this is under CENCER, the CEN certification organization. They are setting up testing centres but is it unclear when these will be operational and what products will be certifiable.
The GUS has split functional standards between transport and session levels. Thus the upper levels are to some extent separate from the lower ones. There is some discussion as to whether the split would be better made above network layer. It must be mentioned that the split was made in good faith some time ago and on mature thought the split at network layer does have some advantages but for this exercise it would be too late to modify the work already done.
Functional standards are classified into four groups:-
A - The A group is the application sets which would typically be a combination of an application protocol, a presentation protocol, and a session protocol. Naturally there is a functional standard for each application such as MHS, FTAM, and JTP. In some cases there is more than one functional standard reflecting different uses of the protocol - for example in FTAM there is one for file transfer and one for file access activities.
C- The C group is the combined one which covers both the upper and lower protocol layers and typical examples are facsimile or teletex over the switched public telephone network. In these cases there is no means of making a sensible split in the layers.
Q- The Q group is the applications extension functions which cover items such as document formats and other aspects of displaying text.
R- The R group are relay functions which define how connections between networks should take place. This covers LAN to WAN and connection to connectionless activities.
S- The S group are character and control repertoire specifications. These are particularly important in Europe with the various and slightly different character needs in the countries.
T - The T group is the telecommunications set which would typically be a combination of all the protocols below and including transport. In this area there is certainly a functional standards for each technology, such as X.25 and CSMA/CD. In addition with some technologies there may be connection or connectionless services which give rise to different functional standards.
Y - The Y group is for the protocols which do not fit into the ISO model. The principle one is the use of X.3, X.28, and X.29 over X.25. Since there is no transport service and there is interaction between X.25 and X.29 (the Q bit) it is difficult to classify it as T or A.
A particular functional standard is defined by its group letter followed by 2 or three digits. The details can be seen in the GUS document or in M-IT-02 which defines the functional standards being worked on in CEN/CENELEC/CEPT.
With the limited resources available the functional standards works is being phased.
The first phase includes the most popular activities which broadly covers X.25, CSMA/CD, and MHS. This will provide about 13 functional standards and this work is largely complete.
The second phase is now in progress. This brings in such topics as FTAM and the token ring. This will add 20 functional standards.
The third phase is now being planned and is tackling other aspects of the standards of lesser interest or of a more advanced nature. This will add about another 20 documents.
Perhaps the most important functional standard is for message handling (MHS, MOTIS, or X.400). This is particularly appropriate and timely as the PTTs are expected to produce services in this area very shortly.
The functional standard is also important for manufactures and customers wanting mail systems in the near future. The European academic community is expecting to promote such services very shortly as a start towards the provision of a uniform networking infrastructure for the community.
There are also plans in many other areas to undertake similar exercises.
It is too early to assess the success of the functional standards but in retrospect it is difficult to imagine how services could be provided without them as each customer would have to make his own requirements and attempt to obtain equipment. It would have been impossible for a manufacturer to meet all this possibly different requirements.
It is to be hoped that with the increasing interest of ISO the concept of functional standards can be put on a firm basis and provide more authoritative documents which can be valid world wide.
The following functional standards are now complete:
A/3211 Message handling system - user agent and message
transfer agent for private message domains.
T/6211 Connectionless network service for a single CSMA/CD local area network.
T/6212 Connectionless network service for multiple CSMA/CD local area networks.
Q/214 Character coded text for word processors.
The following functional standards are almost complete:
A/221 Basic teletex.
A/311 Message handling system - user agent and message transfer
agent for public message domains.
T/31 Public switched data network - permanent access for connection
network service.
T/321 Public switched data network - switched access via telegraph circuit.
T/322 Public switched data network - switched access via digital data circuit.
T/41 Digital data circuit - T.70 case.
T/421 Permanent circuit - connection network service case.
T/422 Switched circuit - connection network service case.
Q/211 Character coded text - telex.
Q/213 Character coded text - teletex.
Y/11 X.29 over X.25.
Y/12 X.28 public switched data network character mode access.
Work is in progress in the following areas:
Teletex Facsimile Connectionless network service CSMA/CD Connection network service Token ring Character codes
Work is expected in the following areas:
File transfer - several functional standards. Further work on message handling. Further character codes. Connection network service token ring.
There is now little doubt that functional standards are vital for success in the provision of ISO networking products. The hope is that the current and various world wide efforts can eventually be harmonized through ISO to provide a stable agreed set of functional standards. The work is well supported by both the customers and the manufacturers.
Temporary note - This is the second draft. Feel free to suggest any changes. Paul.
H Berg-Hoff RUNIT Norway P Bryant Rutherford UK H Goosens Nijmegen Holland N Gunadhi Rutherford UK O Martin CERN Switzerland G Pittiloud Zurich Switzerland
Note: In the interests of consistency International Standards Organization terminology is used. Appendix ? shows the equivalences between the ISO standards and the CCITT recommendations involved. The generic terms Message Handling System (MHS), Message Oriented Text Interchange System (MOTIS), and X.400 are all applied loosely to the same systems. The confusion is caused by the X.400 set of recommendations having been adopted by ISO and redrafted appropriately.
Temporary note- Is it best to stick to ISO terminology as stated above?
CEPT requires EARN to migrate to the use of the International Standards Organization (ISO) Open Systems Interconnection (OSI) protocols by the end of 1987.
As a result of this requirement an investigation was held in 1985 to identify any systems which could used in the migration. In July 1985 a technical meeting in Heidelberg considered that the MHS system being produced at the European Network Centre (ENC) of IBM appeared to hold greatest promise. A proposal was made to IBM for support to evaluate the system and this was accepted.
The participating organizations were:-
Rutherford Laboratory UK RUNIT Norway University College Dublin Ireland Zurich University Switzerland Montpelier France Stockholm University Sweden Nijmegen University Holland CERN Switzerland
Temporary note- Shall we include our names- please correct your site names.
Organizations taking a close interest in the study were:-
Pisa University Italy Berlin University West Germany
Due to unforeseen circumstances Ireland and Sweden were unable to continue their participation.
Temporary note- Shall we leave in references to Ireland, Sweden, Pisa, and Berlin?
The first project meeting was held in Heidelberg on 7/11 April 1986 when tapes containing the system were distributed to the participants.
The second project meeting was held in Zurich on 4/5 December 1986.
It had been expected that the evaluation would take 6 months but there were delays due to the provision of the Series 1 computers required.
During the course of the work the system was improved by the ENC particularly at the end of 1986. The delays were therefore useful in allowing the evaluation of a significantly improved system.
EARN would like to record its thanks to IBM for providing access to the MHS system, for the technical help provided, for equipment, and for the financial help which made the study possible.
The ISO OSI protocols have been developed over the last few years to meet the needs of suppliers and customers wishing to provide network services between heterogeneous systems.
Although the protocols are at various stages of development there is now sufficient stability in a number of areas to allow systems to be developed in the areas of interest to EARN. The rough equivalence between the current EARN protocols and the ISO ones is:-
SERVICE EARN ISO File Transfer Network Job Entry FTAM Mail RFC822 MHS Messaging Messaging No current equivalent Low level Network Job Entry ISO 8208, 7776 etc.
The equivalences are not close. The ISO standards involved in each of the services can be found in appendix ? FTAM is the generic name for the ISO File Transfer, Access, and Management set of standards.
At the time the project was started there were no implementations of FTAM. There is a version of FTAM being developed at Salford University and a brief description is given in appendix ?
The system produced by the ENC provides all seven ISO protocol layers for supporting an MHS service. A number of the layers, particularly at the lower levels, are provided by IBM products. Some parts, particularly to do with the user agent, are developed from, or based on, IBM products such as PROFS and NOTE. Other parts have been produced by the ENC sometimes in conjunction with (?).
Temporary note- Was it Darmstadt? And if so which bit?
The system can be split into n major components.
Heidi's bit.
This chapter gives a general view of the installation of the system and describes the difficulties in making it operational. Possible enhancements or solutions are also presented.
The code needed by the HD product is composed of two equal portions in respect to the effort and expertise needed for its installation:
Depending on the country, the Series/1 interfaces the national X.25 public network by one of three types of connector (V.24, V.35, or X.21) and two types of adapter (#2090 for low speed and #2080 for high speed). The adapter for which the code was developed in HD is no longer available (#1067). As there are a variety of hardware combinations, great care should be exercised at the time of ordering.
In the HD generated system the driver support for the new adapters is missing. Thus a complete system generation and customization of the RPS system was needed. Note that the delivered pre-generated system does not include X.25 support. The required system generation took two weeks (at two sites). The general feeling of the group was that this represented a disproportional effort compared to the number of lines coded on the Series/1.
After generating the Series/1 the system has to be customized to the particular X.25 network. This can simply be done by a utility delivered with the X.25 RPS support. For this delicate operation the assistance of an X.25 specialist is indispensable. The operation determines the DCE/DTE relationship, the logical circuits, packet size, window size, and so on. A special problem can arise with the number of logical circuits subscribed to: the HD application program was assembled for four virtual circuits and if more than four are provided by the PTT then the code has to be reassembled.
Support for the 370 channel interface must also be generated, but there are no particular difficulties in this operation.
In Zurich, a system supporting all three types of adapters was generated and backed up on 29 double density diskettes.
The two adapters #2090 and #2080 were successfully tested. An interface cable connecting an X.21 to a V.24 interface was developed.
The same system was installed at CERN by restoring in stand-alone mode the the one generated at Zurich from the diskettes. This took one hour. Two patches were needed to take account of the adapters on the CERN system. It seems that this mode of installation is much faster than regenerating the system and could be applied to new sites. This assumes that the new sites possess the same disk type (4963) and a double density diskette drive. It reduces to an absolute minimum the expertise needed for RPS.
An easier solution, which was not tested, would be to generate a minimal diskette based system and distribute it with the corresponding patch documentation. In this case the expertise needed is practically zero, also, the intervention possibilities of the system are reduced: the behavior of the system in a real production environment should be carefully tested before this type of distribution procedure can be promoted.
A third variant, which consists of distributing the customized nucleus, is being tested with a new installation in Stuttgart. Here one can affirm in advance, that the RPS expertise needed is not to be neglected.
The conclusion reached is that an easy and straight forward scheme for setting up the system in the Series/1 is essential as few EARN sites have RPS expertise.
The code operating in the VM host is executed in four coupled virtual machines:
The expertise needed is that of the usual VM systems programmer.
The TLVM did not present much difficulties at installation and revealed itself to be quite stable in operation, except after restart situations on the Series/1 or the host. Restarts of the Series/1 or the host applications have led to resynchronisation failures on the channel protocol.
The sequence in which the host and the Series/1 applications are started is rather tricky for a normal operator. A restart or re-ipl of the Series/1 would improve significantly this handling.
The RTSVM is more complex as it interfaces to the three other machines. There was no difficulty in interworking with the TLVM, once the TSAPs were defined, however in operation there were difficulties in connecting to other sites, the interpretation of the log entries proved to be confusing and not sufficiently documented.
The relationship of RTSVM to both RIOVM and MTA is not clear due to lack of documentation (from a system programmers point of view). Special care has to be given to the access and links definition to its neighbour's disk. The greatest difficulties encountered at installation time were in searching for the correct access types, link virtual addresses hidden in the code, and correct IUCV setup.
The handling of partly duplicated routing tables and directories for RIOVM, RTSVM, and MTA is an area ripe for enhancement. The recently announced unified console interface for all four virtual machines will ease the difficulties with dealing with several consoles.
Some bugs were found and documented for the MTA.
In particular, a communication problem between the MTA and the RTSVM was understood after a study of the MTA interface source code. This event clearly demonstrated that the absence of the source code inhibited an efficient cooperation with the ENC.
In conclusion, should the HD product be adopted by EARN for the X.400 migration, its distribution should be enhanced and coordinated in order to remove the need for Series/1 and RPS expertise at each site. The installation of the host software does not represent a major difficulty. The proposed enhancements mentioned above are easy to implement and the VM expertise is, in most cases, already in existence at each VM site.
Girard's part.
compare with RFC822/RSCS to X.400/X.25 - more or less expensive?
Hans's section
Never gave a problem
Needed reloading every so often.
Hans does this bit.
Needs far too many.
This bit or that needs attention now and again.
Hans again.
Heidi
It is important that the Heidelberg system should be capable of interworking with other systems in the community.
The correct approach to ensuring interoperability would be to perform conformance tests with the function standard laid down by CEN/CENELEC and CEPT. It is expected that all systems in the European Academic community will conform to this functional standard.
Unfortunately there are no test facilitates available and the group felt unable to undertake any work of this type. An alternative approach was taken to test the system against as many other systems as possible. This would give a good measure of confidence on the practical aspects of interworking.
It has become apparent that ISO standards are insufficient to ensure that systems can interwork. ISO standards allow any options. There are also often several protocols at any level, particularly at the lower ones. This problem is being overcome by the provision of functional standards which define the options to be provided in each protocol and the allowed 'stacks' of protocols. The protocol stack is split between level 4 (transport) and level 5 (session). In general any 'application' or A functional standard (encompassing layers 5, 6, and 7) should operate over any 'telecommunications' or T functional standard (encompassing layers 1, 2, 3, and 4). CEN/CENELEC, the European standards organization, and CEPT, the European PTT advisory organization, are producing relevant functional standards. It is hoped that ISO will undertake the production of functional standards in the future to ensure common ones across the world.
The CEN/CENELEC/CEPT functional standards of interest are:-
ENV 41 201 Private Message Handling System, also known as A/3211
ENV 41 104 Requirements for dedicated packet mode access to a Packet
Switched Public Data Network for OSI, also known as T/31.
Problems of the early system - improvements seen.
Heidi.
Importance of good user interface - desire for something like MAIL.
Your part Olivier.
Note improvements outlined this month. Need to have an easy to mount system for wide use - how far do we have it. System developing.
3725 possibilities and advantages.
Paul
Paul
The problem of national character sets in EARN is actually not satisfactory. The reason is that, in general, the mail/sendfile utilities do not consider the type of character set in use at the originating site. In fact there is no indication in the message header or in the network records of the charter set in use.
However no restrictions are placed on the context of a message file and all 256 possible bytes are allowed.
Nodes of the same type (e.g. two VM sites in Germany) may exchange mail and text files without loss of character rendition, but in general there can be no guarantee that this is the case. As soon as a country boundary is crossed, the character set commonly used may change. For example, 'dollar' becomes ' cent' and 'pound' becomes 'dollar'. It is up to the user to deal with the received file and attempt to map it into a suitable graphic form.
Between machines with different character codes (e.g. VM and VMS) the problem may become more acute as a translation between EBCDIC and ascii is performed. In general, for mail, this translation is one to one, i.e. a translation from EBCDIC to 8 bit ASCII extended is performed, and no character code is lost. If the translation is not one to one, the operation becomes rather tricky and involves the cooperation of both the sender and the receiver. The first has to pack the data in a transparent format (see below) and the last has to receive it in this form and apply its own EBCDIC to ASCII translation. In any case and for the same reasons as above it is up to the recipient to perform the particular translations required.
Gatewayed mail is not directly effected by this problem, the character set being clearly restricted to ASCII (RFC822).
Files can be conveyed transparently in EARN using NETDATA format or DISKDUMP format class N. As far as is known this gives a good quality of service on the majority of systems, i.e. VAX JNET, IBM VM, and IBM MVS.
X.400 related situation:
With the X.400 migration of EARN, the support of national character sets will not be improved significantly, at least initially. Additionally the transfer of trabsparent files will not be supported unless ad-hoc solutions are found to imbed such files in X.400 or until FTAM is introduced.
Constraints on character sets as defined in the recommendations for MHS/IPM can be grouped into two classes according to their impact on the EARN migration:
In the first group the fields Subject and ORDescriptor freeformName are defined as T61Strings, IPMessageId and ORName (standard and domain defined attributes) as printable strings. No other options are allowed and the standard has to be followed. Also no major difficulties are expected, at most modification of the user identification at some site could be necessary. (e.g. userids containing the characters $, @, or # are not valid printable strings).
For the Bodypart of the message the possible types already defined and related to EARN problems are:
In the future SinpleFormattedDocument, TIFO, TLX,...will also play a role.
It is likely that the first implementation of X.400 will support only IA%Text: strictly speaking, the character set will be an alias subset of ASCII with optional character allocation (e.g. pound/number signs, dollar/currency signs) or an ambiguous mixture of national or application-oriented versions of the basic IA5 set, the sets being based on sender-recipients agreements. The salad continues!!!!
Even the attempt of some implementators to use ANSI ASCII instead of IA5 will not help solve the problem in a general way.
With TTX type Bodypart using the primary and supplementary set of graphic characters of T.61, most of the national European diacritical characters (is it necessary to mention "European") would be covered. By allocating the empty positions of the primary set of graphic characters of T.61 to their equivalent in the International Reference Version (T.50) one could have some chance to realize a more consistent solution: identify uniquely almost all the characters which can be typed in on the ASCII and EBCDIC (3270) keyboards based on the Latin alphabet. Currently the Queen's User Agent and EAN support only IA5 (ASCII ?), NOTE$)) and the gateway software of HD, IA5 and TTX.
For the transfer of transparent files neither IA5 nor TTX are suitable. There is therefore a strong need to find a interim solution (before FTAM) in order not to disrupt the file transfer service actually in use in EARN. Or at least between machines of the same type such as two IBM VM services.
Two solutions are possible:
In any case, file information like dataset name, record format, irecl,... has to be transmitted in order to allow its reconstruction by the recipient. Additionally the corresponding utilities to pack, send, and receive the files have to be developed and eventually integrated in the User Agent. The widespread format NETDATA may be eligible for this task, it is currently supported on the majority of the EARN/BITNET sites.
In conclusion, one can hope for a solution to the national character set problem can be encouraging the implementation of TTX in IPM and for transparent file transfer as an interim solution before FTAM is needed.
?
Paul
The equivalence between ISO standards and CCITT recommendations. Note that there are differences in text between ISO standards and CCITT recommendations and in some cases difference in content.
ISO CCITT ISO name
646 T.50 Information Processing - ISO 7 bit Code Character Set
for information Exchange
3166 none Codes for the representation of the names of countries
6937 Coded Character Set for Text Communication parts 1, 2, and 3.
7776 X.25 Information Processing Systems - Data Communications - HDLC -
Description of the X.25 LAPB compatible DTE single link procedure.
8072 X.214 Information Processing Systems - Open Systems Interconnection
Transport Service Definition.
8073 X.224 Information Processing Systems - Open Systems Interconnection
Transport Protocol Specification.
8208 X.25 Information Processing Systems - Data Communications -
X.25 Packet Level Protocol for DTE.
8326 X.215 Information Processing Systems - Open Systems
Interconnection - Basic Connection Oriented Session Service Definition
8327 X.225 Information Processing Systems - Open Systems Interconnection -
Basic Connection Oriented Session Protocol Specification.
8348 X.213 Information Processing Systems - Data Communications -
Network Service definition.
8878 X.25 Use of X.25 to provide the ISO Connection-mode Network Service.
8505 none Information Processing Systems - Open Systems Interconnection -
Description and Service Specification for Message Oriented Text
Interchange Systems.
8883 X.411 Information Processing - Message Oriented Text Interchange System -
Message Transfer Sub-Layer, Message Interchange Service and Message Transfer Protocol
9065 X.420 Information Processing - Message Oriented Text Interchange System -
Interpersonal Messaging User Agent Sub-Layer, Message Interchange Formats and Protocols.
9066 X.410 Information Processing - Text Communication Message Information Processing -
Text Communication Message Oriented Text Interchange System - Reliable Transfer Server and Use of Presentation and Session Service.
Present: B Davies (Chairman) P Bryant (Secretary) M Hapgood G&R M W Johnson SNS R Cooper JNT J Sherman S&A R E Thomas ID T Daniels CCD W Turner Admin Apologies: W Pulford SNS J Hutton HEP
M Hapgood was present at meeting 6.
Section 1 - for 'nor' read 'not'.
M5.5.1 The action to provide the 'NRS site responsibility' paper on P Linington is moved to R Cooper.
M5.2.1 The Daresbury PAD document has been obtained. T Daniels observed that the so called PAD problems has vanished when the guide was issued there. The Daresbury document will be reviewed and maybe issued. It will be circulated to RCCC and passed to VSM for their consideration. Action: T Daniels
M6.2.2 All the ASYNC 3270 services of interest to users on site are now in the PADs tables.
M6.3.1 The drafts of policy documents have been circulated and are considered below.
M6.4.1 The TELEX service has now been properly installed and a service is being provided.
M6.4.2 The provision of a TELEX Grey Book service via the SYSTEL code has not yet been progressed. Retain.
M6.7.1 A further discussion was held on the mail addresses published on circulars and the views expressed were that these mail addresses should include the Grey Book one. W Turner will discuss with K Jeffrey. Action: W Turner
The technical detail in this paper should be kept small.
It was decided to produce a document on 'New Science Driven Requirements'. In put will be sent to T Daniels by M Johnson, M Hapgood. Action: M Johnson, M Hapgood
R E Thomas noted that in ID there was a heavy use of servers on ether nets. He wanted to know whether CCD were interested in such provisions.
It was conformed that NDM is the technical arm of RCCC.
It was stated that it was not RCCC's role to dictate the standards and policy on site networking.
It was noted that there was a problem of the boundaries of RCCC'S responsibilities in divisions. It seemed that the boundary depended on local circumstances.
In section 2 it was felt that CCD should be responsible for mail, access to JANET, a backbone LAN, the protocols on the backbone, and access to other networks.
R E Thomas noted that the word 'proprietary' should only be applied to the proprietary protocols of manufacturers and not the non proprietary and non ISO protocols such as TCP/IP.
The concept of the 'village' was defined which is a community of users which may be part of a division or may encompass users in a number of divisions. These should be considered as local communities which would have intimate network connections between the users.
The provision of SSMP was considered and CCD and JNT reported that it was intended to provide it on several machines and work stations. It was unclear yet how well an SSMP service would be received by the community. A paper defining the state of implementations on various machines will be circulated. Action: R Cooper
The provision of a reliable 2400 dial up service is regarded as a concern. P Bryant reported that effort is going into solving the admittedly unsatisfactory situation.
A number other points were raised.
The Network Executive is evaluating a high speed PAD.
JTMP is well advanced on the IBM machine and there is some confidence that a service will be available on time.
The expected closure of RLGB is a concern to CCD in respect of the MAIL service provided. CCD has a student attempting to provide similar facilities on the IBM.
It was agreed that monitoring of the network was non-existent due to lack of effort. This is agreed to be a concern.
The poor integration of PROFs with the Coloured Book network was a concern and seems to be leading to a split community as far as mail is concerned.
It was agreed that terminal access, Mail, and the provision of a backbone network were priority areas.
P Bryant reported that a series of meetings were being held with suppliers to explore ideas for the provision of a backbone LAN. So far DEC and Bridge had given presentations and one form ITL is expected. A proposal will be produced by the end of the first quarter. All divisions have been invited to attend the meetings and any paper will be agreed by the group, NDM, and then presented to RCCC.
CCD and HEP have a project to provide an ethernet connection between a VAX and an IBM using JNT approved methods. This is an experimental exercise. The Spider PAD is expended to be evaluated. Results should start to become available at the end of the first quarter. ULCC is cooperating in the project.
Monday 30 March 1987 at 9.00
None.
M5.5.1 Provide 'NRS site responsibility paper. R Cooper
M5.2.1 Review Daresbury PAD guide and possibly
issue. T Daniels
M6.4.1 Provision of a TELEX Grey Book service via
the SYSTEL code. ?
M6.7.1 Discuss mail addresses in printer documents
with K Jeffrey. W Turner
M7.3.1 Provide document on 'new science driven
requirements' for networks for T Daniels. M Johnson
M Hapgood
M7.3.2 Provide paper on state of implementation of
SSMP on various machines. R Cooper