Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20527; 7 Jun 93 6:12 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20523; 7 Jun 93 6:12 EDT Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa25622; 7 Jun 93 6:12 EDT X400-Received: by mta mhs-relay.cs.wisc.edu in /PRMD=XNREN/ADMD= /C=US/; Relayed; Mon, 7 Jun 1993 05:10:44 +0000 Date: Mon, 7 Jun 1993 05:10:44 +0000 X400-Originator: ietf-osi-x400ops-req@cs.wisc.edu X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=XNREN/ADMD= /C=US/;mhs-relay..522:07.05.93.10.10.44] Priority: Non-Urgent DL-Expansion-History: ietf-osi-x400ops@cs.wisc.edu ; Mon, 7 Jun 1993 05:10:43 +0000; Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alf Hansen Message-ID: <"4157*/G=Alf/S=Hansen/OU=delab/O=sintef/PRMD=uninett/ADMD= /C=no/"@MHS> To: ietf-osi-x400ops@cs.wisc.edu Subject: Agenda items, X.400 OPS WG meeting at the Amsterdam IETF. Hi, I am enclosing the current full agenda for the Amsterdam IETF. Our meeting's schedule: WEDNESDAY, 14 July 1993 0900-1200 Morning Sessions APP X.400 Operations WG (x400ops) (Alf Hansen/Sintef and Tony Genovese/LLNL) Breaks Coffee available throughout morning. 1330-1530 Afternoon Sessions I APP X.400 Operations WG (x400ops) (Alf Hansen/Sintef and Tony Genovese/LLNL) THURSDAY, 15 July 1993 0930-1200 Morning Sessions APP X.400 Operations WG (x400ops) (Alf Hansen/Sintef and Tony Genovese/LLNL) We would welcome your proposals for important agenda items, either directly to us or to the full list. Please submit your proposals not later than July 2nd. Thanks, Alf Hansen Tony Genovese Alf.Hansen@delab.sintef.no genovese@ophelia.nersc.gov x400ops WG Co-chairs ============================================================================= Agenda of the Twenty-Seventh IETF - as of 5/11/93 - 5:30pm (12-16 July 1993) MONDAY, 12 July 1993 0800-0900 IETF Registration and Continental Breakfast 0900-0930 Introductions 0930-1200 Technical Presentations o TBD Breaks Coffee available throughout morning. 1330-1530 Afternoon Sessions I APP OSI Directory Services WG (osids) (Steve Hardcastle-Kille/ISODE) INT IP over ATM WG (atm) (Bob Hinden/Sun) RTG Border Gateway Protocol WG (bgp) (Yakov Rekhter/IBM)* RTG OSI IDRP for IP over IP WG (ipidrp) (Sue Hares/Merit)* OPS Operational Statistics WG (opstat) (Phill Gross/ANS and Bernhard Stockman/SUNET) SEC Security Area Advisory Group (saag) (Steve Crocker/TIS) USV WHOIS and Network Information Lookup Service WG (wnils) (Joan Gargano/UCDavis) 1530-1600 Break (Refreshments provided) 1600-1800 Afternoon Sessions II APP OSI Directory Services WG (osids) (Steve Hardcastle-Kille/ISODE) INT Simple Internet Protocol WG (sip) (Steve Deering/Xerox PARC and Christian Huitema/INRIA) OPS Operational Statistics WG (opstat) (Phill Gross/ANS and Bernhard Stockman/SUNET) USV Uniform Resource Identifiers WG (uri) (Alan Emtage/Bunyip and Jim Fullton/UNC) 1930-2200 Evening Sessions INT IP over Large Public Data Networks WG (iplpdn) (George Clapp/Ameritech) MGT Mail and Directory Management WG (madman) (Steve Hardcastle-Kille/UCL) USV Integration of Internet Information Resources WG (iiir) (Chris Weider/Merit) NOTE: Monday evening's sessions may be moved as the IETF Social has been scheduled at that time. TUESDAY, 13 July 1993 0830-0900 Continental Breakfast 0900-1200 Morning Sessions APP Conferencing Control (mmusic) (Eve Schooler/ISI and Abel Weinrib/Bellcore) INT P. Internet Protocol WG (pip) (Paul Francis/Bellcore) MGT NM Directorate (nmdir) (Marshall Rose/DBC) USV Integrated Directory Services WG (ids) (Tim Howes/UMich and Chris Weider/Merit) USV User Services WG (uswg) (Joyce K. Reynolds/ISI) Breaks Coffee available throughout morning. 1330-1530 Afternoon Sessions I APP MHS-DS WG (mhsds) (Kevin Jordan/CDC and Harald Alvestrand/SINTEF DELAB) INT IP over ATM WG (atm) (Bob Hinden/Sun) INT P. Internet Protocol WG (pip) (Paul Francis/Bellcore) USV Uniform Resource Identifiers WG (uri) (Alan Emtage/Bunyip and Jim Fullton/UNC) 1530-1600 Break (Refreshments provided) 1600-1800 Afternoon Sessions II APP MHS-DS WG (mhsds) (Kevin Jordan/CDC and Harald Alvestrand/SINTEF DELAB) INT IP over Large Public Data Networks WG (iplpdn) (George Clapp/Ameritech) INT Point-to-Point Protocol Extensions WG (pppext) (Fred Baker/ACC) * INT TCP/UDP over CLNP-addressed Networks WG (tuba) (Peter Ford/LANL and Mark Knopper/Merit) RTG Border Gateway Protocol WG (bgp) (Yakov Rekhter/IBM)* RTG OSI IDRP for IP over IP WG (ipidrp) (Sue Hares/Merit)* USV User Documents WG (userdoc2) (Ellen Hoffman/UMich and Lenore Jackson/NASA) 1930-2200 Tuesday, 13 July 1993 - Evening Sessions WEDNESDAY, 14 July 1993 0830-0900 Continental Breakfast 0900-1200 Morning Sessions APP Conferencing Control (mmusic) (Eve Schooler/ISI and Abel Weinrib/Bellcore) APP X.400 Operations WG (x400ops) (Alf Hansen/Sintef and Tony Genovese/LLNL) INT IP over Large Public Data Networks WG (iplpdn) (George Clapp/Ameritech)* INT Point-to-Point Protocol Extensions WG (pppext) (Fred Baker/ACC) * RTG Source Demand Routing Protocol (sdr) (Deborah Estrin/USC and Tony Li/cisco) USV Uniform Resource Identifiers WG (uri) (Alan Emtage/Bunyip and Jim Fullton/UNC) Breaks Coffee available throughout morning. 1330-1530 Afternoon Sessions I APP X.400 Operations WG (x400ops) (Alf Hansen/Sintef and Tony Genovese/LLNL) INT IP over ATM WG (atm) (Bob Hinden/Sun) INT Inter-Domain Multicast Routing BOF (idmr) (Tony Ballardie/UCL) MGT Chassis MIB WG (chassis) (Bob Stewart/Xyplex) SEC Privacy-Enhanced Electronic Mail WG (pem) (Steve Kent/BBN) USV Networked Information Retrieval WG (nir) (Jill Foster/UNewcastle-Upon-Tyne and George Brett/MCNC) 1530-1600 Break (Refreshments provided) 1600-1800 Afternoon Sessions II MGT IFIP Electronic Mail Management BOF (emailmgt) (Einar Stefferud/NMA and Paul Brusil/MITRE) RTG IP Routing for Wireless/Mobile Hosts WG (mobileip) (Steve Deering/Xerox PARC) SEC Authorization and Access Control BOF (aac) (Cliff Neuman/ISI) USV Network Information Services Infrastructure WG (nisi) (April Marine/SRI and Pat Smith/Merit) 1930-2200 Wednesday, 14 July 1993 - Evening Session INT IPng Decision Process BOF (ipdecide) (Brian Carpenter/CERN and Tim Dixon/RARE) MGT IFIP Electronic Mail Management BOF (emailmgt) (Einar Stefferud/NMA and Paul Brusil/MITRE) * IPLPDN and PPPEXT will be meeting in joint session. THURSDAY, 15 July 1993 0830-0900 Continental Breakfast 0900-0930 Technical Presentations o TBD 0930-1200 Morning Sessions APP Minimal OSI Upper-Layers WG (thinosi) (Peter Furniss/Consultant) APP X.400 Operations WG (x400ops) (Alf Hansen/Sintef and Tony Genovese/LLNL) INT Point-to-Point Protocol Extensions WG (pppext) (Fred Baker/ACC) * RTG IP Routing for Wireless/Mobile Hosts WG (mobileip) (Steve Deering/Xerox PARC) USV Network Training Materials WG (trainmat) (Ellen Hoffman/Merit and Jill Foster/UNewcastle-Upon-Tyne) Breaks Coffee available throughout the morning. 1330-1530 Afternoon Sessions I MGT IFIP Electronic Mail Management BOF (emailmgt) (Einar Stefferud/NMA and Paul Brusil/MITRE) OPS Operational Area Directorate (orad) (Phill Gross/ANS and Bernhard Stockman/SUNET) RTG Multicast Extensions to OSPF WG (mospf) (Steve Deering/Xerox PARC) SEC Security Area Advisory Group (saag) (Steve Crocker/TIS) USV Internet School Networking WG (isn) (John Clement/EDUCOM, Connie Stout/TheNet and Art St. George/UNM) 1530-1600 Break (Refreshments provided) 1600-1800 Technical Presentations o TBD 1930-2200 Open Plenary and IESG NOTE: Plenary may be shifted to Friday. FRIDAY, 16 July 1993 0830-0900 Continental Breakfast 0900-1200 Technical Presentations TBD   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02802; 23 Jun 93 8:49 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02798; 23 Jun 93 8:49 EDT Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa07009; 23 Jun 93 8:49 EDT X400-Received: by mta mhs-relay.cs.wisc.edu in /PRMD=XNREN/ADMD= /C=US/; Relayed; Wed, 23 Jun 1993 07:32:27 +0000 Date: Wed, 23 Jun 1993 07:32:27 +0000 X400-Originator: ietf-osi-x400ops-req@cs.wisc.edu X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=XNREN/ADMD= /C=US/;mhs-relay..997:23.05.93.12.32.27] Priority: Non-Urgent DL-Expansion-History: ietf-osi-x400ops@cs.wisc.edu ; Wed, 23 Jun 1993 07:32:25 +0000; Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Urs Eppenberger Message-ID: <2267*/S=Eppenberger/O=switch/PRMD=SWITCH/ADMD=ARCOM/C=CH/@MHS> To: ietf-osi-x400ops Subject: next IETF: Agenda items I did not see any agenda item yet on the list, maybe Alf's mailbox contains a lot of personal suggestions? Anyhow, here is a topic: Internet Mail <-> public X.400 services Should we propose on how such gateways should be implemented? - mapping - routing - accounting (?) - service quality - ... Maybe this potato is too hot. Kind regards, Urs.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04901; 23 Jun 93 9:51 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04897; 23 Jun 93 9:51 EDT Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa09489; 23 Jun 93 9:51 EDT Received: from cs.wisc.edu by mhs-relay.cs.wisc.edu with SMTP (PP) id <04202-0@mhs-relay.cs.wisc.edu>; Wed, 23 Jun 1993 08:18:28 +0000 Received: from danpost.uni-c.dk by cs.wisc.edu; Wed, 23 Jun 93 08:18:18 -0500 Received: from uts.uni-c.dk by danpost.uni-c.dk (5.65c+/1.34) id AA15879; Wed, 23 Jun 1993 15:18:12 +0200 Received: by uts.uni-c.dk (/\../\ Smail3.1.14.4 #14.10) id ; Wed, 23 Jun 93 15:18 CET Message-Id: Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Erik Lawaetz Subject: Re: next IETF: Agenda items To: Urs Eppenberger Date: Wed, 23 Jun 93 15:18:29 CET Cc: ietf-osi-x400ops@cs.wisc.edu In-Reply-To: <2267*/S=Eppenberger/O=switch/PRMD=SWITCH/ADMD=ARCOM/C=CH/@MHS>; from "Urs Eppenberger" at Jun 23, 93 2:32 pm Organisation: UNI-C X-Address: Building 305 DTH, DK-2800 Lyngby, Denmark X-Phone: +45 45 93 83 55 X-Fax: +45 45 93 02 20 X-Mailer: ELM [version 2.3 PL11] > Internet Mail <-> public X.400 services > Should we propose on how such gateways should be implemented? > - mapping > - routing > - accounting (?) > - service quality > - ... We should at least discuss it, and exchange experiences. Whether we can come up with a recommendation I don't know. --Erik   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10585; 23 Jun 93 13:25 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10581; 23 Jun 93 13:25 EDT Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa17555; 23 Jun 93 13:25 EDT X400-Received: by mta mhs-relay.cs.wisc.edu in /PRMD=XNREN/ADMD= /C=US/; Relayed; Wed, 23 Jun 1993 11:58:21 +0000 Date: Wed, 23 Jun 1993 11:58:21 +0000 X400-Originator: ietf-osi-x400ops-req@cs.wisc.edu X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=XNREN/ADMD= /C=US/;mhs-relay..082:23.05.93.16.58.21] Priority: Non-Urgent DL-Expansion-History: ietf-osi-x400ops@cs.wisc.edu ; Wed, 23 Jun 1993 11:58:21 +0000; Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: " (Tony Genovese)" Message-ID: <9306231658.AA13405@ophelia.nersc.gov> To: ietf-osi-x400ops@cs.wisc.edu Subject: Re: next IETF: Agenda items > Anyhow, here is a topic: > Internet Mail <-> public X.400 services > Should we propose on how such gateways should be implemented? > - mapping > - routing > - accounting (?) > - service quality > - ... > > Maybe this potato is too hot. I beleave it was a tad hot last time we discussed it. This, if I remember, is what started the A=IMX spin. But, I would love to revisit this topic with a view to come to some international consensus on Public X.400 access for Internet mail. Tony...   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01663; 24 Jun 93 5:44 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01659; 24 Jun 93 5:44 EDT Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa04493; 24 Jun 93 5:44 EDT X400-Received: by mta mhs-relay.cs.wisc.edu in /PRMD=XNREN/ADMD= /C=US/; Relayed; Thu, 24 Jun 1993 04:24:43 +0000 Date: Thu, 24 Jun 1993 04:24:43 +0000 X400-Originator: ietf-osi-x400ops-req@cs.wisc.edu X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=XNREN/ADMD= /C=US/;mhs-relay..661:24.05.93.09.24.43] Priority: Non-Urgent DL-Expansion-History: ietf-osi-x400ops@cs.wisc.edu ; Thu, 24 Jun 1993 04:24:42 +0000; Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alf Hansen Message-ID: <"4240*/G=Alf/S=Hansen/OU=delab/O=sintef/PRMD=uninett/ADMD= /C=no/"@MHS> To: Urs Eppenberger Cc: ietf-osi-x400ops@cs.wisc.edu In-Reply-To: <2267*/S=Eppenberger/O=switch/PRMD=SWITCH/ADMD=ARCOM/C=CH/@MHS> Subject: Re: next IETF: Agenda items Urs, > I did not see any agenda item yet on the list, maybe Alf's mailbox contains > a lot of personal suggestions? No, this is the first one. Where have all the people gone? > Anyhow, here is a topic: > Internet Mail <-> public X.400 services > Should we propose on how such gateways should be implemented? > - mapping > - routing > - accounting (?) > - service quality > - ... > > Maybe this potato is too hot. > I think this is a good topic. Best regards, Alf H   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07207; 24 Jun 93 11:17 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07199; 24 Jun 93 11:17 EDT Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa14029; 24 Jun 93 11:17 EDT Received: from cs.wisc.edu by mhs-relay.cs.wisc.edu with SMTP (PP) id <08896-0@mhs-relay.cs.wisc.edu>; Thu, 24 Jun 1993 09:55:24 +0000 Received: from simpukka.funet.fi by cs.wisc.edu; Thu, 24 Jun 93 09:55:20 -0500 Received: by simpukka.funet.fi with SMTP id AA09059 (5.65c/IDA-1.4.4 for ); Thu, 24 Jun 1993 17:55:17 +0300 Message-Id: <199306241455.AA09059@simpukka.funet.fi> To: ietf-osi-x400ops@cs.wisc.edu Subject: Re: next IETF: Agenda items In-Reply-To: Your message of "Thu, 24 Jun 1993 12:24:43 +0300." <"4240*/G=Alf/S=Hansen/OU=delab/O=sintef/PRMD=uninett/ADMD= /C=no/"@MHS> Date: Thu, 24 Jun 1993 17:55:16 +0300 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Marko Kaittola Alf Hansen writes: >No, this is the first one. Where have all the people gone? Haven't you yet noticed that no-one (but Urs, maybe) answears if you aren't twisting their hands behind their backs? (No, I'm not adding a smiley. This isn't a bit funny.) But to get to the point: - I would obviously like to discuss my paper on table distribution. - I would like to discuss terms GO-MHS and COSINE-MHS. As there is no Cosine the latter isn't appropriate any longer, while the first one doesn't sound good while talking with funders and ADMDs. Even if we call our community GO-MHS we *must* have a name for it that sounds good. - I would like to discuss interaction with GO-MHS and commercial ADMDs. This is something that can't be separated from discussion about Internet-SMTP / ADMDs. - I would also like to see what kind of tools do we have and if we could distribute them more. It doesn't seem to make sense to invent a wheel again and again. - Marko   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16686; 24 Jun 93 17:24 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16682; 24 Jun 93 17:24 EDT Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa27017; 24 Jun 93 17:24 EDT Received: from cs.wisc.edu by mhs-relay.cs.wisc.edu with SMTP (PP) id <09903-0@mhs-relay.cs.wisc.edu>; Thu, 24 Jun 1993 16:05:46 +0000 Received: from relay2.UU.NET by cs.wisc.edu; Thu, 24 Jun 93 16:05:33 -0500 Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA05994; Thu, 24 Jun 93 17:04:12 -0400 Received: from starnine.UUCP by spool.uu.net with UUCP/RMAIL (queueing-rmail) id 170258.24489; Thu, 24 Jun 1993 17:02:58 EDT Received: from mac_smtp by starnine.starnine.com (5.64/SMI-3.2) id AA24975; Thu, 24 Jun 93 13:06:43 PDT Message-Id: <9306242006.AA24975@starnine.starnine.com> Date: 24 Jun 1993 13:50:27 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Phil Chang Subject: Re: next IETF- Agenda items To: Alf Hansen , Einar Stefferud , Urs Eppenberger Cc: ietf-osi-x400ops@cs.wisc.edu Reply to: RE>>next IETF: Agenda items It seems there is a need for concrete gateway standards between X.400 and SMTP/MIME body parts, especially when considering binary attachments. I believe Stef would have some comments regarding this? Would other IETF working groups be appropriate recipients of this message? If so, please forward. Phil Inje Chang Director of Marketing StarNine Technologies, Inc. phil@starnine.com AppleLink: STARNINE 510-649-4949 -------------------------------------- Date: 6/24/93 8:00 AM To: Phil Chang From: Alf Hansen Urs, > I did not see any agenda item yet on the list, maybe Alf's mailbox contains > a lot of personal suggestions? No, this is the first one. Where have all the people gone? > Anyhow, here is a topic: > Internet Mail <-> public X.400 services > Should we propose on how such gateways should be implemented? > - mapping > - routing > - accounting (?) > - service quality > - ... > > Maybe this potato is too hot. > I think this is a good topic. Best regards, Alf H ------------------ RFC822 Header Follows ------------------ Received: by mac_smtp.starnine.com with SMTP;24 Jun 1993 08:00:40 -0800 Received: from mhs-relay.cs.wisc.edu by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA09379; Thu, 24 Jun 93 05:48:15 -0400 X400-Received: by mta mhs-relay.cs.wisc.edu in /PRMD=XNREN/ADMD= /C=US/; Relayed; Thu, 24 Jun 1993 04:24:43 +0000 Date: Thu, 24 Jun 1993 04:24:43 +0000 X400-Originator: ietf-osi-x400ops-req@cs.wisc.edu X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=XNREN/ADMD= /C=US/;mhs-relay..661:24.05.93.09.24.43] Priority: Non-Urgent Dl-Expansion-History: ietf-osi-x400ops@cs.wisc.edu ; Thu, 24 Jun 1993 04:24:42 +0000; From: Alf Hansen Message-Id: <"4240*/G=Alf/S=Hansen/OU=delab/O=sintef/PRMD=uninett/ADMD= /C=no/"@MHS> To: Urs Eppenberger Cc: ietf-osi-x400ops@cs.wisc.edu In-Reply-To: <2267*/S=Eppenberger/O=switch/PRMD=SWITCH/ADMD=ARCOM/C=CH/@MHS> Subject: Re: next IETF: Agenda items   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18184; 24 Jun 93 18:28 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18180; 24 Jun 93 18:28 EDT Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa29004; 24 Jun 93 18:28 EDT Received: from cs.wisc.edu by mhs-relay.cs.wisc.edu with SMTP (PP) id <09956-0@mhs-relay.cs.wisc.edu>; Thu, 24 Jun 1993 16:35:03 +0000 Received: from survis.surfnet.nl by cs.wisc.edu; Thu, 24 Jun 93 16:34:47 -0500 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <09233-0@survis.surfnet.nl>; Thu, 24 Jun 1993 23:33:04 +0200 To: Phil Chang Cc: Alf Hansen , Einar Stefferud , Urs Eppenberger , ietf-osi-x400ops@cs.wisc.edu Subject: Re: next IETF- Agenda items In-Reply-To: Your message of Thu, 24 Jun 93 23:50:27 +0200. <9306242006.AA24975@starnine.starnine.com> Organisation: SURFnet bv Address: Cluetinckborch, P.O. Box 19035, 3501 DA Utrecht, NL Phone: +31 30 310290 Telefax: +31 30 340903 Date: Thu, 24 Jun 93 23:33:02 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Erik Huizer (SURFnet BV)" Message-Id: <"survis.sur.237:24.05.93.21.33.06"@surfnet.nl> These have already been defined, by the mime-mhs Working Group. They were approved today by the IESG, and so you can expect them as proposed standard RFCs pretty soon now. Erik   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18498; 24 Jun 93 18:50 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18494; 24 Jun 93 18:50 EDT Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa29630; 24 Jun 93 18:50 EDT Received: from cs.wisc.edu by mhs-relay.cs.wisc.edu with SMTP (PP) id <10053-0@mhs-relay.cs.wisc.edu>; Thu, 24 Jun 1993 17:11:53 +0000 Received: from THOR.INNOSOFT.COM by cs.wisc.edu; Thu, 24 Jun 93 17:11:47 -0500 Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-13 #1336) id <01GZQESDW3M88WW012@INNOSOFT.COM>; Thu, 24 Jun 1993 14:54:42 PDT Date: Thu, 24 Jun 1993 14:52:42 -0700 (PDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ned Freed Subject: RE: next IETF- Agenda items In-Reply-To: Your message dated "Thu, 24 Jun 1993 13:50:27 -0800" <9306242006.AA24975@starnine.starnine.com> To: Phil Chang Cc: Alf Hansen , Einar Stefferud , Urs Eppenberger , ietf-osi-x400ops@cs.wisc.edu Message-Id: <01GZRDYN48UW8WW012@INNOSOFT.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT > Reply to: RE>>next IETF: Agenda items > It seems there is a need for concrete gateway standards between X.400 and > SMTP/MIME body parts, especially when considering binary attachments. I > believe Stef would have some comments regarding this? This is already being dealt with by the MIME-MHS working group; it is not someting the X400 Operations Group needs to deal with. Indeed, the MIME-MHS working group has produced three Internet Drafts I expect to see as RFCs any time now, so much of the work is already done. Ned   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03968; 25 Jun 93 10:02 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03963; 25 Jun 93 10:02 EDT Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa09971; 25 Jun 93 10:02 EDT X400-Received: by mta mhs-relay.cs.wisc.edu in /PRMD=XNREN/ADMD= /C=US/; Relayed; Fri, 25 Jun 1993 08:58:34 +0000 Date: Fri, 25 Jun 1993 08:58:34 +0000 X400-Originator: ietf-osi-x400ops-req@cs.wisc.edu X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=XNREN/ADMD= /C=US/;mhs-relay..559:25.05.93.13.58.34] Priority: Non-Urgent DL-Expansion-History: ietf-osi-x400ops@cs.wisc.edu ; Fri, 25 Jun 1993 08:58:33 +0000; Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alf Hansen Message-ID: <"4249*/G=Alf/S=Hansen/OU=delab/O=sintef/PRMD=uninett/ADMD= /C=no/"@MHS> To: ietf-osi-x400ops@cs.wisc.edu Subject: Status my actions. Hi, Here is a status report for my actions from Columbus: - - - - - 4 Alf Hansen to send draft-ietf-x400ops-mgtdomains-ops-05.txt to the IESG secretariat with a copy to the Area Director Erik Huizer for consideration of the document as an Informational RFC. I did this in April and this is the last thing I heard abaout this from the IESG secretary: ========================================== Delivery-date: Tue, 20 Apr 1993 8:27:32 UTC+0200 From: Greg Vaudreuil To: Alf Hansen Cc: , In-Reply-To: ietf-ops:527 Importance: normal Message-ID: ietf-ops:528 9304191301.aa20866(a)IETF.CNRI.Reston.VA.US Subject: Re: draft-ietf-x400ops-mgtdomains-ops-05.txt --> Informational RFC. I have recorded this RFC as a IESG work item. With the appropriate Area Director review, it will likely be ready for approval at the next IESG meeting. Greg V. =========================================== I have to check what happened. Erik, do you know? - - - - 15 Tony Genovese and Alf Hansen to propose a revised version of the charter. Tony and I will do this shortly. Best regards, Alf H   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04660; 25 Jun 93 10:23 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04653; 25 Jun 93 10:23 EDT Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa10662; 25 Jun 93 10:23 EDT X400-Received: by mta mhs-relay.cs.wisc.edu in /PRMD=XNREN/ADMD= /C=US/; Relayed; Fri, 25 Jun 1993 08:50:28 +0000 Date: Fri, 25 Jun 1993 08:50:28 +0000 X400-Originator: ietf-osi-x400ops-req@cs.wisc.edu X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=XNREN/ADMD= /C=US/;mhs-relay..517:25.05.93.13.50.28] Priority: Non-Urgent DL-Expansion-History: ietf-osi-x400ops@cs.wisc.edu ; Fri, 25 Jun 1993 08:50:27 +0000; Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alf Hansen Message-ID: <"4248*/G=Alf/S=Hansen/OU=delab/O=sintef/PRMD=uninett/ADMD= /C=no/"@MHS> To: ietf-osi-x400ops@cs.wisc.edu Subject: Action list from Columbus. Just to remind people: Here is the action list from Columbus. I hope most of them will be done before the meeting in Amsterdam. Best regards, Alf H ============================================================================= Action list 1 Jim Romaguera to forward the questions from the ADMD operators to the X400-OPS list. 2 Erik Huizer to work out a possibility to base the coordination point for the GO-MHS community on a sound political basis. 3 The MHS Coordination Service to work out procedures for new members of the GO-MHS community to join the coordination service. 4 Alf Hansen to send draft-ietf-x400ops-mgtdomains-ops-05.txt to the IESG secretariat with a copy to the Area Director Erik Huizer for consideration of the document as an Informational RFC. 5 Claudio Allocchio to report to the X400-OPS group on the results of the discussion with IAB/IESG on the usage of DNS for mapping/routing tables. 6 Claudio Allocchio to update the documents draft-ietf-x400ops- dnsx400maps-02.txt and draft-ietf-x400ops-dnsx400rout-02.txt according the results of action point 5. 7 Claudio Allocchio to write a document on the implementation of the two proposals from action point 6. 8 Urs Eppenberger to wait for the decision of the IESG on his document, do the final modifications and send it to the RFC Editor. 9 Harald T. Alvestrand to send draft-ietf-x400ops-charactersets- 01.txt to the IESG secretariat with a copy to the Area Director Erik Huizer for consideration of the document as a Proposed Standard. 10 Marko Kaittola to update his document according the comments received, choose a new title and prepare a new version for the next IETF meeting in Amsterdam. 11 Einar Stefferud to integrate the final comments to the document draft-ietf-x400ops-admd-01.txt and then send it to the IESG Secretariat for consideration as an Informational RFC. 12 Jim Romaguera to update his document after a final call for comments and send it to the RFC Editor for consideration as Informational RFC. 13 Allan Cargille to send draft-ietf-x400ops-postmaster-01.txt to the IESG Secretariat with a copy to the Area Director Erik Huizer for consideration of the document as a Proposed Standard. 14 All WG members to send comments to the mapping authority paper in a timely fashion to the list or to Jeroen Houttuin to allow him to create a new version for the next RARE WG-MSG meeting at JENC 93 in Trondheim. 15 Tony Genovese and Alf Hansen to propose a revised version of the charter. 16 Erik Huizer to make sure that documents from other groups (esp. RARE WGs) will have the appropriate group name in the ID filename instead of the author's surname. =============================================================================   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04697; 25 Jun 93 10:24 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04693; 25 Jun 93 10:24 EDT Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa10701; 25 Jun 93 10:24 EDT X400-Received: by mta mhs-relay.cs.wisc.edu in /PRMD=XNREN/ADMD= /C=US/; Relayed; Fri, 25 Jun 1993 09:18:47 +0000 Date: Fri, 25 Jun 1993 09:18:47 +0000 X400-Originator: ietf-osi-x400ops-req@cs.wisc.edu X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=XNREN/ADMD= /C=US/;mhs-relay..659:25.05.93.14.18.47] Priority: Non-Urgent DL-Expansion-History: ietf-osi-x400ops@cs.wisc.edu ; Fri, 25 Jun 1993 09:18:46 +0000; Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Urs Eppenberger Message-ID: <2292*/S=Eppenberger/O=switch/PRMD=SWITCH/ADMD=ARCOM/C=CH/@MHS> To: ietf-osi-x400ops Subject: UE Re: Action list from Columbus. > 3 The MHS Coordination Service to work out procedures for new members > of the GO-MHS community to join the coordination service. I started to work on a new-procedures directory. Some documents have been updated. Some still need more work. It has not the very highest priority on my action list. > 8 Urs Eppenberger to wait for the decision of the IESG on his > document, do the final modifications and send it to the RFC Editor. Done: RFC1465 Urs.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05980; 25 Jun 93 11:26 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05976; 25 Jun 93 11:26 EDT Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa13019; 25 Jun 93 11:26 EDT X400-Received: by mta mhs-relay.cs.wisc.edu in /PRMD=XNREN/ADMD= /C=US/; Relayed; Fri, 25 Jun 1993 09:49:29 +0000 Date: Fri, 25 Jun 1993 09:49:29 +0000 X400-Originator: ietf-osi-x400ops-req@cs.wisc.edu X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=XNREN/ADMD= /C=US/;mhs-relay..753:25.05.93.14.49.29] Priority: Non-Urgent DL-Expansion-History: ietf-osi-x400ops@cs.wisc.edu ; Fri, 25 Jun 1993 09:49:25 +0000; Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jim Romaguera Message-ID: <9306251548.AA14259@netconsult.ch> To: " (Alf Hansen)" Cc: ietf-osi-x400ops@cs.wisc.edu In-Reply-To: <"4248*/G=Alf/S=Hansen/OU=delab/O=sintef/PRMD=uninett/ADMD= /C=no/"@MHS> Subject: Re: Action list from Columbus. X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 721 > > Just to remind people: Here is the action list from Columbus. I hope most of > them will be done before the meeting in Amsterdam. Thanks for the reminder. > > Best regards, > Alf H > ============================================================================= > Action list > > 1 Jim Romaguera to forward the questions from the ADMD operators to > the X400-OPS list. > Done (well sort of :-(..). I did not forward the questions onto this list but kept it to the wg-msg list (avoid multiple copies). I forgot to announce to this list that I had done that. I should have put it out on the ops list as well. I hope no one has been drastically inconvienced by this. If so I apologise for my oversight. JIm   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07254; 25 Jun 93 12:33 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07250; 25 Jun 93 12:33 EDT Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa15240; 25 Jun 93 12:33 EDT Received: from cs.wisc.edu by mhs-relay.cs.wisc.edu with SMTP (PP) id <13408-0@mhs-relay.cs.wisc.edu>; Fri, 25 Jun 1993 11:28:37 +0000 Received: from survis.surfnet.nl by cs.wisc.edu; Fri, 25 Jun 93 11:28:33 -0500 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <26466-0@survis.surfnet.nl>; Fri, 25 Jun 1993 18:07:53 +0200 Received: from localhost.surfnet.nl by survival.surfnet.nl (4.1/SMI-4.1(TV920629)) id AA00792; Fri, 25 Jun 93 18:07:54 +0200 Message-Id: <9306251607.AA00792@survival.surfnet.nl> To: Alf Hansen Cc: ietf-osi-x400ops@cs.wisc.edu, John C Klensin Subject: Re: Status my actions. In-Reply-To: Your message of Fri, 25 Jun 93 15:58:34 +0200. <"4249*/G=Alf/S=Hansen/OU=delab/O=sintef/PRMD=uninett/ADMD= /C=no/"@MHS> Organisation: SURFnet bv Address: Cluetinckborch, P.O. Box 19035, 3501 DA Utrecht, NL Phone: +31 30 310290 Telefax: +31 30 340903 Date: Fri, 25 Jun 93 18:07:52 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Erik Huizer (SURFnet BV)" > I have to check what happened. Erik, do you know? Mea culpa, Mea Maxima culpa. The IESG secretariat keeps nagging me on this, it is not forgotten. However, you may have noticed that my co-area director Brewster has resigned due to time problems (he is starting up a new company). This means that between Columbus and now I have been the sole area director for applications. At the same time I have to do much more work on the Amsterdam IETF than I had foreseen (e.g. help restructuring E-bone). Add to that that MIME, MIMEMHS, and several other docs came up for revision, and You can maybe understand why I am behind on reviews. Unfortunately my Directorate does not seem to be in much better state, so they did not help either. Fortunately John Klensin has now taken up position as interim co-AD, and he is a big help. The following docs from this group are on my to-do list, and John will help out where he can: PRMD requirements doc (first in queue) RFC-1327 tutorial A=IMX (done, I'll get back on this). I'll try and get the PRMD requirements finished before the IETF, John has promised to help. Erik   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19988; 28 Jun 93 3:41 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19984; 28 Jun 93 3:41 EDT Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa20901; 28 Jun 93 3:41 EDT X400-Received: by mta mhs-relay.cs.wisc.edu in /PRMD=XNREN/ADMD= /C=US/; Relayed; Mon, 28 Jun 1993 02:25:06 +0000 Date: Mon, 28 Jun 1993 02:25:06 +0000 X400-Originator: ietf-osi-x400ops-req@cs.wisc.edu X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=XNREN/ADMD= /C=US/;mhs-relay..950:28.05.93.07.25.06] Priority: Non-Urgent DL-Expansion-History: ietf-osi-x400ops@cs.wisc.edu ; Mon, 28 Jun 1993 02:25:05 +0000; Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Alf Hansen Message-ID: <"4252*/G=Alf/S=Hansen/OU=delab/O=sintef/PRMD=uninett/ADMD= /C=no/"@MHS> To: "Erik Huizer (SURFnet BV)" Cc: IPM Return Requested , John C Klensin In-Reply-To: <9306251607.AA00792@survival.surfnet.nl> Subject: Re: Status my actions. > I'll try and get the PRMD requirements finished before the IETF, John has > promised to help. Thanks Erik and John. I certainly know that you have a hard time with all these documents in paralell with the Amsterdam preparations. Best regards, Alf H   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26253; 28 Jun 93 11:08 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26249; 28 Jun 93 11:08 EDT Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa02505; 28 Jun 93 11:08 EDT Received: from cs.wisc.edu by mhs-relay.cs.wisc.edu with SMTP (PP) id <20449-0@mhs-relay.cs.wisc.edu>; Mon, 28 Jun 1993 10:02:37 +0000 Received: from survis.surfnet.nl by cs.wisc.edu; Mon, 28 Jun 93 10:02:27 -0500 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <14366-0@survis.surfnet.nl>; Mon, 28 Jun 1993 17:02:18 +0200 Received: from localhost.surfnet.nl by survival.surfnet.nl (4.1/SMI-4.1(TV920629)) id AA02147; Mon, 28 Jun 93 17:02:05 +0200 Message-Id: <9306281502.AA02147@survival.surfnet.nl> To: ietf-osi-x400ops@cs.wisc.edu Subject: Re: Action list from Columbus. In-Reply-To: Your message of Sat, 26 Jun 93 08:16:02 +0200. <4040.741248162@odin.nma.com> Organisation: SURFnet bv Address: Cluetinckborch, P.O. Box 19035, 3501 DA Utrecht, NL Phone: +31 30 310290 Telefax: +31 30 340903 Date: Mon, 28 Jun 93 17:02:04 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Erik Huizer (SURFnet BV)" My action item, to create a political support for global GO-MHS coordination is still under way. I have talked to a lot of people about this,. So far the people concerned are too involved with infrastructural matters like 34 Mb/s lines, to give the matter much attention. However I'll continue to work on this. Keep it as an ongoing action item on my part. Erik   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26604; 28 Jun 93 11:23 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26599; 28 Jun 93 11:23 EDT Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa03004; 28 Jun 93 11:23 EDT Received: from cs.wisc.edu by mhs-relay.cs.wisc.edu with SMTP (PP) id <20215-0@mhs-relay.cs.wisc.edu>; Mon, 28 Jun 1993 09:48:28 +0000 Received: from ics.uci.edu by cs.wisc.edu; Mon, 28 Jun 93 09:48:23 -0500 Received: from nma.com by q2.ics.uci.edu id ab20449; 28 Jun 93 6:17 PDT Received: from localhost by odin.nma.com id aa04042; 27 Jun 93 23:16 PDT To: ietf-osi-x400ops@cs.wisc.edu Subject: Re: Action list from Columbus. In-Reply-To: Your message of "Fri, 25 Jun 1993 08:50:28 -0000." <"4248*/G=Alf/S=Hansen/OU=delab/O=sintef/PRMD=uninett/ADMD= /C=no/"@MHS> Reply-To: Stef=x400@nma.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Einar Stefferud Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 27 Jun 1993 23:16:02 -0700 Message-Id: <4040.741248162@odin.nma.com> X-Orig-Sender: stef@nma.com I did this, and the IESG has taken it under consideration. 11 Einar Stefferud to integrate the final comments to the document draft-ietf-x400ops-admd-01.txt and then send it to the IESG Secretariat for consideration as an Informational RFC. The version under consideration is thjis one, as announced on 06/09 Internet-Drafts@c ID ACTION:draft-ietf-x400ops-admd-02.txt +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ A Revised Internet Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the X.400 Operations Working Group of the IETF. Title : Assertion of C=US; A=IMX Author(s) : E. Stefferud Filename : draft-ietf-x400ops-admd-02.txt Pages : 7 This document establishes an Internet Based X.400 Administrative Management Domain (ADMD) with the name "A=IMX", for use in the United States of America (C=US), according to the applicable rules of CCITT Recommendations and ISO Standards, and in keeping with existing regulatory practices in the United States of America. It also establishes a naming authority under the Internet Assigned Numbers Authority (IANA) to register and openly publish Private Management Domain (PRMD) names subordinate to A=IMX under C=US. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-x400ops-admd-02.txt". Internet-Drafts directories are located at: o East Coast (US) Address: ds.internic.net (198.49.45.10) o West Coast (US) Address: ftp.nisc.sri.com (192.33.33.22) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mail-server@nisc.sri.com. In the body type: "SEND draft-ietf-x400ops-admd-02.txt". For questions, please mail to internet-drafts@cnri.reston.va.us. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26627; 28 Jun 93 11:23 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26623; 28 Jun 93 11:23 EDT Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa03013; 28 Jun 93 11:23 EDT Received: from cs.wisc.edu by mhs-relay.cs.wisc.edu with SMTP (PP) id <20409-0@mhs-relay.cs.wisc.edu>; Mon, 28 Jun 1993 10:00:43 +0000 Received: from survis.surfnet.nl by cs.wisc.edu; Mon, 28 Jun 93 10:00:33 -0500 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <14188-0@survis.surfnet.nl>; Mon, 28 Jun 1993 17:00:01 +0200 Received: from localhost.surfnet.nl by survival.surfnet.nl (4.1/SMI-4.1(TV920629)) id AA02140; Mon, 28 Jun 93 16:59:45 +0200 Message-Id: <9306281459.AA02140@survival.surfnet.nl> To: Stef=x400@nma.com Cc: ietf-osi-x400ops@cs.wisc.edu, jstewart@CNRI.Reston.VA.US, Steve Coya , John C Klensin Subject: Re: Action list from Columbus. In-Reply-To: Your message of Sat, 26 Jun 93 08:16:02 +0200. <4040.741248162@odin.nma.com> Organisation: SURFnet bv Address: Cluetinckborch, P.O. Box 19035, 3501 DA Utrecht, NL Phone: +31 30 310290 Telefax: +31 30 340903 Date: Mon, 28 Jun 93 16:59:39 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Erik Huizer (SURFnet BV)" Stef, The IESG has considered the paper. The difficulty lays in the concept rather thamn tehe contents. It describes a national matter which may have sincere operational consequences for X.400 on the Internet as a whole. The IESG endorses the paper, but it has questions about the operational effect it will have. Therefore the IESG proposes to the WG to publish the paper as an experimental RFC. This also avoids standardizing a national matter, while giving it more cloud than just informational. The IESG hopes that experience with implementing this RFC will be documented by the WG and that it may lead to a general (internte wide) recommendation that can be put on the standards track in the future. Erik   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04552; 28 Jun 93 19:21 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04546; 28 Jun 93 19:21 EDT Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa18739; 28 Jun 93 19:21 EDT Received: from cs.wisc.edu by mhs-relay.cs.wisc.edu with SMTP (PP) id <21932-0@mhs-relay.cs.wisc.edu>; Mon, 28 Jun 1993 18:01:41 +0000 Received: from ics.uci.edu by cs.wisc.edu; Mon, 28 Jun 93 18:01:37 -0500 Received: from nma.com by q2.ics.uci.edu id ad21114; 28 Jun 93 15:57 PDT Received: from localhost by odin.nma.com id aa05463; 28 Jun 93 14:36 PDT To: "Erik Huizer (SURFnet BV)" Cc: ietf-osi-x400ops@cs.wisc.edu, jstewart@CNRI.Reston.VA.US, Steve Coya , John C Klensin Subject: Re: Action list from Columbus. In-Reply-To: Your message of "Mon, 28 Jun 1993 16:59:39 +0200." <9306281459.AA02140@survival.surfnet.nl> Reply-To: Stef@nma.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Einar Stefferud Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Jun 1993 14:36:40 -0700 Message-Id: <5461.741303400@odin.nma.com> X-Orig-Sender: stef@nma.com Hi Erik, et al -- The IESG has the correct view. I think Experimental is fine, but note that we need for the register it creates should not be an experimental register. The A=IMX PRMD Name register itself must be seen as permanent, though it is possible that A=IMX may not have a long and useful life. But, note that it is my objective to give it a long and useful life. I also note that progress has been reported on the move to establish C=WW in ISO 3166. If this ever happens, we should consider establishment of an International C=WW; A= (maybe A=IMX), and I see our C=US "experiment" as useful in this progression. In any case, I want to report that to a very large extent, Allan Cargille, Steve Kille, and I have managed to resolve our greatest differences regarding the entire concept of allowing any ADMD to be formed by other than those institutions blessed by the CCITT. This should close the argument that erupted in the x400ops WG at the Washington IETF. (I thought it had been closed already at Columbus;-) What we are approaching is a clash between two major paradigms (Monopoly PTT and Open Internet), and A=IMX is an experiment that will take place in the midst of the battlefield. Not that I want to scare anyone off! We need all the help we can get! I regret not being able to attend the IETF in Amsterdam, however, I will be busy that same week attending the US-NMTS meeting near LAX, so I will remain in the game;-). I am also planning to collaborate much more closely with Allan Cargille in the NSF UWisc X.400 project. So... Onward...\Stef From your message Mon, 28 Jun 93 16:59:39 +0200: } } }Stef, } }The IESG has considered the paper. The difficulty lays in the concept rather }thamn tehe contents. It describes a national matter which may have sincere }operational consequences for X.400 on the Internet as a whole. The IESG }endorses the paper, but it has questions about the operational effect it }will have. Therefore the IESG proposes to the WG to publish the paper as an }experimental RFC. This also avoids standardizing a national matter, while }giving it more cloud than just informational. } }The IESG hopes that experience with implementing this RFC will be documented }by the WG and that it may lead to a general (internte wide) recommendation }that can be put on the standards track in the future. } }Erik   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13116; 29 Jun 93 1:44 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13112; 29 Jun 93 1:44 EDT Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa27093; 29 Jun 93 1:44 EDT Received: from cs.wisc.edu by mhs-relay.cs.wisc.edu with SMTP (PP) id <22482-0@mhs-relay.cs.wisc.edu>; Tue, 29 Jun 1993 00:31:26 +0000 Received: from ics.uci.edu by cs.wisc.edu; Tue, 29 Jun 93 00:31:19 -0500 Received: from nma.com by q2.ics.uci.edu id aa22770; 28 Jun 93 22:21 PDT Received: from localhost by odin.nma.com id aa06034; 28 Jun 93 22:14 PDT To: ietf-osi-x400ops@cs.wisc.edu Subject: ADMD vs INTERNET -- Re: next IETF: Agenda items In-Reply-To: Your message of "Thu, 24 Jun 1993 04:24:43 -0000." <"4240*/G=Alf/S=Hansen/OU=delab/O=sintef/PRMD=uninett/ADMD= /C=no/"@MHS> Reply-To: Stef=x400@nma.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Einar Stefferud Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Jun 1993 22:14:32 -0700 Message-Id: <6032.741330872@odin.nma.com> X-Orig-Sender: stef@nma.com OK -- I will take a shot at it;-)... From your message Thu, 24 Jun 1993 04:24:43 +0000: } }> Anyhow, here is a topic: }> Internet Mail <-> public X.400 services }> Should we propose on how such gateways should be implemented? }> - mapping }> - routing }> - accounting (?) }> - service quality }> - ... }> }> Maybe this potato is too hot. Let's start with recognition of a vast difference in the basic paradigms involved by different parties. And with vastly different business models, and vastly different economic interests for the different parties. 1. The Internet is "owned" by more than 12,000 individual owners, who each own and operate their "owned" part (subnet). Sometimes this subnet looks like a leaf, and sometimes it looks like a segment of the backbone. Each owner is responsible for the quality of service it offers to anyone who connects to or through the owners subnet/segment/leaf. The result is distributed responsibility for overall quality of service. We witness many poorly managed leafnets whose users complain loudly about the low quality of Internet Service (mail included) when every other involved subnet is well managed and enjoying high quality service. As a mailing list sponsor, I can provide many megabytes of EMail traffic to back up what I say here. Typically, the complaining person is the victim of locally bad service support, most frequently untended local DNS records. The Internet Business Model is one where each subscriber is responsible for her/his own leaf network, or attached service host. Also note that directionality of traffic is of no concern, since the total fee for connection service does not distinguish any directionality in terms of maximum pipe capacity. In other words, every end-leaf pays for all traffic, in either direction, without regard to direction. It is not the case that outbound traffic generates charges, while inbound traffic is free. (Compare this with ADMD Service Provider pricing;-). Actually, the buyer of Internet connection service does not buy quantities of transmitted traffic. Generally the buyer contracts for and receives a potential capacity, which is then realized to some level of satisfaction. In this business model, the network connection is a wasting asset, which if not used, is wasted, like water from a spring with no storage reservoir to capture and hold what is not used. The connection customer buys into the risk of underutilzation, which is then not born by the Connection Service Provider. 2. ADMD Service Providers are generally owned by a single entity, with a central management concerned with the owned network, and with clearly demarcated boundaries, beyond which all problems are "somebody else's problem" (aka an SEP). ADMD Service Providers like to talk a lot about quality of service, but they are only talking about the quality of service provided by what they own. They do not generally concern themselves with what is beyond their pointof demarcation. (Well, there are sometimes requirements on customers, such as the TELEX requirement for the customer to always keep their TTY "online". The internet does not make this a contractual requirment, but connection customers soon learn that falling off the net is very very bad for them and for their business. Note that SEP technology does not work in the Internet. If the other end of your Internet connection is not well managed, your service quality suffers along with that of the other end. 3. It is my opinion that the ADMD Service Providers have not yet fully faced the real issues of being participants in an X.400 "internet". Look at the X.400 network diagrams in F.400 and tell me how you distinguish those pictures from an Internet with routing relays mounted between autonomously owned subnet domains? 4. So how are we going to deal with (negotiate, contract, interoperate, interwork) with the Internet on one side, and the collection of ADMD Service Providers on the other? What does a contract between an ADMD Service Provider and 12,000 Internet owners look like? Who gets to speak for The Internet? I suggest that this is not a really new question! Who, I ask, speaks for all the customers in an open competitive marketplace? AHA! ... I hear you saying ... That's the rub, isn't it? My answer is "Tell the ADMD Service Providers that they have the opportunity to connect to the the Internet, just like anyone else, and with that access to all 12,000+ Owners of Internet Subnets, viewed as an open market, go forth and sell their ADMD Services to all who will buy, using the Internet to connect to them. You might also tell them about the huge growing Interent marketplace for Inforamtion Services that is available to them just by buying one connection the the whole massive Internet. (Or maybe we shoudl keep that a secret for a bit longer so us consultants can make some money from this inside information?) In the meantime, also point out to them how much money they can make buy selling EMail services to people who want access to the Internet. All they have to do is set up their charging schemes to be direction insensitive, so they no longer care what direction the traffic to/from their customers is flowing (just like in the Internet). The reason for this is, that this is a characteristic of the Internet Marketplace, and not an arbitrary choice made by any one of the 12,000+ Internet Owners. The Internet should be viewed by the ADMD Service Providers more or less like a shopping mall, or a marketplace. Each seller of services buys access and egress rights to the mall or market, and then attracts customers who buy services. Customers, likewise, gain access to the mall or marketplace, at their own expense, perhaps using shared public streets paid for by both buyers and sellers. That is, the buyer maintains his/her own residence and auto plus garage and access/egress to the public streets, just like the service vendor does. 5. Well, enough for now. I am sure this will start your thoughts running, or your adrenaline flowing, or whatever you use for juice. The key question should not become lost here. I think it is... "How are the ADMD Service Providers going to find a way to interface with the Internet Marketplace?" I am sure there are others who say it is... "How are the Internet Marketplace Customers/Users going to find a way to interface with the ADMD Service Providers?" I suggest that the answer will be generated by the Internet acting as a Marketplace, with the ADMD Service Providers acting like vendors. 6. And just one more thing. Let's not here a lot of foolish talk about how Internet EMail is free. It is not free. It is fully paid for by every leafnet owner, who pays for both sending and receiving! Cheers...\Stef   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01036; 29 Jun 93 7:01 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ah00997; 29 Jun 93 7:01 EDT Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa01613; 29 Jun 93 5:29 EDT Received: from cs.wisc.edu by mhs-relay.cs.wisc.edu with SMTP (PP) id <23519-0@mhs-relay.cs.wisc.edu>; Tue, 29 Jun 1993 04:12:13 +0000 Received: from survis.surfnet.nl by cs.wisc.edu; Tue, 29 Jun 93 04:12:09 -0500 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <18635-0@survis.surfnet.nl>; Tue, 29 Jun 1993 11:11:41 +0200 Received: from localhost.surfnet.nl by survival.surfnet.nl (4.1/SMI-4.1(TV920629)) id AA02795; Tue, 29 Jun 93 11:11:21 +0200 Message-Id: <9306290911.AA02795@survival.surfnet.nl> To: Stef@nma.com Cc: ietf-osi-x400ops@cs.wisc.edu, jstewart@CNRI.Reston.VA.US, Steve Coya , John C Klensin Subject: Re: Action list from Columbus. In-Reply-To: Your message of Mon, 28 Jun 93 14:36:40 -0700. <5461.741303400@odin.nma.com> Organisation: SURFnet bv Address: Cluetinckborch, P.O. Box 19035, 3501 DA Utrecht, NL Phone: +31 30 310290 Telefax: +31 30 340903 Date: Tue, 29 Jun 93 11:11:19 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Erik Huizer (SURFnet BV)" Stef, Is therew any chance that you can be at an AVT terminal during the x400ops sessions, if so, Alf could ask Megan for the X.400ops sessions to be scheduled for multicast AVT. Erik   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06948; 29 Jun 93 12:05 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06944; 29 Jun 93 12:05 EDT Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa13717; 29 Jun 93 12:05 EDT Received: from cs.wisc.edu by mhs-relay.cs.wisc.edu with SMTP (PP) id <24875-0@mhs-relay.cs.wisc.edu>; Tue, 29 Jun 1993 11:01:24 +0000 Received: from ics.uci.edu by cs.wisc.edu; Tue, 29 Jun 93 11:01:19 -0500 Received: from nma.com by q2.ics.uci.edu id ae19744; 29 Jun 93 8:59 PDT Received: from localhost by odin.nma.com id aa07016; 29 Jun 93 8:51 PDT To: "Erik Huizer (SURFnet BV)" , support@ics.uci.edu Cc: ietf-osi-x400ops@cs.wisc.edu, jstewart@CNRI.Reston.VA.US, Steve Coya , John C Klensin Subject: Re: Action list from Columbus. In-Reply-To: Your message of "Tue, 29 Jun 1993 11:11:19 +0200." <9306290911.AA02795@survival.surfnet.nl> Reply-To: Stef@nma.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Einar Stefferud Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Jun 1993 08:51:33 -0700 Message-Id: <7014.741369093@odin.nma.com> X-Orig-Sender: stef@nma.com Hi Erik -- Which topic(s) do you want me to participate in? My only access would be at ICS.UCI.EDU, so I have included the ICS Support Group on this reply. I am sure they can make a SUN workstation available with the appropriate AVT software installed for me. They will no doubt want to see what it is all about in any case. But, I don't think they have ever "tuned in" to an IETF Multicast AV connection, so this may be new to them. But, it is about time;-)... From your message Tue, 29 Jun 93 11:11:19 +0200: } }Stef, } }Is there any chance that you can be at an AVT terminal during the x400ops }sessions, if so, Alf could ask Megan for the X.400ops sessions to be }scheduled for multicast AVT. } }Erik The schedule may be a problem. I assume that we are 8 hours apart, which would generally make the sessions fall into the wee hours of the morning, my time in California. The schedule, on your times is: WEDNESDAY, 14 July 1993 0900-1200 Morning Sessions APP X.400 Operations WG (x400ops) (Alf Hansen/Sintef and Tony Genovese/LLNL) 1330-1530 Afternoon Sessions I APP X.400 Operations WG (x400ops) (Alf Hansen/Sintef and Tony Genovese/LLNL) THURSDAY, 15 July 1993 0930-1200 Morning Sessions APP X.400 Operations WG (x400ops) (Alf Hansen/Sintef and Tony Genovese/LLNL) In my time zone, these are WEDNESDAY, 14 July 1993, 0100-0400, 0530-0730. THURSDAY, 15 July 1993. 0130-0400. That really is a pessimal time to be holed up at UCI. We should plan things so I will not have to be there all that time;-)? I prefer joining you at the 0530-0730 session on Wednesday. It is a worthy experiment, so lets try it, if ICS can provide the needed AVT support. They are well connected to the NSFnet with what I think is a T3 to SDSC in San Diego. Do I need to be able to send Video and Audio, or just audio? I expect just audio is OK at a minimum. Sending video is another can of worms. Cheers...\Stef   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07744; 29 Jun 93 13:09 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07740; 29 Jun 93 13:09 EDT Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa16177; 29 Jun 93 13:09 EDT Received: from cs.wisc.edu by mhs-relay.cs.wisc.edu with SMTP (PP) id <24959-0@mhs-relay.cs.wisc.edu>; Tue, 29 Jun 1993 11:09:45 +0000 Received: from survis.surfnet.nl by cs.wisc.edu; Tue, 29 Jun 93 11:09:38 -0500 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <01906-0@survis.surfnet.nl>; Tue, 29 Jun 1993 18:08:46 +0200 Received: from localhost.surfnet.nl by survival.surfnet.nl (4.1/SMI-4.1(TV920629)) id AA03621; Tue, 29 Jun 93 18:08:27 +0200 Message-Id: <9306291608.AA03621@survival.surfnet.nl> To: Stef@nma.com Cc: support@ics.uci.edu, ietf-osi-x400ops@cs.wisc.edu, jstewart@CNRI.Reston.VA.US, Steve Coya , John C Klensin Subject: Re: Action list from Columbus. In-Reply-To: Your message of Tue, 29 Jun 93 08:51:33 -0700. <7014.741369093@odin.nma.com> Organisation: SURFnet bv Address: Cluetinckborch, P.O. Box 19035, 3501 DA Utrecht, NL Phone: +31 30 310290 Telefax: +31 30 340903 Date: Tue, 29 Jun 93 18:08:17 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Erik Huizer (SURFnet BV)" Ok, we can sort the agenda of x400ops in such a way that the wednesday aft session will be multicast and has subjects on it that interest you. Just indicate which items you are interested in. E.g. you just send a long mail on the subject suggested by Urs. Does that mean you would be interested in particpating in that part? The software for doing AVT is freely available, I don't know where, ask somebody who knows like Stephen Casner . You need a sun, and only audio on return would be sufficient. There is 9 hours time diff :-) Erik   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08460; 29 Jun 93 13:36 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08456; 29 Jun 93 13:36 EDT Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa17206; 29 Jun 93 13:36 EDT X400-Received: by mta mhs-relay.cs.wisc.edu in /PRMD=XNREN/ADMD= /C=US/; Relayed; Tue, 29 Jun 1993 12:22:21 +0000 Date: Tue, 29 Jun 1993 12:22:21 +0000 X400-Originator: ietf-osi-x400ops-req@cs.wisc.edu X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=XNREN/ADMD= /C=US/;mhs-relay..365:29.05.93.17.22.21] Priority: Non-Urgent DL-Expansion-History: ietf-osi-x400ops@cs.wisc.edu ; Tue, 29 Jun 1993 12:22:21 +0000; Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: ALLOCCHIO@elettra-ts.infn.it Message-ID: <"80419192603991/32067 INFN*"@MHS> To: ietf-osi-x400ops@cs.wisc.edu Subject: Action s from Columbus meeting.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14374; 29 Jun 93 18:17 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14370; 29 Jun 93 18:17 EDT Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa29141; 29 Jun 93 18:17 EDT Received: from cs.wisc.edu by mhs-relay.cs.wisc.edu with SMTP (PP) id <26069-0@mhs-relay.cs.wisc.edu>; Tue, 29 Jun 1993 17:15:14 +0000 Received: from ics.uci.edu by cs.wisc.edu; Tue, 29 Jun 93 17:15:00 -0500 Received: from nma.com by q2.ics.uci.edu id aa25630; 29 Jun 93 14:55 PDT Received: from localhost by odin.nma.com id aa07496; 29 Jun 93 11:33 PDT To: "Erik Huizer (SURFnet BV)" Cc: support@ics.uci.edu, ietf-osi-x400ops@cs.wisc.edu, jstewart@CNRI.Reston.VA.US, Steve Coya , John C Klensin Subject: Re: Action list from Columbus. In-Reply-To: Your message of "Tue, 29 Jun 1993 18:08:17 +0200." <9306291608.AA03621@survival.surfnet.nl> Reply-To: Stef@nma.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Einar Stefferud Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 29 Jun 1993 11:33:38 -0700 Message-Id: <7494.741378818@odin.nma.com> X-Orig-Sender: stef@nma.com Thanks Erik -- With a 9 hour difference, I would prefer meshing with the "late night" alternative. In my time zone, these are WEDNESDAY, 14 July 1993, 0000-0300, 0430-0630. THURSDAY, 15 July 1993. 0030-0300. Staying up till 0300 beats getting up at 0300;-). I will select topics from the agenda, and work with ICS Support to see if we can do this. Yes, I am interested in the ADMD/Internet interconnection topic of my long message, but I am also certain that a good and proper discussion would be held with or without my paticipation. Cheers...\Stef From your message Tue, 29 Jun 93 18:08:17 +0200: } }Ok, we can sort the agenda of x400ops in such a way that the wednesday aft }session will be multicast and has subjects on it that interest you. Just }indicate which items you are interested in. E.g. you just send a long mail }on the subject suggested by Urs. Does that mean you would be interested in }particpating in that part? } }The software for doing AVT is freely available, I don't know where, ask }somebody who knows like Stephen Casner . } }You need a sun, and only audio on return would be sufficient. } }There is 9 hours time diff :-) } }Erik   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00758; 30 Jun 93 3:55 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00754; 30 Jun 93 3:55 EDT Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa02171; 30 Jun 93 3:55 EDT Received: from cs.wisc.edu by mhs-relay.cs.wisc.edu with SMTP (PP) id <26973-0@mhs-relay.cs.wisc.edu>; Wed, 30 Jun 1993 02:36:22 +0000 Received: from SYNW03.elettra.trieste.it by cs.wisc.edu; Wed, 30 Jun 93 02:36:16 -0500 Date: Wed, 30 Jun 1993 9:35:22 +0200 (WET-DST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Claudio Allocchio - +39 40 3758523 To: ietf-osi-x400ops@cs.wisc.edu, wg-msg@rare.nl Cc: ALLOCCHIO@elettra.trieste.it Message-Id: <930630093522.23600099@elettra.trieste.it> Subject: Re-send: actions from Columbus IETF Well, late but here I'm again on line with my action report. 5 Claudio Allocchio to report to the X400-OPS group on the results of the discussion with IAB/IESG on the usage of DNS for mapping/routing tables. During the (lunchtime) discussion we had with IAB/IESG members in Columbus the general points about the use of DNS iteself for distribuiting X.400 related information were raised. After a short discussion we decided to deal separately the mapping and the routing issues. The first question was: - shall we really distribute X.400 information via DNS? for routing informations the major objections were: - DNS is not for routing informations; we detected that this was a misunderstanding in terminology: routing information for an MTA has nothing to do with routing of IP packet data etc. Routing information for an MTA is like the MX record informations for an SMTP mailer. - not all MTA will be on the Internet, thus the use of DNS will not solve globally the problem. There will be thus coordiation problems, and the benefits will not be for the whole GO-MHS community. More over this kind of service (the MTA routing data) is a service for the GO-MHS community, based on a service established for the Internet community. I objected that the difference is "subtle", but indeed not all MTA will be able to use a similar service. - The routing data for MTA is just coming out now is a table based format. thus experience is needed to check if the provided information can really "do its job" or if something different is needed. The suggestions were thus to let the idea of using DNS for "MTA routing data" stand still until experience is gained both in using static tables and in using X.500 for routing. I personally think that the "for further study" suggestion can be accepted. - for the mapping table issue: Not all the RFC1327 gateways are on the Internet (there can be isolated SMTP service islands), but for sure ANY RFC1327 gateway on the Internet needs coordinated and up to date mapping tables. Thus the use of DNS to distribute mapping tables to the RFC1327 gateways IS a service for the Internet community, as well as providing MX records for non SMTP e-mail services. Usually the DNS provides only the MX pointer, letting the non SMTP communities "do by themselves" all the remaining e-mail processing. In the case of RFC1327 gateways, however, it was recognized that this kind of service is important for the Internet community, and thus DNS could provide an "extra service" (i.e. more informations than a simple MX record). Then the discussion moved to "how the DNS can provide this extra service". The original suggestion to create a totally separate branch into the DNS to store the RFC1327 mapping rule encountered the following objections: - if we create a new top level like X400.ARPA (or whatever) then there could be an authority delegation problem, i.e. the root mantainer should work to identify per each country again the correct authority for the mapping information branch. I objected that this is not the case, as we already have in the GO-MHS community identified the organizations and people in charge to submit mapping rules etc, and these people will receive the DNS delegation for the mapping branch. More over there is a very simple alternate solution wich can bypass totally the problem: the root mantainer simply insert some pointer (NS records) to the DNS servers holding the X400.ARPA top level SOA records, and then the authority delegation problem is moved from the root to ourselves. An alternate suggestion came from Jon Postel, stating that we could move the new tree from the top level to the second level, i.e. X400.it, X400.fr, X400.de, X400.us. This will just remove an heavy task to the root mantainer, and let any country solve internally its authority problem. Conclusion: study both the first idea (just NS record pointing somewhere where the whole new branch is rooted) and the second one (X400.xx under country top level domain). An alternate idea came from Christian Huitema, suggesting possible methods to be studied in order not to create at all a new branch. We agreed to have a look to it in details. After some thinking (see the e-mail below which was sent to the namedroppers chairman) Blasco (one of the co-authors) and myself concluded that it does not work in our real (and messed up) world. Some other suggestions were in favour to intodruce eventaully some new reseource records instead of using PTRs. I.e. define just a new RR, with the same structure than a PTR, and use it in the RFC822 ---> X.400 section. This will remove only half of the separated branch, but will also create a coordination problem in keeping mapping data aligned. More over the separate branch is needed anyhow to store X.400 ---> rfc822 rules. The IAB suggestion was to consider strongly the idea that if DNS is used for distributing mapping data, it will be used by Internet gateways forever, and thus try to construct a consistent and reliable structure being able to be distributed geographically in the future. As a result of this discussion Erik and myself reported to the last WG-MSG meeting in Trondheim. The conclusion there was to continue with the experiment under x400.it branch as it is now to gain more experimental data on the possible impact that the DNS use under a separate tree can have on the DNS service (this was one of the major worries of IAB people). After a more detailed test, using it in real life, (what we are doing now in GARR admd) we will report again and decide what to do. For this reason I sent the below mail to the namedroppers group, asking their comments and feedblack. ... still waiting for a complete answer. The documents were thus not updated, as the experiment is going on as it is. During the next IETF I'll report with more data on the real life experiment we are doing now, and also distribute the s/w and documentation to those willing to join the experiment. What we need now is just to check again in details if the solution really works well, and if so, we will go back with these data to IAB deciding what to do. The s/w has been meanwhile modified in order to be configurable easily to adapt both to X400.it top level domain, or to X400.arpa or to the other possible solutions with no impact on the developed applications. See you in Amsterdam them! Claudio =========================================================================== From: SYNW03::ALLOCCHIO "Claudio Allocchio - +39 40 3758523" Date: 27-MAY-1993 11:57:38.14 To: SMTP%"sra@epilogue.com" CC: ALLOCCHIO Subj: X.400 <=> DNS mapping/routing documents? Hallo Rob, yes, I was just waiting for feedback both from X400ops and WG-MSG RARE groups after reporting them about the discussion we had at lunch. As WG-MSG met only 10 days ago in Trondheim and JENC 93 I'd to wait a littel bit for them. Meanwhile I also tried to examine carefully the idea of hiding into the already existing naming tree also the X400 --> rfc822 branch using some algorithm as proposed by Christian (see below the result of our meditations!). Here is the feedback from the groups. There is a general consensus about keeping the mapping and routing items totally disjointed. While in X400ops there are some members (all implementors) which would like to have the X400 MTA routing data available via DNS as soon as possible, the general opinion of the the other X400ops members is to consider the routing issue not as urgent as the mapping one. Within WG-MSG this consideration is even stronger: let consider the mapping problem, and place routing issue in the future. RFC1465 about a method for static tables routing as just been published (yesterday) and we will at least try to implement this first (we are at the stage of the "host" table and the group is willing to check if the proposed routing algorythms works before trying to use something dynamic like DNS or X.500 to distribute their data). More over a more general proposal, considering the fact that maybe for routing issues in a complex interconnected MHS world needs a really dedicated network service support, was done: Static routing tables, DNS and X.500 could also be inadequate to provide the required routing algorythm functionality. Thus the group will consider the idea of proposing a totally new (and dedicated) service for MHS routing data (BTW: "routing" = routing of e-mail messages, the equivalent of MX records informations), based on IP and OSI services at the same time: probably something which will have a dedicated IP socket number and at the same time a dedicated OSI NSAP and TSAP, able to pass transparently the routing data on both services, with dedicated data structures, etc... This proposal is still very tentative, and thus very future... Our (the authors') conclusion was thus to let the routing proposal via DNS stand still, waiting for further evaulations of the problem. If some more efficient solution comes out (we are also looking at the X.500 routing experiment which MHS-DS group is starting) the proposal will probably be dropped. The mapping issues. Both X400ops and WG-MSG believes that this topic, instead, is urgent, and thus we should try to solve it as soon as possible. The general consensus is that (as any rfc1327 gateway is of course both on the Internet and on X.400 MHS) the DNS looks still a very good method to make the mapping rules availables to all the gateways, including the public X.400 ADMDs which are now starting to provide Internet gateway service to their customers. The AT&T and Sprint representatives in X400ops stated that they'd like to find the mapping rules with a query to DNS as they can find the MX records data to decide where to then the messages from their Internet gateways. More over X400ops and WG-MSG fear that, if some dynamic (and trusted) way of having mapping rules available for all gateways on the Internet is not there, then there is a strong risk to have public service providers (like ADMDs) go with totally non standard solutions for they gateways (i.e. solutions violating RFC1327) which will create a serious mess both on X.400 MHS and expecially on Internet SMTP mail services (unrepliable addresses, mail loops, idle source routings, addresses much longer than 80 characters, rfc822 local parts totally uncomprehensible for the users and often totally umparsable by SMTP mailers...) An example of the problem already exists: the Canadian Government Gateway service (check a mail announcing which came out about 1 month ago). After having examined the idea of having the mapping data totally embedded into the current DNS tree, the groups came to the conclusion that probably the rfc822 --> x.400 data can be stored into the existing DNS tree, but the x.400 --> DNS rules needs anyhow a separated branch. This branch can start both at top level (as in the original proposal) or at level 2, under each national top level domain (as Jon proposed). The differences about the two possible solutions are administrative ones: if the branch starts from top level ( X400.xxx, xxx = ARPA/NET/MHS/... who knows what!) the administrator of the root should identify the local mapping authorities for the X.400 branch. If the branch start at national level (X400.it, X400.us, X400.de,...) the problem is simply shifted one administrative level down. However the groups suggests, in case of solution at top level, a different approach: the root simply puts a pointer (NS record) to another nameserver, which actually becomes the root for the X400 --> rfc822 branch, totally delegating any authority problem: X400.xxx. IN NS artsbl.area.trieste.it. to make an example with the current experimental test. There is a strong opinion, expecially in the WG-MSG group, that this kind of delegation will produce a much secure and controlled environment for mapping authorities both during implementation phase and during the subsequent authotity delegation process. In fact the authority controlling the X400.xxx root will be the already available X.400 MHS coordination service, which currently distributes the static mapping tables. However the mapping authority would like to keep. at least at the beginning, the authority centralised, implementing the following schema: DNS <---------- Static tables <-------- national updates. As a conclusion the groups decided to make some more experiments (currently implemented under X400.it provisional root) to check the effects of this "new branch" solution, and also making some authority distribution tests, before deciding the way to really go. About this point we would like to invite also the namedroppers group to make tests with this provisional experimental cranch (actually totally centralised on one single naeserver) and let us know their feedback. Another point being discussed was: which kind of RR to use for the mapping rules? in the current experiment PTRs are used. The open questions are - PTRs is a pointer to a different branch of the name space. a mapping rule points from rfc822 to x.400 (and viceversa) name spaces. Is thus legal to use PTRs (with syntax conformance to RFC1035, of course)? - If not, which kind of RR do we need? just a copy of PTR structure could be fine, or do we need somthing different? One aim of the experiment is also to check if the use of PTRs creates any trouble (and in such a case the PTR use will automatically be discarded). About the documents: as the decision was to continue with more exepriments any update of the mapping document proposal is related to the result of the experiment itself and to the suggestions and proposals coming from namedroppers group. At next Amsterdam IETF the expected result will be to have a more detailed knowledge about the experimental results, jointed with suggestions from the theoretical DNS gurus. Thus... conlusions: Some kind of a separate tree seems to be needed, both for technical reasons (otherwise there are name clashes) and authority delegation reasons. We currently need to have more data of the possible effects of this separate tree. thus we need namedroppers collaboration to make some further tests. The exact location (in RR terms) of the mapping rules has to be decided: PTRs or what? All the above facts will help deciding how to go on. Some other possible solutions also came out of the groups: - instead of creating a new branch in the current name space, we just create a new dedicated name space (this can also fit with the new routing data tools idea, see above). i.e. a new socket number for the new service, and a new software (very likely to be a modified BIND version) for it. - we just use DNS for accessing informations, and not to distribute the authority for mapping rules. A number of appropriate secondary nameservers located at focal points will keep query traffic under control, giving the needed redundancy. i.e. one central nameserver keeps the whole mapping data and some secondary ones just replicate them. In this case there is simply no new branches in the name tree. just a new file replicated in some places. Ok, that's it Rob, could you also forward this mail to namedroppers and have back their comments? (BTW: I'm not on there, maybe it's better to subscribe me on the list in order to follow easily the discussion). let me know! Claudio ------------------------------------------------------------------------- Use of the existing name space for rfc1327 mapping rules. a) rfc822 --> x.400 mapping rules. This case is trivial: the rfc822 key of the mapping rule is an existing domain; thus the only question is do we put the rule in PTR epilogue.com. IN PTR P-epilogue-d-com.A-IMX.C-us.X400.us. (or something similar) or we use a new RR? X400ops and WG-MSG are in favour of using PTRs, but we need stil to check in real life if this can create problems, and if the PTR definition fits with this scope. b) x.400 --> rfc822 mapping rule. This case is NOT trivial, and the x.400 O/R name space is totally different from the domain name one. Even if often the domain name and the corresponding O/R name looks quite similar (especially in R&D world), there are much more cases, expecially in the commercial X.400 service providers, in which there is a compleletely different naming approach: attributes filled with blanks, non alphanumhyphen characters, different fields. One example from real life: cen.jrc.it <---> o=ispraa; prmd=ccrispra; admd=garr; c=it apart 'it' anything else does not match! Using a generic algorhytm to solve the problem also does not help: 1) drop the labels from an X.400 address O=Olivetti.P=IUnet.A=garr.C=it --> Olivetti.IUnet.garr.it (the real equivalent for the above O/R name is 'olivetti.it') 2) look in the name space for Olivetti.IUnet.garr.it; it does not exists as a domain, thus a CNANE stating something like Olivetti.IUnet.garr.it. IN CNAME Olivetti.it. must exists (this implies thousands of CNAMEs around) 3) then you get the mapping rule which goes from rfc822 --> X.400, reverse it (to obtain the rule X.400 --> rfc822) and apply it. But this does not work: rfc822 --> X.400 rule is not necessarily symmetric with X.400 --> rfc822 one. This is also the reason to have TABLE1 and TABLE2 separated in order to solve asymmetries existing. (check RFC1327). More over the correspondence is not bijective: it can happen that rfc822 X.400 A.B.C ---> XY D.B.C ---> XY B.C ---> XY or viceversa. WHat do we do if I want to go from XY (X.400) to rfc822? having asymmetric mapping rules (table1 and table2) you can solve it, but only in that case. More over there are possible clashes: an example p=nis.a=garr.c=it actually maps to nis.it dropping labels from x.400 to rfc822 we have nis.garr.it but nis.garr.it is another actual rfc822 domain, totally different from nis.it, and the real mapping for the real nis.garr.it is 'o=nis.p=garr.a=garr.c=it'. Conclusion: using CNAMEs will produce thousands on unmanageble entries in the normal name tree, and more over there are many cases in which there is NO solution for storing the correct data. As a consequence, for X.400 --> rfc822 data we really need a separate branch.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01054; 30 Jun 93 5:54 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01050; 30 Jun 93 5:53 EDT Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa03781; 30 Jun 93 5:53 EDT Received: from cs.wisc.edu by mhs-relay.cs.wisc.edu with SMTP (PP) id <27854-0@mhs-relay.cs.wisc.edu>; Wed, 30 Jun 1993 04:30:44 +0000 Received: from mitsou.inria.fr by cs.wisc.edu; Wed, 30 Jun 93 04:30:26 -0500 Received: by mitsou.inria.fr (5.65c/IDA-1.2.8) id AA12213; Wed, 30 Jun 1993 11:30:56 +0200 Message-Id: <199306300930.AA12213@mitsou.inria.fr> To: Claudio Allocchio - +39 40 3758523 Cc: ietf-osi-x400ops@cs.wisc.edu, wg-msg@rare.nl Subject: Re: mapping and DNS In-Reply-To: Your message of "30 Jun 93 09:35:22 +0200." <930630093522.23600099(a)elettra.trieste.it> Date: Wed, 30 Jun 93 11:30:56 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Christian Huitema Claudio, The suggestion that I made at the IETF were the following: 1) For the RFC to X.400 table: The situation is straightforward. The "prefered mapping", or mappings, can be inserted as an attribute of the domain name. Details can be worked out separately, but from the discussions I had with Rob Hagens a long time ago, I believe that we can devise a simple structure of: Record Type: XA - X400-Address Record Syntax: preference level -- one binary octet number of parts matched -- one binary octet X.400 adress -- BER encoded octet string, only containing the elements which are useful. We need the preference level because we must be able to choose between multiple mappings (multiple X.400 subscriptions). We need the "number of parts matched" so we can use "catch all" records, e.g. <*.inria.fr> matches for , but the count is 2 which means that one has to insert the unmatched parts as OUs. I dont like the idea of using PTRs -- in fact, I think it is the wrong thing to do. It does not let you register preferences, nor catch all pointers. Also, it obliges you to create te reverse domain, which I believe is the wrong thing to do. And there is a risk to collide with bona-fide PTRs. 2) For the X.400 to RFC table: This is a mess. There is a strong desire not to create a second tree, and specially not to create one that includes a branch in it. I think that in a number of case there is a strong correlation between the DNS tokens and the X.400 name parts, and that we should use this correlation in order to minimize the amount of information that has to be entered in the DNS. I was thinking of using the following algorithm: a) Extract 1, 2 or 3 possible candidate domain names from the ORName. Given Claudio's example of: O=Olivetti.P=IUnet.A=garr.C=it The candidates would be Olivetti.IUnet.garr.it, Olivetti.IUnet.it, Olivetti.it b) Look for the candidate domain in the DNS. If the doamin exist, the candidate is selected. This is not sufficient however to resolve the "clashes", e.g. when several of the candidate domain names are selected. In that case, execute step (c). c) In order to resolve the clashes, look at the X.400 mapping records for the selected domain names. If the resulting mapping matches the ORName (or one of the possible mappings if several are present), then the domain name is considered correct. d) cache the result. Statistics show that a cache of about 200 entries garanties a very high hit rate. Indeed, this solution assumes that there is some degree of correlation between X.400 and Internet names. When there is no correlation, e.g. for Claudio's examples of: cen.jrc.it <---> o=ispraa; prmd=ccrispra; admd=garr; c=it epilogue.com <---> prmd=epilogue.com; admd=IMX; c=us we have do use other techniques, like: a) inserting an "alias" in the DNS for one of , or . This will work also for all the non alphanumeric names -- there is no restriction to the syntax of DNS tokens. b) recognizing the "ADMD=IMX, C=US" convention. c) just not mapping the ORName, and use the long form. Indeed, the owners of the non matchable addresses will not like it. But, after all, they were the ones which chosed to use ridiculous ORNames and not insert the proper back pointers in the DNS. They deserve what they get. In fact, some research is needed here. A first try could be to just pass the proposed algorithm over the existing collection of names present in the mapping tables, and to look at the number of matches, collisions, etc. Inserting some statistics in the debate could be helpful. Christian Huitema   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04381; 30 Jun 93 8:38 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04377; 30 Jun 93 8:38 EDT Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa07386; 30 Jun 93 8:38 EDT Received: from cs.wisc.edu by mhs-relay.cs.wisc.edu with SMTP (PP) id <28396-0@mhs-relay.cs.wisc.edu>; Wed, 30 Jun 1993 07:18:59 +0000 Received: from SYNW03.elettra.trieste.it by cs.wisc.edu; Wed, 30 Jun 93 07:18:55 -0500 Date: Wed, 30 Jun 1993 14:18:05 +0200 (WET-DST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Claudio Allocchio - +39 40 3758523 To: ietf-osi-x400ops@cs.wisc.edu, wg-msg@rare.nl Cc: ALLOCCHIO@elettra.trieste.it Message-Id: <930630141805.23600099@elettra.trieste.it> Subject: Match statistics... Hallo Christian, yes, I agree that an attempt to similate the number of matches, clashes and the overall load of queries needed for the X.400 ---> rfc822 part is needed. What worries me is the "native X.400 O/R addresses" of the public service providers (the ADMDs) which have just discovered now the Internet (or better: they just discovered that selling their customers also the Internet con- nectivity will make them get more money!). In fact the R&D X.400 O/R addresses are usually plain and close to the equivalent rfc822 ones. We will try to sort out some statistics and check the results. Comments, ideas, etc about Christian's proposed algorhytms? (did I spell it ok?) regards Claudio   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06305; 30 Jun 93 10:24 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06301; 30 Jun 93 10:24 EDT Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa11551; 30 Jun 93 10:24 EDT Received: from cs.wisc.edu by mhs-relay.cs.wisc.edu with SMTP (PP) id <28828-0@mhs-relay.cs.wisc.edu>; Wed, 30 Jun 1993 09:01:02 +0000 Received: from mitsou.inria.fr by cs.wisc.edu; Wed, 30 Jun 93 09:00:52 -0500 Received: by mitsou.inria.fr (5.65c/IDA-1.2.8) id AA12589; Wed, 30 Jun 1993 15:33:40 +0200 Message-Id: <199306301333.AA12589@mitsou.inria.fr> To: Claudio Allocchio - +39 40 3758523 Cc: ietf-osi-x400ops@cs.wisc.edu, wg-msg@rare.nl Subject: Re: Match statistics... In-Reply-To: Your message of "30 Jun 93 14:18:05 +0200." <930630141805.23600099(a)elettra.trieste.it> Date: Wed, 30 Jun 93 15:33:40 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Christian Huitema >What worries me is the "native X.400 O/R addresses" of the public service >providers (the ADMDs) which have just discovered now the Internet (or better: >they just discovered that selling their customers also the Internet con- >nectivity will make them get more money!). That is not a big problem -- in theory. You can very well suppose that these clients do not have yet an Internet address (if they are regular internet user, we can recommend them to chose matching names in both worlds). In that case, having one DNS entry for the ADMD would be enough. The entry would probably also hold the ADMD MX record for gatewaying... Christian Huitema   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07477; 30 Jun 93 11:02 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07473; 30 Jun 93 11:02 EDT Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa13160; 30 Jun 93 11:02 EDT Received: from cs.wisc.edu by mhs-relay.cs.wisc.edu with SMTP (PP) id <28908-0@mhs-relay.cs.wisc.edu>; Wed, 30 Jun 1993 09:08:58 +0000 Received: from mailgate.ericsson.se by cs.wisc.edu; Wed, 30 Jun 93 09:08:49 -0500 Received: from eua.ericsson.se by mailgate.ericsson.se (4.1/SMI-4.1-MAILGATE1.14) id AA08907; Wed, 30 Jun 93 16:07:42 +0200 Received: from ms.eua.ericsson.se by eua.ericsson.se (4.1/EUA-2.1) id AA18606; Wed, 30 Jun 93 16:07:40 +0200 Received: from euas58c30.eua.ericsson.se by ms.eua.ericsson.se (4.1/MS-2.1) id AA08062; Wed, 30 Jun 93 16:07:37 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Osten Franberg Received: by euas58c30.eua.ericsson.se (4.1/client-1.3) id AA18375; Wed, 30 Jun 93 16:07:37 +0200 Date: Wed, 30 Jun 93 16:07:37 +0200 Message-Id: <9306301407.AA18375@euas58c30.eua.ericsson.se> To: Erik.Huizer@surfnet.nl, Alf.Hansen@delab.sintef.no Subject: OSI-adr. in Sweden Cc: ietf-osi-x400ops@cs.wisc.edu, KLENSIN@infoods.mit.edu, Osten.Franberg@eua.ericsson.se Hallo This is my first entry into your group. I have followed your conversation over e.mail since last ITEF-meeting in Boston. During 1992 SIS (Swedish standards org.) SNUS (Swedish Network Users Society) KTH (Royal Technical Institute) has formed a NATIONAL REGISTER. This register has the national responsebility to allocate, internet B, C- addresses, OSI-adr, internet domain namne, PRMD and ADMDs. We have find it useful to have common registration athority for internet and OSI mail identities, speciality for mail adr. translations. We look carefully to the ADMD, PRMD-names people ask for, so it corspond to the common use of the company name (ie that VOLVO get's the PRMD-name VOLVO) I will attend the ITEF-conference 12-16 July, and we could meet then and exchange ides. Regards Osten Franberg Chairman SNUS   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07487; 30 Jun 93 11:03 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07483; 30 Jun 93 11:03 EDT Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa13170; 30 Jun 93 11:03 EDT Received: from cs.wisc.edu by mhs-relay.cs.wisc.edu with SMTP (PP) id <29067-0@mhs-relay.cs.wisc.edu>; Wed, 30 Jun 1993 09:29:01 +0000 Received: from SYNW03.elettra.trieste.it by cs.wisc.edu; Wed, 30 Jun 93 09:28:50 -0500 Date: Wed, 30 Jun 1993 16:27:59 +0200 (WET-DST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Claudio Allocchio - +39 40 3758523 To: ietf-osi-x400ops@cs.wisc.edu, wg-msg@rare.nl Cc: ALLOCCHIO@elettra.trieste.it Message-Id: <930630162800.23600088@elettra.trieste.it> Subject: ADMD customers O/R addresses... ... I was thinking of all those O/R addresses filled up with "blanks", dots, "+" signes, etc. wich could make the creation of a "plain" rfc822 address impossible with just one mapping rule for the ADMD. Let me explain it better: O/R address: c=gb; admd=Gold 400; prmd=ACME Inc.+Co.; O=Sales dept.; ... if we have a mapping rule for c=gb; admd=Gold 400; only, the above address will end up in LHS encoding according to RFC1327. I suppose that the ACME Inc. & Co. guys would prefer of course to present a nice plain rfc822 address on their salesmen business cards, like: xxxx@sales-dept.ACME-Inc.gb (mmmh... ".co.uk" ??? ok forget this problem). but this requires a mapping rule entry specific. OK, "its their fault" but can we convince them that it is a fault having used the allowed features in an O/R address? I'm in favour of avoiding such O/R addresses, too (O/R addresses are too complex already, we do not need to make life worst!) but I'm worried about the possible implications. ... I'm just trying to collect all possible sources of problems and then to analyze them. Claudio   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15765; 30 Jun 93 18:21 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15761; 30 Jun 93 18:21 EDT Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa28894; 30 Jun 93 18:21 EDT Received: from cs.wisc.edu by mhs-relay.cs.wisc.edu with SMTP (PP) id <00416-0@mhs-relay.cs.wisc.edu>; Wed, 30 Jun 1993 17:18:18 +0000 Received: from SYNW03.elettra.trieste.it by cs.wisc.edu; Wed, 30 Jun 93 17:18:14 -0500 Date: Thu, 1 Jul 1993 0:17:21 +0200 (WET-DST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Claudio Allocchio - +39 40 3758523 To: ietf-osi-x400ops@cs.wisc.edu, wg-msg@rare.nl Cc: ALLOCCHIO@elettra.trieste.it Message-Id: <930701001721.236000e3@elettra.trieste.it> Subject: a complex mapping case... I started examining the real cases using the algorhytm proposed by Christian; in most of the obvious cases it works, dropping the admd and/or the prmd. Let's examine some more complex ones: the real rfc1327 rules are: OU$A.O$@.PRMD$B.ADMD$c.C$xx#a.b.c.xx" a.b.c.xx#OU$A.O$@.PRMD$B.ADMD$c.C$xx# a.xx#PRMD$A.ADMD$A.C$xx" and I get an address like: OU=d; OU=A; PRMD=B; ADMD=c; C=xx; using the proposed rules I can try to match: d.A.B.c.xx this matches a.b.c.xx . IN XA n OU$a.O$@.PRMD$B.ADMD$c.C$xx d.A.B.xx this does not match anything d.A.xx this matches a.xx. IN XA n PRMD$A.ADMD$A.C$xx I select the 1st and the 3rd, then looking at the O/R address I decide for the 3rd one, and I get the X.400 ---> rfc822 rule. What about this one: OU$A.O$@.PRMD$B.ADMD$c.C$xx#a.b.c.xx" a.b.c.xx#OU$A.O$@.PRMD$B.ADMD$c.C$xx# (symmetric mapping) and O$A.PRMD$B.ADMD$c.C$xx#abc.xx" abc.xx#O$A.PRMD$B.ADMD$c.C$xx# (symmetric mapping) They're both legal mapping rules and addresses. Now I get the following addresses: 1) OU=a; PRMD=b; ADMD=c; C=xx; 2) O=a; PRMD=b; ADMD=c; C=xx; The both produce: a.b.c.xx this matches a.b.c.xx. IN XA n OU$a.O$@.PRMD$B.ADMD$c.C$xx a.b.xx this does not match anything a.xx this does not match anything but... there is also abc.xx. IN XA n O$a.PRMD$B.ADMD$c.C$xx, which is the correct mapping for O/R address 2). How do I get the correct mapping X.400 ---> rfc822 for case 2) ? 2) produces a.b.c.xx, but the O/R address does not match the mapping proposed, i.e. OU$a.O$@.PRMD$B.ADMD$c.C$xx; How do I ever get to the correct one, which is abc.xx. IN XA n O$a.PRMD$B.ADMD$c.C$xx ? I should have some kind of alias which states a.b.c.xx is an alias of abc.xx. But how to store this alias? a CNAME? it does not work: a.b.c.xx is already an entry, it cannot be a CNAME too. And we are not considering the organizational problems caused by authority delegation. The kind of coordination required to establish this kind of info into the normal branch of DNS I suspect is really enormous. We need a mechanism which can cover all the possible RFC1327 cases, otherwise we will have different behaviour between a gateway using tables, and another one using DNS (a eventually another different behaviour ix we use X.500): this must not happen. Anyhow I'll continue investigating Christian's proposal. "see" you tomorrow! Claudio   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16755; 30 Jun 93 19:43 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16751; 30 Jun 93 19:43 EDT Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa00839; 30 Jun 93 19:43 EDT X400-Received: by mta mhs-relay.cs.wisc.edu in /PRMD=XNREN/ADMD= /C=US/; Relayed; Wed, 30 Jun 1993 18:13:52 +0000 Date: Wed, 30 Jun 1993 18:13:52 +0000 X400-Originator: ietf-osi-x400ops-req@cs.wisc.edu X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=XNREN/ADMD= /C=US/;mhs-relay..592:30.05.93.23.13.52] Priority: Non-Urgent DL-Expansion-History: ietf-osi-x400ops@cs.wisc.edu ; Wed, 30 Jun 1993 18:13:50 +0000; Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: " (Tony Genovese)" Message-ID: <9306302313.AA28870@ophelia.nersc.gov> To: ietf-osi-x400ops@cs.wisc.edu Subject: Amsterdam meeting Organization: ESnet, Energy Sciences Network Hi, Alf and I are puting together the agenda, Alf volunteered ;-) to draft it. From your input and my desires here is a tentative outline of the agenda. NB: the secratary for our next meeting has already graciously volunteered - Jim. We are also reworking the charter and hope to get it out to you this week. I am leaving for Amsterdam on friday morning the 9th. And considering the 4th of July is a big day around here I will also be off on monday the 5th. What all this boils done to is I DO NOT HAVE MUCH TIME LEFT to get this done. So if you have any input or changes do it NOW. --------------------- Agenda outline --------------------- o Introduction o Action list review o Liaison Reports o Review New Charter o Report on DNS pilot o Urs write up on the transition to the GO-MHS community o Internet support for GO-MHS o Document review o A=IMX report o Table distribution paper o Tool survey for mail management o Do we need to develop gateway specifications for other mail systems? We have smtp/mime <-> X.400. Do we need to deal with other LAN mail systems. Or is this being handled by other groups? o ADMD/Internet interconnection - with Multicasting possibly o AOB and Plan for next meeting in Houston, TX ----------------------- File server access --------------- I have set up a file store for our WG. I have also created a subdirectory for the Amsterdam meeting. I have put the latest drafts of your papers in this directory. I need to have your latest versions for the meeting. Please send me a copy if, I have missed your paper or have an out of date version. To access File server: Via Anonymous FTP to ftp.es.net: ftp> cd pub/mhs/x400ops/amsterdam Via Read-Only NFS from nfs.es.net: path = /esnet-nic/pub/mhs/x400ops/amsterdam Via DECnet COPY from ESNIC: ESNIC::"/esnet-nic/pub/mhs/x400ops/amsterdam" Via Gopher: host: gopher.es.net path: 1/pub/mhs/x400ops/amsterdam Current files in pub/mhs/x400ops/amsterdam: minutes draft-ietf-x400ops-admd-02.txt draft-ietf-x400ops-charactersets-03.txt draft-ietf-x400ops-dnsx400maps-02.txt draft-ietf-x400ops-dnsx400rout-02.txt draft-ietf-x400ops-evaluation-admd-00.txt draft-ietf-x400ops-mapsmail-02.txt draft-ietf-x400ops-mgtdomains-ops-05.txt draft-ietf-x400ops-mhs-service-06.txt draft-ietf-x400ops-postmaster-01.txt draft-ietf-x400ops-tbl-dist-00.txt   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17084; 30 Jun 93 20:51 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17080; 30 Jun 93 20:51 EDT Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa02153; 30 Jun 93 20:51 EDT Received: from cs.wisc.edu by mhs-relay.cs.wisc.edu with SMTP (PP) id <00852-0@mhs-relay.cs.wisc.edu>; Wed, 30 Jun 1993 19:34:40 +0000 Received: from THOR.INNOSOFT.COM by cs.wisc.edu; Wed, 30 Jun 93 19:34:36 -0500 Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-13 #1336) id <01GZZXAQ3DZW8WW6RS@INNOSOFT.COM>; Wed, 30 Jun 1993 17:34:24 PDT Date: Wed, 30 Jun 1993 17:34:24 -0700 (PDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Kevin V. Carosso" Subject: Using DNS for TABLE1 and TABLE2 To: ietf-osi-x400ops@cs.wisc.edu, wg-msg@rare.nl Message-Id: <01GZZXAQ3DZY8WW6RS@INNOSOFT.COM> X-Vms-To: IN%"ietf-osi-x400ops@cs.wisc.edu",IN%"wg-msg@rare.nl" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Maybe this has been hashed out already, but not in anything I've seen since I joined the group at the Columbus IETF. We've been talking about using PTR RRs or inventing a new flavor, XA. Has this been taken up with the DNS experts? I know that when the Kerberos people went off to use the DNS for additional purposes over and above common usage, they ended up having to modify the source to bind. I think they called the result HESIOD, but I could be wrong about that. For good or for bad, almost every single DNS server deployed at present is based on some version of bind. Do we know what something like XA can be supported by the currently deployed DNS infrastructure (as opposed to what the DNS RFC's say is possible)? Even if XA isn't a problem, how about limits on lengths and permissible characters? /Kevin Carosso Innosoft   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24078; 30 Jun 93 23:58 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24074; 30 Jun 93 23:58 EDT Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa05270; 30 Jun 93 23:58 EDT Received: from cs.wisc.edu by mhs-relay.cs.wisc.edu with SMTP (PP) id <01123-0@mhs-relay.cs.wisc.edu>; Wed, 30 Jun 1993 22:42:37 +0000 Received: from ics.uci.edu by cs.wisc.edu; Wed, 30 Jun 93 22:42:33 -0500 Received: from nma.com by q2.ics.uci.edu id aa15247; 30 Jun 93 19:46 PDT Received: from localhost by odin.nma.com id aa11209; 30 Jun 93 19:02 PDT To: " (Tony Genovese)" Cc: ietf-osi-x400ops@cs.wisc.edu Subject: Re: Amsterdam meeting In-Reply-To: Your message of "Wed, 30 Jun 1993 18:13:52 -0000." <9306302313.AA28870@ophelia.nersc.gov> Reply-To: Stef@nma.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Einar Stefferud Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Jun 1993 19:02:53 -0700 Message-Id: <11207.741492173@odin.nma.com> X-Orig-Sender: stef@nma.com I do not yet have any confrimaton of being able to participate from UCI via multicast, but just in case, here are the items I am interested in, so you can maneuver them into the Thursday morning session, if possible. o A=IMX report o Do we need to develop gateway specifications for other mail systems? We have smtp/mime <-> X.400. Do we need to deal with other LAN mail systems. Or is this being handled by other groups? o ADMD/Internet interconnection - with Multicasting possibly Thanks...\Stef