From mailman-owner@lists.bell-labs.com Sat Jul 1 05:20:20 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18048 for ; Sat, 1 Jul 2000 05:20:19 -0400 (EDT) From: mailman-owner@lists.bell-labs.com Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4A1F544618 for ; Sat, 1 Jul 2000 05:09:38 -0400 (EDT) Subject: lists.bell-labs.com mailing list memberships reminder To: iptel-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.1 Precedence: bulk List-Id: Message-Id: <20000701090938.4A1F544618@lists.bell-labs.com> Date: Sat, 1 Jul 2000 05:09:38 -0400 (EDT) This is a reminder, sent out once a month, about your lists.bell-labs.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, iptel-request@lists.bell-labs.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@lists.bell-labs.com. Thanks! Passwords for iptel-archive@lists.ietf.org: List Password // URL ---- -------- iptel@lists.bell-labs.com Gfcn http://lists.bell-labs.com/mailman/options/iptel/iptel-archive@lists.ietf.org From iptel-admin@lists.bell-labs.com Mon Jul 3 11:40:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03522 for ; Mon, 3 Jul 2000 11:40:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4EACA44350; Mon, 3 Jul 2000 11:39:48 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from paris.packetizer.local (rdu162-228-022.nc.rr.com [24.162.228.22]) by lists.bell-labs.com (Postfix) with ESMTP id 69B8F44336 for ; Mon, 3 Jul 2000 02:53:55 -0400 (EDT) Received: from berlin (berlin.packetizer.local [192.168.1.4]) by paris.packetizer.local (8.9.3/8.9.3) with SMTP id CAA15953; Mon, 3 Jul 2000 02:53:11 -0400 Message-ID: <072301bfe4bb$5c45d180$0401a8c0@berlin> From: "Paul E. Jones" To: "Suntichai Chusywong" , References: <004801bfd5c1$f073f980$8300a8c0@coe.psu.ac.th> Date: Mon, 3 Jul 2000 01:42:11 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_061E_01BFE48F.E7F591B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: [IPTEL] =?windows-874?B?UmU6IFtJUFRFTF0g51doZXJlIGNhbiBJIGdldCBmcmVlIEFTTi4xIENv?= =?windows-874?B?bXBpbGVy?= Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_061E_01BFE48F.E7F591B0 Content-Type: text/plain; charset="windows-874" Content-Transfer-Encoding: quoted-printable Suntichai, You can get a free ASN.1 compiler as part of the OpenH323 effort here: http://www.openh323.org Best Regards, Paul ----- Original Message -----=20 From: Suntichai Chusywong=20 To: IPTEL@lists.bell-labs.com=20 Sent: Wednesday, June 14, 2000 1:29 AM Subject: [IPTEL] =E7Where can I get free ASN.1 Compiler Where can I get free ASN.1 Compiler? ------=_NextPart_000_061E_01BFE48F.E7F591B0 Content-Type: text/html; charset="windows-874" Content-Transfer-Encoding: quoted-printable
Suntichai,
 
You can get a free ASN.1 compiler as = part of the=20 OpenH323 effort here:
http://www.openh323.org
=
 
Best Regards,
Paul
 
----- Original Message -----
From:=20 Suntichai Chusywong
To: IPTEL@lists.bell-labs.com
Sent: Wednesday, June 14, 2000 = 1:29=20 AM
Subject: [IPTEL] =E7Where can I = get free=20 ASN.1 Compiler

Where can I get free ASN.1 = Compiler?
 
