Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09664; 3 Jun 94 14:18 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09660; 3 Jun 94 14:18 EDT Received: from THOR.INNOSOFT.COM by CNRI.Reston.VA.US id aa14331; 3 Jun 94 14:18 EDT Received: from REPROCESS-DAEMON by INNOSOFT.COM (PMDF V4.3-8 #1234) id <01HD3OYAWV7495N15F@INNOSOFT.COM>; Fri, 03 Jun 1994 10:29:21 -0700 (PDT) Received: from gw1.att.com by INNOSOFT.COM (PMDF V4.3-8 #1234) id <01HD3OY2AWTS95N3BP@INNOSOFT.COM>; Fri, 03 Jun 1994 10:29:10 -0700 (PDT) Received: from mrspock.UUCP by ig1.att.att.com id AA23918; Fri, 3 Jun 94 13:28:37 EDT Received: by mrspock.mt.att.com (4.1/SMI-4.1) id AA10225; Fri, 3 Jun 94 13:28:39 EDT Date: Fri, 03 Jun 1994 13:28:38 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Douglas N. Zuckerman" Subject: IFIP/IEEE ISINM '95 CFP Reminder To: ietf-madman@innosoft.com Errors-to: ~ned+madman-errors@SIGURD.INNOSOFT.COM Message-id: <9406031728.AA10225@mrspock.mt.att.com> X-Mailer: ELM [version 2.4 PL3] Content-type: text Content-transfer-encoding: 7BIT Original-From: mrspock!w2xd (Douglas N. Zuckerman) Original-To: innosoft.com!ietf-madman _/ _/_/_/ _/ _/ _/ _/ _/ _/ _/_/_/_/ _/_/_/_/ _/ _/ _/ _/ _/_/ _/ _/_/ _/_/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/_/ _/ _/ _/ _/ _/ _/ _/_/_/ _/ _/ _/ _/ _/ _/ _/ _/_/_/_/ _/_/_/_/ _/ _/ _/ _/ _/_/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/ _/_/_/ _/ _/ _/ _/ _/ _/_/_/ _/_/_/_/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ IFIP/IEEE INTERNATIONAL SYMPOSIUM ON INTEGRATED NETWORK MANAGEMENT _/ _/ C A L L F O R P A P E R S _/ Red Lion Hotel, Santa Barbara, California, USA _/ 1-5 May 1995 _/ _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ The one and only ISINM will return in 11 months. Mark your calender now! This is your Symposium, but please remember that you have only 1 month to go, to send us your paper for review. Authors are invited to submit unpublished papers, as well as proposals for tutorials, panel discussions, poster demonstrations, or birds-of-a-feather sessions (informal discussion groups), in the following topic areas: o User Requirements, Expectations and Analysis for Integrated Networked Systems Management o Standards Issues and Different Layer Management Approaches: OSI, TMN, SNMP, Internet and Others o Telecommunications Management, including OAM&P o Personal Communications Services and Wireless Data Communications Network Management o High-Speed Network Management: B-ISDN, ATM-LAN, DQDB, FDDI, etc. o Interplay of Networked Systems and Telecommunications Management o Fault, Configuration, Accounting, Performance, Security Management o Quality of Service Management o Management Protocols and Protocol Management o Models, Architectures and Formal Methods o Distributed Systems Management o Information Modeling and Storage: Database Techniques, Object Oriented Management o Information Interpretation: AI Techniques, Rule-based Analysis, Neural-Networks Modeling o Interoperability and Cooperative Operation o Management Applications o Trials, Case Studies Experiences: Solutions, Limitations and Challenges o Product Strategies and Different Vendor Approaches All submissions will be carefully reviewed by four international experts and returned to the author(s) with comments to ensure high quality. The authors of accepted papers will receive the suggested modifications for inclusion in the widely distributed, hard-bound Symposium Proceedings. The final camera- ready copy should be no longer than 12 single-spaced pages. Final papers arriving too late will be removed from the program. The authors of accepted papers must guarantee that their paper will be presented at the symposium. Please submit six (6) copies of complete papers in English to either address listed below. The cover page should include paper title, brief abstract, list of key-words, author(s) full name(s), affiliation(s) and complete address(es), telephone number(s) and electronic mail address(es). PLEASE SEND COMPLETE PAPERS TO: Program Co-Chair: (Americas, Australia) Professor Adarshpal S. Sethi Department of Computer & Information Sciences University of Delaware, Newark, Delaware 19716, USA Email: sethi@cis.udel.edu Fax: +1 302 831 8458 Program Co-Chair: (Europe, Asia, Africa) Professor Yves Raynaud Universite Paul Sabatier - IRIT/SIERA - 118 route de Narbonne, Toulouse 31062 FRANCE Email: raynaud@irit.fr Fax: +33 61 55 8247 ------------------------------------------------------ DEADLINE FOR RECEIPT OF PAPERS: July 1, 1994 Notification of Acceptance Mailed: October 15, 1994 Final Camera Ready Papers Due: December 1, 1994 ------------------------------------------------------ Submit Proposals for Tutorials, Panel Discussions, Birds-of-a-Feather Sessions, and Poster Demonstrations to: Special Events and Tutorials Chair: Dr. Iyengar Krishnan The MITRE Corporation, W425 7525 Colshire Drive, McLean, Virginia 22102, USA Email: kris@mitre.org Fax: +1 703 883 7142 Deadline for Receipt of Proposals for Tutorials, Panel Discussions, Birds-of-a-Feather Sessions, and Poster Demonstrations: August 15, 1994 ------------------------------------------------------ For more information about ISINM '95 or to indicate your interest in participating, please contact: Mary Olson ISINM '95 P.O. Box 22605, Santa Barbara, CA 93101, USA Phone: +1 805 569 1222 Fax: +1 805 569 2227 Email: ISINM@cs.ucsb.edu _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28680; 8 Jun 94 0:22 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28676; 8 Jun 94 0:22 EDT Received: from THOR.INNOSOFT.COM by CNRI.Reston.VA.US id aa25712; 8 Jun 94 0:22 EDT Received: from REPROCESS-DAEMON by INNOSOFT.COM (PMDF V4.3-8 #1234) id <01HD9VR3YSE895N79X@INNOSOFT.COM>; Tue, 07 Jun 1994 20:49:04 -0700 (PDT) Received: from comm.Tandem.COM (comm.cpd.tandem.com) by INNOSOFT.COM (PMDF V4.3-8 #1234) id <01HD9VQYZSJ495N5G2@INNOSOFT.COM>; Tue, 07 Jun 1994 20:48:58 -0700 (PDT) Received: by comm.Tandem.COM (4.10/4.5) id AA10041; 7 Jun 94 20:44:29 +1700 Date: 7 Jun 94 20:38:00 +1700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: LEBECK_SUE@tandem.com Subject: Report on latest Messaging Mgmt Council (MMC) To: ifip-emailmgt@ics.uci.edu Cc: nhirose@attmail.com, rjesmajian@attmail.com, valet@prl.dec.com, valet@taec.enet.dec.com, efifiom.edem@ei.par.sita.nt, ietf-madman@innosoft.com Errors-to: ~ned+madman-errors@SIGURD.INNOSOFT.COM Message-id: <199406072044.AA10041@comm.Tandem.COM> Content-transfer-encoding: 7BIT Folks -- These arene't the official minutes, but attached are my notes re: the recent meeting of the Messaging Management Council (MMC), an emerging new industry group which is promoting near-term deployment of common messaging management practices/facilities/software. MMC is looking to leverage work that has been done and is on-going; I have (and plan to continue to) attend, representing IFIP directly and IETF and ISO/ITU indirectly, during this work. I encourage participation from you, as well. Please see attached. Questions and comments welcome. Cheers, Sue ------------ TEXT ATTACHMENT -------- SENT 06-07-94 FROM LEBECK_SUE Messaging Management Council (MMC) ---------------------------------- First Technical Meeting, May 26, 1994 Atlanta, Georgia Participants: ------------- Eighteen different Companies/Organizations participated in this first technical meeting of the Messaging Management Council. They include: AT&T (Global Info Systems) Tandem Exxon WorldTalk Lotus SITA Soft*Switch Microsoft Intel Sequent EMA CMS Collabra Retix WallData ISOCOR ? Service Boeing (by phone) The meeting was chaired by David Knight of ISOCOR. The meeting setting was hosted by Microsoft. Re-cap of last (first) MMC meeting (at EMA): (Thom McCann, Microsoft) --------------------------------------------------------------------- - Defined general charter - Focus: 6-9 month timeframe - Scope: spans multiple messaging technologies and products - EMA chartered with producing requirements document, by the time of the first technical MMC meeting a month later - Mailing list established - IFIP work introduced Update on EMA and MMC relationship: (Roger Mizumori, Boeing, EMA Board Member) ------------------------------------------------------------------------------ - EMA generated the requirements document - met the 30 day challenge - agreed approach is to follow the XAPIA structure of having an Executive Subcommittee (ESC) to provide direction and requirements, and a Technical Subcommittee (TSC) to develop the technical work. In this case, the proposal and anticipated outcome is that the EMA would play the ESC role, and the MMC would play the TSC role. Discussion of the EMA Requirements document: -------------------------------------------- - Boeing supports the document in general, though some tweaking is needed. Boeing will be submitting consolidated comments next week. - The EMA Requirements document was perceived by the Chair and others to be starting at a point that was a bit too detailed. We decided to step back a bit and develop some parameters and prioritization of our work, as seen by the group present, and then to reconcile that with the EMA Requirements document. The parameters and prioritizations are discussed in sections below. The MMC (TSC) will respond to the EMA regarding the EMA Requirements Document. - The MMC (TSC) feels that the first-increment functional set should be a smaller set than that proposed by the EMA. It is believed that this smaller set is all that is practical to do in the allowed timeframe. This smaller set is described below. Goals: ------ - From a user perspective (eg. Boeing), the primary goal of messaging management is to heighten a user's ability to trust in the reliability of the system/network. The basic goal of our work, therefore, is to incrementally improve the effective reliability of the network. - Another goal is to make our current work fit within existing deployed management facilities, and also to be able to integrate it with a standard infrastructure. - The intent is to enable the development of a modest but significant increment of common management capability across available commercial products, within an approximately 2 year period. Lists of Parameters/Prioritizations developed by MMC group present: ------------------------------------------------------------------- The following lists were developed, led by David Knight, ISOCOR. The System: Characteristics ----------------------------- - Manage Multiple Domains - Centralized Administration - Support Inter-networks - Multiple Components - Work across public networks - scaled approach (i.e. able to gradually increase scope of influence) - User needs must be addressed as well as Administrative needs Functional Requirements: ------------------------ - Monitoring (this is viewed as being networking-oriented) - Auditing (this includes Accounting and Message Tracking; it is viewed as being oriented to a particular message/transaction.) - Control - Configuration - Administration/Registration (eg. add a user to a directory) Messaging Components: --------------------- - MTAs/Switches - Gateways - Message Stores (this includes both the active and passive aspects, and should consider a view of what Message Stores will likely evolve to in the future.) - Clients - Directories - Network itself (considered out of scope, from a definition standpoint; however, we'd like to be able to get hints, at the messaging level, about what problems mights exist at the lower network level.) Proposed Prioritization for 6-9 Month Focus: -------------------------------------------- It was believed by the group present that the following constitutes a practical set for the current 6-9 month focus; this is a subset of the first-priority requirements proposed by the EMA. The prioritization result includes the following Functional Requirements: - Monitoring - Auditing for the following Messaging Components: - MTAs/Switches - Gateways All work must be cross-checked against the list of system characteristics described above. Modes of Operation: ------------------- A major consideration for our work is that the result be deployable given technologies widely available and deployed today. In the least common denominator case (and, initially, perhaps the most common case ;-), this may mean that only the messaging system itself is available for communicating management requests and information. This led to the belief that, to the extent possible and practical, our work should result in specification building-blocks that are deployable over two different modes of operation: Store and Forward, and Real-time. - STORE AND FORWARD: It should be possible to issue some subset of the defined requests and responses via use of the store & forward messaging system itself, for example, using an Administrative Messaging Enabled Application (MEA) which responds to messages sent to a well-known mailbox. The EMA proposal for "MTA Trace" queries between domains is an example of this. Note, however, that it is often sub-optimal to use the messaging system itself to manage the messaging system, particularly when problems with the messaging system itself are present or suspected. (Note: this is relevant to the "MTA Trace" example.) Therefore, as much as possible, the Real-Rime mode of operation should also be deployed. - REAL-TIME: A real-time mode of operation should also be defined, and deployed whenever possible. This will be accomplished, for example, using a Network Management protocol, such as SNMP. This mode is preferred when, for eg., an immediate response is important, or when problems with the messaging system are present or suspected. Also, certain management functions may only be sensibly accomplished using a real-time approach. IFIP Email Management Summary: (Sue Lebeck, Tandem) --------------------------------------------------- Sue gave a half-hour rundown of Email standardization work in the industry, including: - IETF's MADMAN work - Joint ISO and ITU work on MHS Management - IFIP Email Management's work and experience today, including a description of the cross-committee coordination role which they have taken on, and plan to take on regarding the MMC work Sue also provided to all participants copies of relevant specifications, including documents from IETF, ISO/ITU, and IFIP, for use at the meeting and to take back to their companies for digestion. Everyone took back an action item to ensure that they or someone in their organization digested the documentation prior to the next meeting, and developed ideas as to how the work may be leveraged. Brief Discussion of Current Available Work ------------------------------------------ - The IETF "MADMAN" MIB on Mail Monitoring (RFC1566) defines a base set of monitoring information, using an SNMP-based model and notation. This MIB is considered to likely be a leverageable piece of work, relevant to Monitoring. We will evaluate it for appropriateness and completeness. This MIB is in "Proposed Standard" state within the IETF (Internet community); given its relatively stable, and implementable state, it will be evaluated for direct usage. It is suspected, however, that it will not be found to meet all of the Monitoring needs. We will also look at this MIB with an eye to supporting the Store and Forward mode of operation (i.e. info accessible from a management MEA) as well as the Real-Time (SNMP) mode. - The EMA draft paper on MTA Trace is considered to likely be a leveragable piece of work, relevant to Auditing/Message Tracking. We will look at it, and try to determine how it might be adapted for non-X.400 use (since it is currently written with X.400 in mind.) Also, we will look at the syntax with an eye to ensure that the selected fields and syntaxes can successfully traverse through gateways, with all required information and position still intact. Support of this sort of service using the Real-Time model will also be considered. - The EMA paper on "Guidelines to Production PRMDs" may contain information relevant to our work. - ISO, together with the ITU, have generated extensive management information definitions, which are in various stages of stability. An extensive and relatively stable document (Committee Draft, or CD) exists on "Logging Information". It is expected that this document will contain work relevant to Auditing/Accounting/Message Tracking. Additionally, a Working Draft on MTA managed objects is likely to contain information leverageable to our work. - The Desktop Management Task Force (DMTF) work may be relevant, when we get to working on the Client component. - The EMA has a paper on Gateway testing; our work might result in requirements relevant to their work. - The EMA has a paper "Guidelines for Production PRMDs", which may contain information relevant to our work. - The IFIP "Strawman MIB" may contain input materials relevant to our work. - The ISO/ITU "Model and Architecture" document may also be helpful. Next Meeting(s) --------------- - June 23 (Thurs. aft) and June 24 (all day Friday), Seattle WA (piggy-backed on Microsoft Information Exchange conference) - Same week and venue as July 19-21 EMA Committee Meetings, Chicago IL - continued meetings, as needed - Possibly culminating in a demo/announcemnet, in January 1995, Orlando, FL (piggy-backed at the LOTUS Fair) Action Items ------------ - ALL : Take home and digest (or find someone to digest) distributed documents, and think of ways in which to leverage the information there for monitoring and auditing MTAs and Gateways. - David Knight (draft), Ed Owens, Roger Mizumori, DS (sorry, I missed who this is), Sue Lebeck (review): Respond to EMA Requirements Document, based on our discussions, by June 10. - Mark Smith, Bob Costa, Connor (Sorry, missed last name, of Retix), Thom McCan, Tim (Sorry, missed last last name, of LOTUS): Develop proposed refinement of the EMA "MTA Trace" syntax. Open Issues ----------- - Solicit thoughts on "what is a Gateway?" and what functions must be monitored. Julie Ferris might have important input on this one. - What's it mean to have a messaging infrastructure for Management? What should the primitives look like? what granualarity is appropriate?   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00373; 13 Jun 94 3:59 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00369; 13 Jun 94 3:59 EDT Received: from THOR.INNOSOFT.COM by CNRI.Reston.VA.US id aa00926; 13 Jun 94 3:58 EDT Received: from REPROCESS-DAEMON by INNOSOFT.COM (PMDF V4.3-8 #1234) id <01HDH2UVNZOW95NA05@INNOSOFT.COM>; Mon, 13 Jun 1994 00:27:45 -0700 (PDT) Received: from comm.Tandem.COM (comm.cpd.tandem.com) by INNOSOFT.COM (PMDF V4.3-8 #1234) id <01HDH2UQ7LV495MP4E@INNOSOFT.COM>; Mon, 13 Jun 1994 00:27:34 -0700 (PDT) Received: by comm.Tandem.COM (4.10/4.5) id AA1337; 13 Jun 94 00:30:51 -0700 Date: Sun, 12 Jun 1994 23:38:00 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: LEBECK_SUE@tandem.com Subject: Report from May "Interim" meeting of Email Mgmt To: ifip-emailmgt@ics.uci.edu Cc: ewos-mhs-mgt@ukerna.ac.uk, nhirose@attmail.com, ietf-madman@innosoft.com Errors-to: ~ned+madman-errors@SIGURD.INNOSOFT.COM Message-id: <199406130030.AA1337@comm.Tandem.COM> Content-transfer-encoding: 7BIT Attached please find my report from the Tandem-hosted "interim" meeting of the IFIP Email Management group, held on the West Coast, last month. This meeting produced the work which made up the contribution to ANSI (and later to ISO/ITU) sent 'round the other day. That contribution is also contained in this report. Best, Sue ------------ TEXT ATTACHMENT -------- SENT 06-12-94 FROM LEBECK_SUE ----------------------------- IFIP EMAIL MANAGEMENT Group: ----------------------------- Minutes from the May Interim Meeting Hosted by Tandem Computers ------------ Participants ------------ Gordon Jones, MITRE Chris Lavagmino, Retix Heather McKelvey, Tandem Sue Lebeck, Tandem Bruce Greenblatt, Novell Thanks to all who attended! Thanks especially to the travel efforts made by Gordon (who came cross-country) and by Chris. We had a cozy but productive meeting. -------------------------------- Primary Goal and Accomplishment -------------------------------- This meeting was held with the primary goal of developing a contribution to ISO/ITU re: the genericization (don't know if that's a word, but it must be by now; we've been using it for a year :-)) of the ISO/ITU MHS Management Work. In their response to our earlier contribution, in which we expressed the belief that the MHS Management work could and should be made leverageable beyond X.400, the ISO/ITU group agreed in spirit and invited us to make a detailed contribution. We have done so, focusing on the MTA Management piece (and, in particular, on the "Part 8: MTA Management" draft document.) A contribution was developed, and is included below. The contribution also includes miscellaneous comments on the targeted document. In order to enhance its reception at the ISO/ITU meeting later this summer (July, I believe), we are also submitting it to the U.S. contingent (ANSI) meeting this week. We hope to find support from that group. I aplogize that this contribution was not compiled until very recently, leaving a minute amount of time for reaction from the list. Please, however, submit any comments you may have on this. There is still time to feed modifications of the attached into the ISO/ITU process, (and, to a lesser degree, there is time to feed comments into the ANSI process later this week) and I will ensure that it is done. I am "on the road" at the IFIP Email Management meeting hosted by NIST and the OSE Implementors Workshops this week, but I am electronically attached, and reading e-mail. Best, Sue Lebeck IFIP Email Management Chair -------------------------------------------------------------------- GENERICIZATION CONTRIBUTION FOLLOWS: I. Genericization of ISO/IEC CD 11588-8 : 1994(E) As we worked through the document (ISO/IEC CD 11588-8, dated February 1994) we sought opportunities to apply the superclass mechanism, in order to genericize the management information (i.e. to make the management information applicable to X.400 and non-X.400 messaging technologies alike). This attempt was in followup to our past dialogue, in which you invited us to develop concrete proposals regarding genericization. When reviewing the document, we found most of the defined information to be applicable to any messaging system (although there are many features which may or may not be included in a given messaging implementation, X.400 or otherwise). In our search, we found that the addition of superclasses was unneccessary after all; we found that the management information would be largely genericized simply by modifying many of the addressing/naming attribute definitions, and by modifying some of the Managed Object names. As we worked through the document, the things we did find that were X.400- specific fell into the following categories: 1) Managed Object and attribute names (e.g. "p1Mta" could become "adjacentMta") 2) Addressing/naming syntax a) message identifier construction b) message and body part typing c) credential syntax ------------- To address 1): ------------- We felt that a slightly modified set of names could be employed. Our proposal is that the Object/Attribute name values be modified as follows: (All section references refer to "Part 8: MTA Management") These effect: Section 9 (9.7, 9.8, 9.20, 9.21) "P1MTA" ------> becomes "AdjMTA" "P3MTSUser" ------> becomes "MTSUser" "SecP1MTA" ------> becomes "SecAdjMTA" "SecP3MTSUser" ------> becomes "SecMTSUser" These effect: Section 10 (10.11, 10.12, 10.13, 10.14, 10.30, 10.31, 10.43, 10.44, 10.45) "P1MTAConditionalPackage" ------> becomes "AdjMTAConditionalPackage" "P1MTAPackage" ------> becomes "AdjMTAPackage" "P3MTSUserConditionalPackage" ------> becomes "MTSUserConditionalPackage" "P3MTSUserPackage" ------> becomes "MTSUserPackage" "SecP1MTAPackage" ------> becomes "SecAdjMTAPackage" "SecP3MTSUserPackage" ------> becomes "SecMTSUserPackage" "X500DistributionListPackage" ------> (we recommend be merged into "DistributionListPackage") "X500MTAPackage" ------> becomes "DirServiceMTAPackage"" "X500ReferencePackage" ------> becomes "DirServiceReferencePackage" These effect: Section 11 (11.49, 11.50, 11.51, 11.52, 11.164, 11.165, 11.178,11.92, 11.123, 11.124) "MaxP1InboundAssocs" ------> becomes "MaxAdjMTAInboundAssocs" "MaxP1OutboundAssocs" ------> becomes "MaxAdjMTAOutboundAssocs" "MaxP3InboundAssocs" ------> becomes "MaxMTSUserInboundAssocs" "MaxP3OutboundAssocs" ------> becomes "MaxMTSUserOutboundAssocs" "SecP1MTAId" ------> becomes "SecAdjMTAId" "SecP3MTSUserId" ------> becomes "SecMTUserId" "SupportedPSAPs" ------> becomes "SupportedAccessPoints" "NeighboringPSAPAddress" ------> becomes "NeighboringAccessPointAddress" "ORaddress" ------> becomes "UserAddress" "ORaddresses" ------> becomes "UserAddresses" These changes also carry over into Section/Clause 7 (Services) and Section/Clause 14 (Name Bindings) -------------- To address 2): -------------- We felt that applying an open-ended typing mechanism worked better than applying the superclass mechanism. GenericAddress ::= SEQUENCE { DisplayFormat PrintableString DEFAULT "", TypedFormat SEQUENCE { Type OBJECT IDENTIFIER, Value ANY DEFINED BY Type } GenericName ::= SEQUENCE { DisplayFormat PrintableString DEFAULT "", TypedFormat SEQUENCE { Type OBJECT IDENTIFIER, Value ANY DEFINED BY Type } Note: although the definitions of these attributes are the same, the semantics of the name and address are different. The DisplayFormat field of the Generic objects allows for the display of names and addresses even when the actual types of the addresses can not be resolved. The following examples show the application of GenericName and GenericAddress: In 10.13 of ISO/IEC CD 11588-8: mtsUserConditionalPackage { . . userAddress . . UserAddress ::= GenericAddress -- here the display format for an O/R Address would use the new -- annex to 10021-2. OID is id-attribute-orAddress -- value is an ASN.1 ORAddress Note: userAddress is not actually resolved in the document CD 11588-8, February 16, 1994; we assume that this resolves to an ORAddress . . -- static information supportedAccessPoints -- this replaces supportedPSAPs . . supportedAccessPoints ::= SET OF GenericAddress -- here the display format for a PSAP address is -- a printable representation of the PSAP address -- the OID is id-attribute-psapAddress -- value is an ASN.1 PSAPAddress In 10.45 of ISO/IEC CD 11588-8: DirectoryServicesReferencePackage { . . directoryName GET, . . DirectoryName ::= SET OF GenericName . . } -- here the display format for an X.500 Directory Name -- would use the format described in the new annex to 10021-2 -- OID is id-attribute-directoryName, value is an -- ASN.1 DirectoryName Note: DirectoryName is not actually resolved in the document CD 11588-8 Feb 16, 1994; we assume this is imported from a Directory document In 10.11 of ISO/IEC CD 11588-8: GlobalDomainID ::= GenericName -- we assume that this is intended to be an MTAName, -- which is defined as an IA5String, which should -- be made more generic MTA Address ::= GenericName -- this general mechanism can apply to MTAAddress as well -- we think that MTAName was intended to be used here In 10.6 of ISO/IEC CD 11588-8: We propose that the syntax used by messageIdentifier, which is the syntax MessageIdentifier found in 11588-3.2, be replaced by GenericMessageId ::= SEQUENCE { DisplayFormat PrintableString DEFAULT "", TypedFormat SEQUENCE { Type OBJECT IDENTIFIER, Value ANY DEFINED BY Type }} -- the OID for an X.400 message id is -- id-attribute-messageIdentifier, and -- the value would be an X.400 messageIdentifier. We propose that the syntax used by messageEITs, (which is not defined in 11588-8; however, the syntax Eits which is defined as EncodedInformationTypes which in turn is imported from MTSAbstractService) is not sufficiently generic, and we propose that it be replaced by GenericMessageEncodedInformationTypes ::= SEQUENCE OF OBJECT IDENTIFIER -- the OIDs in the sequence list out each of the -- encoded information types found in the message messageType, which refers to 11588-3.2, clause 12.82, which states "the MessageType indicates if the record refers to an IPM, IPN, EDIM, or EDIM," and the permitted values are "??"; this should not be limited to the values IPM, IPN, EDIM, or EDIN in the previous description In 10.9 and 10.11 of ISO/IEC CD 11588-8: Credentials (simple, strong) is imported from MTS Abstract Services. We believe that this definition should allow for other forms of credentials. GenericCredentials ::= SEQUENCE { Type OBJECT IDENTIFIER, Value ANY DEFINED BY Type } -- the OID, in the case of X.400 simpleCredentials, would be -- id-attribute-simpleCredentials -- the value would be of the syntax SimpleCredentials In 10.11 of ISO/IEC CD 11588-8: possibleConversions is resolved to FromToEIT, which is defined as an ExplicitConversion, which is imported from MTAAbstractService. However, as the X.400 recommendation specifies that ExplicitConversion is an Integer with all of the values explicitly spelled out in X.400, this is not a sufficiently general method of specifying conversions.. Thus, we suggest the use of a GenericConversion "object" as follows: GenericConversion ::= SEQUENCE { From OBJECT IDENTIFIER, To OBJECT IDENTIFIER } -- This conversion identifies the source and target information -- that are to be used in a generic conversion. II. MISCELLANEOUS COMMENTS ON ISO/IEC 11588-8 1. In 9.4 of ISO/IEC CD 11588-8: We could not resolve reportPackage, and if it refers to reportStatisticsPAckage, it does not seem to contain the needed information. 2. In 10.6 of ISO/IEC CD 11588-8: This requires that the content be opened to find the expiryTime. Normally, MTAs aren't required to do this, and it is one of a number of things that may be obtained from the content. 3. In 10.4 and 10.43 of ISO/IEC CD 11588-8: DistributionListPackage and x500DistributionListPackage both contain distribution list information that is potentially relevant whether or not x500 is used; we think they should be merged as DistributionListPackage. III. ADDITIOANL COMMENTS ON ISO/IEC 11588-8 Ref.# Clause Qualifier Text 1. 9.4 M The conditional package reportPackage in the MHSInfoObject is not defined in section 10, Definition of Packages. 2. 10.11 Q P1MTAConditionalPackage, mtaAddress is not defined in the document. Is this a PSAP or an OR Address? Is globalDomainId the same as a GlobalDomainIdentifier? Or can the globalDomainId be something other than an ADMD or PRMD? 3. 11.175 M The attribute simpleCredentials, is this bounded by X.500? If so is it to be imported from X.509? 4. 10.13 M In p3MtsUserConditionalPackage the attribute userAddress is not defined in the section 11, Definition of Attributes or imported. 5. 10.13 e p3MtsUserConditionalPackage the attribute deliverableContentLengths we assume resolves to deliverableContentLength. 6. 10.42 m The redirectionRecipient attribute in the simpleRedirectionPackage resolves to RecipientAssignedAlternateRecipient. RecipientAssignedAlternateRecipient is not defined or imported. 7. 10.6 M The attribute messageEITs in the MhsInfoObjectPackage is not defined in the section 11, Definition of Attributes or imported. 8. 10.6 M The attribute mhsInfoObjectSize in the MhsInfoObjectPackage is not defined in the section 11, Definition of Attributes or imported. 9. 10.6 e The attribute deferalTime in the MhsInfoObjectPackage is misspelled, and we assume is intended to be deferralTime.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26307; 21 Jun 94 0:50 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26303; 21 Jun 94 0:50 EDT Received: from THOR.INNOSOFT.COM by CNRI.Reston.VA.US id aa27274; 21 Jun 94 0:50 EDT Return-path: glenn@aic.co.jp Received: from REPROCESS-DAEMON by INNOSOFT.COM (PMDF V4.3-8 #1234) id <01HDS30WRB8W95NAZC@INNOSOFT.COM>; Mon, 20 Jun 1994 21:31:16 -0700 (PDT) Received: from aic-wide.aic.co.jp (150.80.254.1) by INNOSOFT.COM (PMDF V4.3-8 #1234) id <01HDS2ZT9QJK95NDQQ@INNOSOFT.COM>; Mon, 20 Jun 1994 21:31:10 -0700 (PDT) Received: by aic-wide.aic.co.jp (5.65+1.5W/2.7W) id AA07649; Tue, 21 Jun 94 13:29:26 JST Date: Tue, 21 Jun 1994 13:29:26 +0900 (JST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Glenn Mansfield Subject: MADMAN status .. To: S.Kille@isode.com Cc: ietf-madman@innosoft.com Errors-to: ~ned+madman-errors@SIGURD.INNOSOFT.COM Message-id: <9406210429.AA07649@aic-wide.aic.co.jp> Content-transfer-encoding: 7BIT Steve, Is the MADMAN-wg going to be re-activated at Toronto? According to the report of the Area-director - MADMAN is eligible for re-activation. Glenn   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07555; 21 Jun 94 12:24 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07551; 21 Jun 94 12:24 EDT Received: from THOR.INNOSOFT.COM by CNRI.Reston.VA.US id aa10195; 21 Jun 94 12:23 EDT Received: from REPROCESS-DAEMON by INNOSOFT.COM (PMDF V4.3-8 #1234) id <01HDSLWTAH0095NFE2@INNOSOFT.COM>; Tue, 21 Jun 1994 06:32:23 -0700 (PDT) Received: from glengoyne.isode.com by INNOSOFT.COM (PMDF V4.3-8 #1234) id <01HDSLWGYMZK95NFMC@INNOSOFT.COM>; Tue, 21 Jun 1994 06:32:16 -0700 (PDT) Date: Tue, 21 Jun 1994 14:31:58 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Kille Subject: Re: MADMAN status .. In-reply-to: Your message of Tue, 21 Jun 1994 13:29:26 +0200. <9406210429.AA07649@aic-wide.aic.co.jp> To: Glenn Mansfield Cc: ietf-madman@innosoft.com Errors-to: ~ned+madman-errors@SIGURD.INNOSOFT.COM Message-id: <13568.772205518@glengoyne.isode.com> Content-id: <13561.772205506.1@glengoyne.isode.com> MIME-version: 1.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: 7BIT Phone: +44-81-332-9091 I believe that there are a number of issues that will need to be addressed. However, I do not think that we are far enough down the implementation track to justify this. I will be happy to hear views to the contrary, provided that they indicate clearly the technical work that they see the group should do. Steve   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10361; 21 Jun 94 14:15 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10357; 21 Jun 94 14:15 EDT Received: from THOR.INNOSOFT.COM by CNRI.Reston.VA.US id aa12982; 21 Jun 94 14:15 EDT Received: from REPROCESS-DAEMON by INNOSOFT.COM (PMDF V4.3-8 #1234) id <01HDSQRCWOF495NFE2@INNOSOFT.COM>; Tue, 21 Jun 1994 08:50:48 -0700 (PDT) Received: from SIGURD.INNOSOFT.COM by INNOSOFT.COM (PMDF V4.3-8 #1234) id <01HDSQRARIN495NFPN@INNOSOFT.COM>; Tue, 21 Jun 1994 08:50:39 -0700 (PDT) Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.4-0 #1234) id <01HDS76QTG289KM5OE@SIGURD.INNOSOFT.COM>; Tue, 21 Jun 1994 08:49:49 -0800 (PST) Date: Tue, 21 Jun 1994 08:48:23 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ned Freed Subject: Re: MADMAN status .. In-reply-to: Your message dated "Tue, 21 Jun 1994 13:29:26 +0900 (JST)" <9406210429.AA07649@aic-wide.aic.co.jp> To: Glenn Mansfield Cc: S.Kille@isode.com, ietf-madman@innosoft.com Errors-to: ~ned+madman-errors@SIGURD.INNOSOFT.COM Message-id: <01HDSQQACZNI9KM5OE@SIGURD.INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT > Is the MADMAN-wg going to be re-activated at Toronto? According to the > report of the Area-director - MADMAN is eligible for re-activation. While MADMAN is eligible for reactivation at this time, I agree with Steve that more implementation experience is needed before we do so. Ned   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16206; 21 Jun 94 21:17 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16202; 21 Jun 94 21:17 EDT Received: from THOR.INNOSOFT.COM by CNRI.Reston.VA.US id aa20919; 21 Jun 94 21:17 EDT Return-path: glenn@aic.co.jp Received: from REPROCESS-DAEMON by INNOSOFT.COM (PMDF V4.3-8 #1234) id <01HDT96XGAOW95NFE2@INNOSOFT.COM>; Tue, 21 Jun 1994 17:38:43 -0700 (PDT) Received: from aic-wide.aic.co.jp by INNOSOFT.COM (PMDF V4.3-8 #1234) id <01HDT96BQWV495NE6W@INNOSOFT.COM>; Tue, 21 Jun 1994 17:38:36 -0700 (PDT) Received: by aic-wide.aic.co.jp (5.65+1.5W/2.7W) id AA28944; Wed, 22 Jun 94 09:37:47 JST Date: Wed, 22 Jun 1994 09:37:47 +0900 (JST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Glenn Mansfield Subject: Re: MADMAN status .. To: S.Kille@isode.com Cc: ietf-madman@innosoft.com Errors-to: ~ned+madman-errors@SIGURD.INNOSOFT.COM Message-id: <9406220037.AA28944@aic-wide.aic.co.jp> Content-transfer-encoding: 7BIT Steve, One of the inadequacies I have experienced in X.500 Directory management is the lack of instrumentation for monitoring entities like the GDA. Presently, the GDA is a black-hole from the management point of view. Cheers Glenn >>From S.Kille@isode.com Tue Jun 21 22:32:04 1994 >>To: Glenn Mansfield >>Cc: ietf-madman@innosoft.com >>Subject: Re: MADMAN status .. >> >>I believe that there are a number of issues that will need to be >>addressed. However, I do not think that we are far enough down >>the implementation track to justify this. I will be happy to hear >>views to the contrary, provided that they indicate clearly the technical >>work that they see the group should do. >> >> >>Steve >> >>