JPALME@qz.qz.se (Jacob Palme QZ) (08/02/90)
Notes from the ISO/CCITT joint meeting on messaging, Munich, July 1990. ====================================================================== The future development on message handling standards (X.400, Motis etc.) is now handled by a joint ISO/CCITT group. This group had its third meeting in Munich in July 1990. Here are my personal notes on what was done at this meeting. The notes are *not* official minutes of the meeting. When I in this report say that the meeting "was of the opinion" or "decided" this in most cases does not mean any final decision. Standards making involves many meetings over a period of several years, where "decisions" made at one meeting can be re-opened again at the next meeting, until a final usually unanimous opinion is reached. General enhancements group -------------------------- An important issue in this group is a standard for an international store-and-forward facsimili service. Such a service is useful especially when a sender wants to send a facsimili to several recipients in other countries. The intention is to develop a standard for this based on the X.400 messaging standard. Some enhancements to X.400 are desirable for facsimili handling in the area of delivery and non- delivery notifications. Since there is at present no extension mechanism for notifications, the group suggested such a mechanism. (The idea with an extension mechanism is that when there is such a mechanism, older systems which do not know of an extended feature will not break down when receiving a message, or in this case a notification containing extended fields.) The group also suggested a field in the envelope to indicate whether the content is a notification or a message. This is useful for charging, since often, the sender pays for a message, but the recipient of the notification pays for the notification. The group also discussed a mechanism for allowing a message to be charged to the recipient, somewhat similar to reverse- charge telephone calls. An example of the use of this is the sending of an electronic newspaper, for which the recipient pays. This mechanism will be based on the EDI feature of X.400, with the sending of EDI messages between PTT-s with information about charging. A proposal to add a new heading-attribute on messages with the name "auto-submitted mark" was accepted. This mark is to be set on messages, which have automatically (without any human intervention) been created by a machine. There was not yet any agreement on whether this mark should be in the P22 heading or on the P1 envelope, but P1 seems to be the most probably outcome. File transfer in MHS -------------------- One important issue in the general enhancements group was a facility for store-and-forward file transfer in X.400. Note that this is different than the file transfer provided by FTAM, which is based on direct connections between the hosts. File transfer can be provided in X.400 in two ways, either via new body parts, or via a new content type. Present work aims at providing both facilities. The intention of the X.400 group is to provide file transfer in a way which is compatible with FTAM and ODA, for example in providing similar attributes on the files transferred. This requirement is easier to meet with a new content type for file transfer. A new body part type is however also useful, since it provides easy combination of file transfer with messaging, for example sending a message which contains as one body part a textual message, and as another body part a file such as a spreadsheet. The aim is to provide a facility to transfer complete files, partial files or multiple files, as well as directory structures, support for automatic reception of files. No facility for file transfer on the initiative of the recipient is planned. Visual representation of OR-addresses ------------------------------------- Two human factor.s studies had been done, comparing three different formats for writing OR-addresses on business cards, letter heads etc. Three formats had been compared: (a) A complete format, something like this: Country (C) = SE ADMD = TEDE PRMD = QZ Given Name (GN) = John Surname (SN) = Peterson (b) An abbreviated labelled format, something like this: C=SE; ADMD=TEDE; PRMD=QZ; GN=John; SN=Peterson (c) A very concise format, something like this: John/Peterson//QZ//TEDE/SE The human factors' studies had compared real user performance and satisfaction with these formats. The results of these studies tend to indicate (the studies were however rather restricted in size): That the complete format combined with a form-fill-in user interface (with different fields on the screen for the different OR-name attributes) gave good performance and user satisfaction. That the abbreviated labelled format combined with a form- fill-in user interface also gave good performance. That the abbreviated labelled format combined with a single- string user interface gave bad performance and many errors. That the concise format combined with a single-string user interface gave speedy input but a higher error rate (mostly confusing "/" and "//" when typing in the string). Based on these results, the group concluded that the abbreviated labelled format should be recommended. (This format only works well in combination with a form-fill-in user interface, but which user interface to recommend is outside the scope of present standards). Message store extensions ------------------------ A controversial issue during the meeting were the plans to extend the message store facility in X.400 with new facilities, making it more suitable for long-term storage of messages. (The message store facility in X.400 is at present not a multi-user message store, it is a facility for a central facility to keep letters for a user for a short time after delivery.) The reason this is a controversial issue is that a more advanced message store would be a competitor to the DFR standard, and standards organizations try to avoid several different standards for the same facility. The outcome of the meeting was that the message store should not be changed to make it useful for long-term storage of messages. Some small extensions will be made, but not the more advanced extensions needed for long-term storage. Exactly how "small" the accepted extensions will be is not yet clear. But at least the following facilities will be added: Inlog, outlog, autocorrelation (of incoming notifications to outgoing messages), a simple facility for grouping of stored messages, not as advanced as a full folder facility, stored message tagging. It is possible that the ISO version of the standard will include more MS facilities than the CCITT version. Group communication ------------------- One main issue in the group communication subgroup was whether to use MS (Message Store), DFR (Document filing and retrieval) or Directory System (DS) for the multi-user access long-term storage facilities needed in group communication. No final conclusion was reached, but the tentative feeling in the group seemed to be that MS was not satisfactory. DS has the advantage of supporting a distributed store, while DFR has the advantage of being created for the storage of documents. It seems probable that group communication will use DFR as background storage, to be used by Group Communication Service Agents (GCSA), but that this will not be directly visible to Group Communication User Agents (GCUA), since these will be connected to the Group Communication Service Agent. We decided that at least two protocols are needed for group communication: (a) Group Communication Access Protocol (GCAP), a ROS-based protocol for direct interaction between a GCUA and a GCSA. Probably, also GCSA will be allowed to communicate using the GCAP. (b) Group Communication Service Protocol (GCSP). This will be the main protocol for distributing information between GCSA-s. It will use MTS as a transport vehicle and use (possible an extension of) P22 or a new content type under P1. We made some decisions on reworking the working text X.GC, which included splitting the text into an F.GC and an X.GC version. Voice messaging --------------- There will be both a new content type for voice messaging within MTS and a provision for voice bodies within IPM as body types. The new content type is most useful in communication between voice messaging systems. The new body type is useful when multi-media functionality, i.e. the mixing of voice with other body types, is wanted. The group had heard rumours that the ODA group is working on something called "audio content architecture" but did not know enough about this to be able to evaluate it. More information will be found for the next meeting. The defect group ---------------- The defect group, which handles obvious defects in the present (1988 version) of the standard handled 60 defect reports during the meeting. 53 of these were resolved. By resolving a defect report means that the group concluded that the report was either: - Rather an extension than a defect - A misunderstanding of the standard, not a defect - A real defect, and a correction was issued. There is sometimes a tendency to have much controversy of small details in a standard. Thus, the tentative decision from the last meeting that ADMD="0" (a single zero) should be used to mark an OR-address which is not connected to any ADMD, caused lengthy discussions. The conclusion now was that this will be a difference between the CCITT and ISO version of the standard, and will only be included in the ISO version of it. The tentative decision from the last meeting on the use of T.61 strings across national boundaries was also discussed again. It was accepted that this would be allowed, but that a statement will be put in the standard saying that all MD-s may not be able to handle such OR-address fields. (T.61 allows national characters, like the German and Scandinavian O with two dots on top of it, or the french e with an accent). This means that T.61 is necessary to give proper rendering of names in many non-English languages. A small issue which got much discussion was the ordering of the bits in G3 Facsimili body parts. The present standard requires a reordering of the bits within bytes which some wanted to change. Before deciding, we decided to ask study group VIII (which is responsible for facsimili standards) for their opinion. However, if they do not answer, we will decide how to handle G3 facsimili in X.400 bodies anyway. MHS Management -------------- In this area there seems to be some disagreement between CCITT and ISO, since ISO is more interested in support for routing inside a private domain, while CCITT is mostly interested in routing between ADMD-s. Thus, ISO, but not CCITT, delegates want to continue work for the production of a standard for the exchange of routing information. The group has however now a working document which can be developed into a complete standard. The group also made some work on control of traffic flow, to avoid dead-lock situations which can occur in overload situations in the MTS. Conformance testing ------------------- The conformance testing subgroup recommended that the development of conformance tests for EDI should have high priority. A liaison letter was sent to the separate group (not present at this meeting) for developing conformance tests. This letter stated the above requirements and asked a number of questions regarding the status of conformance testing.
mark@cbmark.cbcc.att.COM (Mark Horton) (08/09/90)
--- begin included message --- Visual representation of OR-addresses ------------------------------------- Three formats had been compared: (a) ... (b) An abbreviated labelled format, something like this: C=SE; ADMD=TEDE; PRMD=QZ; GN=John; SN=Peterson (c) A very concise format, something like this: John/Peterson//QZ//TEDE/SE That the abbreviated labelled format combined with a form- fill-in user interface also gave good performance. That the abbreviated labelled format combined with a single- string user interface gave bad performance and many errors. That the concise format combined with a single-string user interface gave speedy input but a higher error rate (mostly confusing "/" and "//" when typing in the string). Based on these results, the group concluded that the abbreviated labelled format should be recommended. (This format only works well in combination with a form-fill-in user interface, but which user interface to recommend is outside the scope of present standards). ---- end included message --- Of course, if you use the /= syntax with the abbreviated/labelled semantics, as the gateway apparently did: X400-Received: by /PRMD=QZ/ADMD=TEDE/C=SE/; Relayed; 01 Aug 90 13:13:50+0200 you'll get the best of both worlds: low error rate and the ability to use with both form-fill-in and single-string user interfaces (which implies compatibility with most of the software currently in use in the world.) It is a shame that the concise form proved hard for users to handle, but I think I agree with the results. Mark
khiem@hpindda.cup.hp.COM (Khiem Ho) (08/09/90)
>/ hpindda:comp.protocols.iso.x400 / JPALME@qz.qz.se (Jacob Palme QZ) / 10:48 am Aug 1, 1990 / >Notes from the ISO/CCITT joint meeting on messaging, Munich, July 1990. >====================================================================== >....... > >Visual representation of OR-addresses >------------------------------------- > >(a) A complete format, something like this: > >Country (C) = SE >ADMD = TEDE >PRMD = QZ >Given Name (GN) = John >Surname (SN) = Peterson > >(b) An abbreviated labelled format, something like this: > >C=SE; ADMD=TEDE; PRMD=QZ; GN=John; SN=Peterson > >(c) A very concise format, something like this: > >John/Peterson//QZ//TEDE/SE > I recall that there was an US/ANSI contribution (D-28?) in this area (June 1990) to ISO SC18 and CCITT suggesting the syntax "/type=value" for ORAddress. Was it discussed at the July meeting? Khiem Ho Hewlett Packard
he@idt.unit.no (Haavard Eidnes) (08/16/90)
In article <375226*JPALME@QZ.qz.se>, JPALME@qz.qz.se (Jacob Palme QZ) writes: |> Country (C) = SE |> ADMD = TEDE |> PRMD = QZ |> Given Name (GN) = John |> Surname (SN) = Peterson |> |> (b) An abbreviated labelled format, something like this: |> |> C=SE; ADMD=TEDE; PRMD=QZ; GN=John; SN=Peterson |> |> (c) A very concise format, something like this: |> |> John/Peterson//QZ//TEDE/SE I note that the following was *not* evaulated: John.Peterson@qz.tede.se I'm not much in doubt which one I as a user prefer. But hoping for this one is probably a long lost cause. - Havard
bannon@osage.csc.ti.COM (08/16/90)
from: Mark Horton <mark@cbmark.cbcc.att.COM>: > > Visual representation of OR-addresses > ------------------------------------- > > Three formats had been compared: > > (a) ... > > (b) An abbreviated labelled format, something like this: > > C=SE; ADMD=TEDE; PRMD=QZ; GN=John; SN=Peterson > > (c) A very concise format, something like this: > > John/Peterson//QZ//TEDE/SE > For what it's worth, my $0.02 on X.400 addressing: From what I percieve as being proposed as required address formats for input by humans to send mail to other humans it is *completely ridiculous*. For use by computers, fine. Humans??? Wake up. It looks like something a first year CS student would hack up for one of his projects. Something quick and dirty just to get the interface done so he/she could concentrate on the project internals. In my view electronic mail addressing formats should converge to those used to address ordinary physical mail, the kind you put stamps on and put in the mail box on the corner. If my grandmother is going to be able to send email to my mother, it had better be pretty close, if not *completely* inter-changeable with the mail addressing she already knows how to do. What is this "C=SE; ADMD=TEDE; PRMD=QZ" garbage anyway? My god, this is terrible!! Supposedly in the not too distant future we'll all be linked up via high speed data channels from fiber and satellite networks. At that time the ratio of ordinary people vs. all us university, government, & corporate computer types using systems such as email will probably be something like 10000:1 and growing. Do you see ordinary people getting into "C=SE; ADMD=TEDE; PRMD=QZ"? Well, perhaps I'm way off base here, and X.400 is not expected to be any kind of a major player in the real world. But you get my drift. Some serious human interface work will be required in this area. Tom Information Technologies Laboratory Computer Science Center Texas Instruments, Dallas bannon@csc.ti.com
perry@MCL.Unisys.COM (Dennis Perry) (08/16/90)
from: Mark Horton <mark@cbmark.cbcc.att.COM>: > > Visual representation of OR-addresses > ------------------------------------- > > Three formats had been compared: > > (a) ... > > (b) An abbreviated labelled format, something like this: > > C=SE; ADMD=TEDE; PRMD=QZ; GN=John; SN=Peterson > > (c) A very concise format, something like this: > > John/Peterson//QZ//TEDE/SE > Tom Bannon adds the following >> >>For what it's worth, my $0.02 on X.400 addressing: From what I >>percieve as being proposed as required address formats for input >>by humans to send mail to other humans it is *completely >>ridiculous*. For use by computers, fine. Humans??? Wake up. >>It looks like something a first year CS student would >>hack up for one of his projects. >>In my view electronic mail addressing formats should converge to >>those used to address ordinary physical mail, the kind you put >>stamps on and put in the mail box on the corner. >>Do you see ordinary people getting into "C=SE; ADMD=TEDE; PRMD=QZ"? >>Tom >>Information Technologies Laboratory >>Computer Science Center >>Texas Instruments, Dallas >>bannon@csc.ti.com Finally, a reasonsable statement about how technology runs amuck and causes ordinary people (not elite technologist) to react negatively to technology. Technology should be used to make life enjoyable, remove the drudgery, and advance the civilization of the human race. In the business world it should promote and support the activities of that business. In the academic world it can do what ever it wants, since that is what academics do. :-) Unfortunately, anarchy in non-academic society does not promote the advance of that society, but retards it. dennis