------=_NextPart_000_061E_01BFE48F.E7F591B0-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Jul 5 10:17:11 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04709 for ; Wed, 5 Jul 2000 10:17:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D23C744336; Wed, 5 Jul 2000 10:16:41 -0400 (EDT) Delivered-To: iptel@share.research.bell-labs.com Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by lists.bell-labs.com (Postfix) with SMTP id EAF4944336 for ; Wed, 5 Jul 2000 08:42:01 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Wed Jul 5 08:40:19 EDT 2000 Received: by lists.bell-labs.com (Postfix) id DE13344351; Wed, 5 Jul 2000 08:27:09 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by lists.bell-labs.com (Postfix) with ESMTP id B0AD744347 for ; Wed, 5 Jul 2000 08:27:09 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id AC10D52C4; Wed, 5 Jul 2000 08:27:08 -0400 (EDT) Delivered-To: iptel@lists.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id D01E252AB for ; Wed, 5 Jul 2000 08:27:05 -0400 (EDT) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Jul 5 08:25:38 EDT 2000 Received: from nscolmar.colmar.uha.fr ([194.167.108.34]) by dusty; Wed Jul 5 08:25:37 EDT 2000 Received: from colmar.colmar.uha.fr (colmar.colmar.uha.fr [194.167.107.31]) by nscolmar.colmar.uha.fr (8.9.3/8.9.3) with ESMTP id NAA31839; Wed, 5 Jul 2000 13:46:35 +0200 From: conf@colmar.uha.fr Received: from gtrpc13 (gtrpc13.colmar.uha.fr [192.168.12.51]) by colmar.colmar.uha.fr (8.8.8/8.8.8) with SMTP id OAA25648; Wed, 5 Jul 2000 14:03:43 +0100 (WET DST) Message-Id: <3.0.1.32.20000705150859.009216a0@colmar.colmar.uha.fr> X-Sender: conf@colmar.colmar.uha.fr X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F] Date: Wed, 05 Jul 2000 15:08:59 +0200 To: conf@colmar.colmar.uha.fr Mime-Version: 1.0 Content-Type: text/enriched; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [IPTEL] Call for Papers of ICATM01 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: quoted-printable Please feel free to circulate this following preliminary program of ICATM01 to interested colleagues (see http://iutsun1.colmar.uha.fr/ICATM01.html for more information).=20 Accept our sincere apologies if you receive multiple copies. ----------------------------------------------------------------------------= ----------- =20
Preliminary Call For Papers =20 Conference on Intelligent Networks, IP over ATM and Quality of Services=20 Joint 4th International Conference on ATM and High Speed Internet (ICATM'01)=20 April 23-25, 2001=20 Olympic Parktel, Seoul, Korea
=20 GENERAL INFORMATION=20 The 2001 IEEE International Conference on ATM (ICATM'01) is sponsored by the IEEE, IEE and WSES. ICATM'01 is organized by academic, research and industrial societies will be held at Olympic Parktel, Seoul, http://metro.seoul.kr , Korea, from Monday April 23, 2001 to Wednesday April 25, 2001 plus Tutorials on Sunday April 22, 2001. The Olympic Park is situated at the city of Seoul where the Olympic game was helid in 1988, about 20 km(14 miles) north-east of KIMPO International Airport. Seoul, the metropolitan captical of Korea located almost in the center of the Korean peninsula, has been the hub of the nation's politics, economy, culture and transportation. Seoul covers a total of about 600km2, with a population of more than 10 million. Just a few steps from many hotels in the downtown is Toksugung Palace, Ch'angdokkung Palace, Piwon, the Secret Garden, and much more historical/cultural sites to visit. Seoul hosts a variety of symphony concerts, operas, and recitals by local and visiting musicians. The Seoul Arts Center in the southern part of Seoul, the Sejong Cultural Center, located on the main thoroughfare in downtown Seoul, the National Theatre in Namsan Park, and the Hoam Art Hall near the City Hall offer a wide range of cultural programs and performances. There are few cities in the world where the ultra-modern and the ancient exist side by side in such perfect harmony. Today, Seoul is a teeming metropolis with many first-class Western-style hotels. English is spoken at many shops, bars, and restaurants. For traveling major cities of Korea; by Air, there are two domestic Airlines: KAL(=3DKorean Air), http://www.koreanair.com and Asiana Airline, http://www.asiana.co.kr . Most of major cities can be reached within an hour by Air.=20 By Rail, there are three type trains: Tong-il (twice per day), Mugunghwa (four times per day) and Saemaul (twice per day). The Saemaul train is the fastest one and takes you major cities within 5 hour 30 minutes time from SEOUL and the Mugunghwa would take about 6-hour time frame to reach at any cities. We do not recommend Tong-il train since it is a slow train which stops at each local areas. Many major cities are all within a day's reach. One can learn more about Seoul in the Website, http://metro.seoul.kr and apersonal prestige, but innate place, That is Seoul, the center of the Korean peninsula. We salute you all.=20 In order to encourage closer interaction between academic and industrial ATM research communities, we solicit both academic research papers and industrial contributions.=20 TOPICS OF SPECIAL INTEREST=20 Topics of interest include, but are not limited to the following:=20 Traffic models=20 LAN Emulation=20 IP over ATM, IPv6 over ATM=20 VLANs=20 High-Speed Routing=20 I-PNNI, NHRP=20 Java, Tina, Corba architectures=20 Interconnection=20 Network Management, performance=20 CTI (Computer Telephony Integration)=20 Multicast ATM and Internet/Intranet IP and ATM over xDSL=20 Security=20 IP and ATM Telephony=20 Practical experiences results=20 User applications=20 Video (Davic, ...)=20 QoS=20 WDM=20 Optical Switching=20 Scheduling & Resource allocation=20 Services over ATM MPOA, IP Switching, MPLS, Tag Switching, Fast IP, Aris ...=20 Wireless ATM (LEO,MEO GEO, from GSM to UMTS and IMT2000 Hyperlan2, ...) These topics can be discussed in term of concepts, state of the art, standards, implementations, performance, security and confidentiality, traffic management, running experiments, QoS (Quality of Service) and applications.=20 INSTRUCTIONS FOR AUTHORS=20 Mail four copies of a full paper which should be no longer than 10 pages or an extended abstract summarizing an original work. All the manuscripts must be written in English. The top of the first page of each paper should include the title of the paper, authors' name, position, address, telephone and fax numbers, e-mail of the author responsible for correspondence and a list of four keywords.=20 Electronic submissions are strongly encouraged. Acceptable formats are PDF, Postscript, RTF, Word 97. Please use A4 paper format when formatting your submission! Authors of accepted papers will later be required to submit a IEEE copyright form, please assure that you have all necessary authorizations in place. Typing instructions for accepted full papers can be downloaded from http://dongshinu.ac.kr/~idec_du.=20 The deadline for submission of all extended abstracts is September 10, 2000 with notification of acceptance by November 10, 2000. Submission of camera-ready paper is by January 10, 2001.=20 Authors of accepted papers will be invited to submit full-length manuscripts for inclusion in the proceedings.=20 All submitted papers should be sent to the following address:=20 For the worldwide:=20 Mike Myung-Ok LEE=20 IDEC=20 Dongshin University=20 252 Daeho-Dong, Naju=20 Chonnam, 520-714 Korea=20 Phone:82(0)613-330-3195 Fax:82(0)613-330-2911 Mobile:82(0)16-612-2925=20 E-mail: mikelee@dongshinu.ac.kr=20 For Europe :=20 Pascal LORENZ=20 University of Haute Alsace=20 IUT - Department GTR=20 34 rue du Grillenbreit=20 68008 Colmar, France=20 Phone: 33 (0)389202366 Fax: 33 (0)389202359 Mobile: 33 (0)603658042=20 E-mail: lorenz@colmar.uha.fr=20 You can learn more in our Web page at http://dongshinu.ac.kr/~idec_du/ICATM01.html for the latest information concerning the conference.=20 Best papers will be forwarded for consideration in a special issue of the journal Telecommunication Systems published by Baltzer Science Publishers.=20 TUTORIALS AND WORKSHOPS=20 Tutorials and workshops provide overviews of current high interest topics. Proposals for half of full day tutorials are due by September 10, 2000.=20 INTERNATIONAL ADVISORY COMMITTEE=20 R. Addie (Australia) - University of Southern Queensland=20 K. Begain (Jordan) - Mu'tah University=20 A. Benslimane (France) - University of Belfort=20 B. Bing (Singapore) - Ngee Ann Polytechnic=20 D. Bonjour (France) - CNET=20 A. Brandwajn (USA) - University of California Santa Cruz=20 J.P. Coudreuse (France) Mitsubishi=20 J. Crowcroft (UK) University College London=20 B. Gavish (USA) - Vanderbilt University=20 J. Halpern (USA) Newbridge=20 Z. Hulicki (Poland) University of Cracow=20 R. Israel (France) - IEEE=20 S. Komandur (USA) - Ascend Communications=20 D. Kouvatsos (UK) - University of Bradford=20 S. Kumar (USA) Ericsson=20 G.S. Kuo (Taiwan) National Central University=20 F. Le Faucheur (France) - Cisco=20 M. Lee (Korea) Dongshin University=20 P. Lorenz (France) - University of Haute Alsace=20 G. Omidyar (USA) - Computer Sciences Corp.=20 J.J. Pansiot (France) - University of Strasbourg=20 M. Potts (Switzerland) - Martel=20 Z. Mammeri (France) - University of Toulouse=20 N. Mastorakis (Greece) - Military Institutions of University Education=20 S. Moyer (USA) - Bellcore=20 R. Muraine (France) - Newbridge=20 G. Pujolle (France) - University of Versailles-Saint-Quentin=20 S. Rao (Switzerland) - Ascom=20 A. Reid (UK) - British Telecom=20 S. Ritzenthaler (France) - Newbridge=20 P. Rolin (France) - ENST Bretagne=20 R. Saracco (Italy) - CSELT=20 G. Swallow (USA) - Cisco=20 H. Tobiet (France) Clemessy=20 V.A. Villagra (Spain) University of Madrid=20 E. Vazquez Gallo (Spain) University of Madrid=20 IMPORTANT DATES=20 Extended Abstract due: September 10, 2000=20 Notification of acceptance: November 10, 2000=20 Deadline for full-length camera-ready manuscript: January 10, 2001=20 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Jul 6 09:14:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15646 for ; Thu, 6 Jul 2000 09:14:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 87C8844336; Thu, 6 Jul 2000 09:14:01 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by lists.bell-labs.com (Postfix) with ESMTP id AB6F544341 for ; Wed, 5 Jul 2000 20:10:37 -0400 (EDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id RAA22488; Wed, 5 Jul 2000 17:10:35 -0700 (PDT) Message-Id: <200007060010.RAA22488@boreas.isi.edu> To: IETF-Announce: ; Cc: rfc-ed@ISI.EDU, iptel@lists.bell-labs.com Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 05 Jul 2000 17:10:35 -0700 From: RFC Editor Subject: [IPTEL] RFC 2871 on TRIP Framework Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2871 Title: A Framework for Telephony Routing over IP Author(s): J. Rosenberg, H. Schulzrinne Status: Informational Date: June 2000 Mailbox: jdrosen@dynamicsoft.com, schulzrinne@cs.columbia.edu Pages: 25 Characters: 60664 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-iptel-gwloc-framework-06.txt URL: ftp://ftp.isi.edu/in-notes/rfc2871.txt This document serves as a framework for Telephony Routing over IP (TRIP), which supports the discovery and exchange of IP telephony gateway routing tables between providers. The document defines the problem of telephony routing exchange, and motivates the need for the protocol. It presents an architectural framework for TRIP, defines terminology, specifies the various protocol elements and their functions, overviews the services provided by the protocol, and discusses how it fits into the broader context of Internet telephony. This document is a product of the IP Telephony Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000705170749.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2871 --OtherAccess Content-Type: Message/External-body; name="rfc2871.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000705170749.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Jul 6 10:23:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17003 for ; Thu, 6 Jul 2000 10:23:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2A18A443F5; Thu, 6 Jul 2000 10:22:17 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66]) by lists.bell-labs.com (Postfix) with ESMTP id 88D5F443F3 for ; Thu, 6 Jul 2000 10:22:14 -0400 (EDT) Received: by dnspri.npac.com; id JAA05024; Thu, 6 Jul 2000 09:22:14 -0500 (CDT) Received: from unknown(208.143.39.132) by dnspri.npac.com via smap (V5.0) id xma004904; Thu, 6 Jul 00 09:21:40 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Thu, 6 Jul 2000 09:21:02 -0500 Message-ID: From: James Yu To: "'Jonathan Rosenberg'" , "'Henning Schulzrinne'" Cc: iptel@lists.bell-labs.com Subject: RE: [IPTEL] RFC 2871 on TRIP Framework Date: Thu, 6 Jul 2000 09:19:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Jonathan, Henning, A few comments on Section 11, "Number Translations": - 1st paragraph, 3rd line: change "telephone" to "phone" for consistency. - 2nd paragraph, 1st line: change "don't represent GSTN terminals" to "don't indicate the physical locations of the associated GSTN terminals." - 2nd paragraph, 3rd line: change "LNP numbers" to "ported phone numbers" and refer to draft-foster-e164-gstn-np-01.txt (July 2000). - 2nd paragraph, 4th line: change "routable telephone numbers" to "routable numbers." Those are the "network routing numbers" in the number portability (NP) environment. You may want to add that a freephone number can be mapped to a POTS number (or subscriber phone number), and then be mapped again to a routable number when NP is involved. You may also want to add that the subscriber phone numbers are routable numbers when NP is not involved. James _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Jul 6 11:35:49 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18777 for ; Thu, 6 Jul 2000 11:35:49 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 05B464443E; Thu, 6 Jul 2000 11:27:02 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id A4C174442C for ; Thu, 6 Jul 2000 11:26:59 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA11366; Thu, 6 Jul 2000 11:28:18 -0400 (EDT) Message-ID: <3964A5D7.4B2A88D2@dynamicsoft.com> Date: Thu, 06 Jul 2000 11:29:27 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: James Yu Cc: "'Jonathan Rosenberg'" , "'Henning Schulzrinne'" , iptel@lists.bell-labs.com Subject: Re: [IPTEL] RFC 2871 on TRIP Framework References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Well, this just issued as rfc2871, which means that the time has past for changes. RFCs cannot be changed. Comments on documents must made before they go to rfc. -Jonathan R. James Yu wrote: > > Jonathan, Henning, > > A few comments on Section 11, "Number Translations": > > - 1st paragraph, 3rd line: change "telephone" to "phone" for consistency. > > - 2nd paragraph, 1st line: change "don't represent GSTN terminals" to "don't > indicate the physical locations of the associated GSTN terminals." > > - 2nd paragraph, 3rd line: change "LNP numbers" to "ported phone numbers" > and refer to draft-foster-e164-gstn-np-01.txt (July 2000). > > - 2nd paragraph, 4th line: change "routable telephone numbers" to "routable > numbers." Those are the "network routing numbers" in the number portability > (NP) environment. You may want to add that a freephone number can be mapped > to a POTS number (or subscriber phone number), and then be mapped again to a > routable number when NP is involved. You may also want to add that the > subscriber phone numbers are routable numbers when NP is not involved. > > James > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Jul 7 17:35:16 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13763 for ; Fri, 7 Jul 2000 17:35:16 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0FD66443D4; Fri, 7 Jul 2000 17:33:43 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 8A7F1443B0 for ; Fri, 7 Jul 2000 17:33:41 -0400 (EDT) Received: from ind.cs.columbia.edu (ind.cs.columbia.edu [128.59.19.27]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA19368; Fri, 7 Jul 2000 17:33:39 -0400 (EDT) Received: (from lennox@localhost) by ind.cs.columbia.edu (8.9.3/8.9.3) id RAA14440; Fri, 7 Jul 2000 17:33:38 -0400 (EDT) Date: Fri, 7 Jul 2000 17:33:38 -0400 (EDT) Message-Id: <200007072133.RAA14440@ind.cs.columbia.edu> From: Jonathan Lennox To: James Undery Cc: iptel@lists.bell-labs.com Subject: Re: [IPTEL] draft-ietf-cpl-01 the DTD In-Reply-To: References: Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com On Wed, June 21 2000, "James Undery" wrote to "lennox@cs.columbia.edu, iptel@lists.bell-labs.com" saying: > Hi, > > Just a quick observation, I know The CPL DTD got a mauling on the > iptel mailing group a while back, but I think Nilo missed a mistake in the > DTD, > > > > is what the text describes, rather than > > > > in the draft's DTD. No, the idea was that you would have multiple timezones, each with one standard time and possibly one daylight time. I don't think this actually works, though; more about this in a followup message. > > I am also interested in how seriously XML schemas are being considered as > I think there are some areas where the DTD could be tightened up, but, > don't want to waste time if the DTD is binned in favour of a schema. Since XML schemas are a) not finished yet, b) not nearly as widely implemented as DTDs, and c) specified in two huge, impenetrable (to me) specifications, I don't think it's likely unless someone else wants to volunteer to write up a schema for CPL. So comments on the DTD are very welcome. -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Jul 7 18:05:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14340 for ; Fri, 7 Jul 2000 18:05:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9B6A2443B0; Fri, 7 Jul 2000 18:04:57 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id DB31344336 for ; Fri, 7 Jul 2000 18:04:54 -0400 (EDT) Received: from ind.cs.columbia.edu (ind.cs.columbia.edu [128.59.19.27]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id SAA20275 for ; Fri, 7 Jul 2000 18:04:53 -0400 (EDT) Received: (from lennox@localhost) by ind.cs.columbia.edu (8.9.3/8.9.3) id SAA14544; Fri, 7 Jul 2000 18:04:52 -0400 (EDT) Date: Fri, 7 Jul 2000 18:04:52 -0400 (EDT) Message-Id: <200007072204.SAA14544@ind.cs.columbia.edu> From: Jonathan Lennox To: iptel@lists.bell-labs.com In-Reply-To: References: <2E532B03F035D3119AF40000F80932C37B6EAC@crchy28d.us.nortel.com> Subject: [IPTEL] CPL: Timezone issues Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com I think I've mentioned this before on the list, but I'll mention it now as a follow-up to my two earlier messages. The scheme for timezones I came up with in the CPL -01 draft doesn't work. Timezones are, unfortunately, much more complicated than can be described by the simple scheme I came up with. Politicians over the years have come up with *amazingly* bizarre timezone rules and transitions. The best reference for all things timezone related is the Olson TZ database and its mailing list archive: . This problem has already been confronted by an IETF working group: CalSch had to deal with what timezone scheduled events take place in. Therefore, one thought for timezones would be to deal with them simply by referencing section 4.8.3.5 of RFC 2445; the grammar for the CPL tag would become simply Tag: timezone Parameters: name Name of this timezone tzurl Valid RFC 2445 TZURL Outputs: none The problem with this, however, is that as far as I know no one actually has any TZURLs deployed anywhere. There's been some talk about defining a standard repository for these, but it doesn't seem to have come to anything. Additionally, putting this in the CPL spec means that any CPL implementor also has to build most of an RFC 2445 parser, which seems like a bad idea. Another possibility would be to reference the names used in the Olson TZ database directly; this is liberally-licensed open-source code, and it's already the database used for system timezone information on a wide variety of Unix systems. However, it's not a standard of any kind, so citing it normatively would probably be bad. A third possibility would be (again referencing RFC 2445) to use their TZID parameter, from section 4.8.3.1. This is defined as follows: Description: This is the label by which a time zone calendar component is referenced by any iCalendar properties whose data type is either DATE-TIME or TIME and not intended to specify a UTC or a "floating" time. The presence of the SOLIDUS character (US-ASCII decimal 47) as a prefix, indicates that this TZID represents an unique ID in a globally defined time zone registry (when such registry is defined). Note: This document does not define a naming convention for time zone identifiers. Implementers may want to use the naming conventions defined in existing time zone specifications such as the public-domain Olson database [TZ]. The specification of globally unique time zone identifiers is not addressed by this document and is left for future study. This is more-or-less the same solution I came up with in CPL draft -00, which everyone hated, except better explained; that is, timezone names are entirely locally-defined at the server. Probably the best compromise would be to combine cases 1 and 3; a tag has either the parameter "tzid" or "tzurl", both as specified in RFC 2445, and the script server SHOULD either handle them or complain about them at script upload time. Hopefully, sometime in the future someone will build an actual normative globally-unique timezone registry, and we can reference it then. Any thoughts on all this? -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Jul 7 18:17:41 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14580 for ; Fri, 7 Jul 2000 18:17:41 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BAAC744396; Fri, 7 Jul 2000 18:17:21 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 45A4044386 for ; Fri, 7 Jul 2000 18:17:19 -0400 (EDT) Received: from ind.cs.columbia.edu (ind.cs.columbia.edu [128.59.19.27]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id SAA20690 for ; Fri, 7 Jul 2000 18:17:18 -0400 (EDT) Received: (from lennox@localhost) by ind.cs.columbia.edu (8.9.3/8.9.3) id SAA14574; Fri, 7 Jul 2000 18:17:18 -0400 (EDT) Date: Fri, 7 Jul 2000 18:17:18 -0400 (EDT) Message-Id: <200007072217.SAA14574@ind.cs.columbia.edu> From: Jonathan Lennox To: iptel@lists.bell-labs.com In-Reply-To: <200007072204.SAA14544@ind.cs.columbia.edu> References: <2E532B03F035D3119AF40000F80932C37B6EAC@crchy28d.us.nortel.com> <200007072204.SAA14544@ind.cs.columbia.edu> Subject: [IPTEL] CPL: H.323 issues Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com The primary area still missing in the CPL spec is H.323 work. I'm unfortunately not very knowlegeable about this, so if some H.323 experts could assist with this it would be very helpful. Here are the general issues that I feel need to be addressed: 1. I understand that work is in progress to define an H.323 url as an annex of the H.323 specification. What is the status of this? Are copies of available? Will these URLs be appropriate to use in CPL and tags? 2. Is the unpacking of H.323 addresses as specified for CPL's address subfield matching correct, and complete for at least a useful subset of H.323 addresses? 3. What free-form strings does H.323 signalling carry that a CPL should be able to match? I understand H.225 has a "data" string, but it's not clear to me what it's for. 4. Is there some H.323 counterpart to SIP caller preferences and callee capabilities that should either be used or mapped into CPL, for and ? Since Our Esteemed Working Group Chair has expressed a strong interest in moving CPL along to Proposed Standard soon, these points *need* to be addressed. If no one else comments on them, I'll have to guess based on my own (very limited) understanding of H.323, which will probably mean a much weaker CPL specification all around. -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Jul 7 18:21:38 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14643 for ; Fri, 7 Jul 2000 18:21:37 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D96D7443F9; Fri, 7 Jul 2000 18:19:32 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 2E522443F1 for ; Fri, 7 Jul 2000 18:19:28 -0400 (EDT) Received: from ind.cs.columbia.edu (ind.cs.columbia.edu [128.59.19.27]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id SAA20757 for ; Fri, 7 Jul 2000 18:19:27 -0400 (EDT) Received: (from lennox@localhost) by ind.cs.columbia.edu (8.9.3/8.9.3) id SAA14589; Fri, 7 Jul 2000 18:19:27 -0400 (EDT) Date: Fri, 7 Jul 2000 18:19:27 -0400 (EDT) Message-Id: <200007072219.SAA14589@ind.cs.columbia.edu> From: Jonathan Lennox To: iptel@lists.bell-labs.com Subject: Re: [IPTEL] corrections to CPLv2 DTD and some text In-Reply-To: <9DBEF0AB0E49D311AD7D005004D4FB50024C2B30@eamlynt751.ena-east.ericsson.se> References: <9DBEF0AB0E49D311AD7D005004D4FB50024C2B30@eamlynt751.ena-east.ericsson.se> Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com My *profound* apologies for taking so long to get back to this. I've been swamped. On Tue, May 2 2000, "Nilo Mitra" wrote to "'iptel@lists.research.bell-labs.com', 'lennox@cs.columbia.edu', 'schulzrinne@cs.columbia.edu'" saying: > Here are some corrections to the DTD of the CPL version 2 document, > draft-ietf-iptel-cpl-01.txt, dated March 10, 2000. Wonderful -- thank you. I'm working on the next revision of the document. (More general CPL comments will follow in a later message.) > I am working on the assumption that the text takes precedence over the DTD, > and therefore I have corrected the CPLv2 DTD to conform to the intent stated > in the text. I do realise that the CPL DTD is not sufficient for a cpl > script's validity but feel that it should accurately reflect the text as far > as is possible. Think of my efforts as making corrections to the CPL DTD > syntax using DTD and XML rules to allow for greater expressivity (if that's > a word). This is true; however, it may be that the text was unclear in some sections. > 1. The preamble is not needed, as a DTD is not an > XML document. Not a standalone document, anyway, I presume you mean? > 2. Enclose the whole thing within: > .... > ]> The W3C's DTDs (e.g. ) don't do this. Is it really necessary/appropriate? > 3. Is it really intended that the timezone information can be included more > than once, as described by the asterisk (0 or more) in the definition of the > top level element > namely ? > > I suspect it should be 0 or 1 in which case a "?" should be used to qualify > it so that it reads incoming? )>. It *is* possible (though perhaps not terribly likely) that someone would want to be able to say "do such-and-such between 9 am and 5 pm Eastern Time, and such-and-such between 8 pm and 9 pm Pacific Time". This could actually be useful if you're specifying rules in timezones with different DST rules; otherwise it's just a notational convenience. I see no reason not to support it, though. > 4. It would be good to write the top level element as > > thereby not requiring any change to the top level structure when there are > additional items added to the ancillary information beyond the currently > supported "timezone". Good idea. Though presumably it should either be "%Ancillary;" or "(%Ancillary;)?" depending on how the Ancillary entity is written. > 5. The address-switch node or element as currently written, namely > > would suggest that the not-present element can potentially be present > multiple times. This element definition should be rewritten as > It doesn't make sense to have not-present occur multiple times, but it could potentially (I think) make sense for some address tags to occur after the not-present tag, since order is significant in switches. Unfortunately, the DTD regex syntax for element tags can't express this concisely. I suppose it could be: but that's awfully ugly, and leads to exponential explosion if we add more occurs-anywhere-but-only-once tags. My thought was to just throw all the tags which can occur anywhere into a fixed bag, and describe the only-once properties in the text. Note that my I *will* change address-switch from 1-or-more address tags to 0-or-more, because is sensible. > 6. The attribute list for
should contain only one of "is", > "subdomain-of" or "contains", but this limitation is not perfectly expressed > in the syntax I don't think you can use alternation in ATTLISTs; from my reading of section 3.3 of the XML spec, an ATTLIST only consists of a list of AttDefs, with no other structure to them. [Comments 7 and 8 elided; they carry over 5 and 6 naturally to string-switch, and my same comments apply.] [First half of Comment 9 elided, similarly] > As the text says that the not-present output is never true for a > time-switch, why not leave it out altogether from the definition of the DTD > so that it becomes > I put it in so that the handling of switches could be more generic. I don't feel too strongly about this one way or the other, though. > 10. A propos the