From owner-pint-outgoing@lists.research.bell-labs.com Mon Jan 3 10:35:25 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02857 for ; Mon, 3 Jan 2000 10:35:24 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id C831552E3; Mon, 3 Jan 2000 10:29:34 -0500 (EST) Delivered-To: pint-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id E6EB452E8; Mon, 3 Jan 2000 10:29:33 -0500 (EST) Delivered-To: pint-local@paperless.dnrc.bell-labs.com To: pint@lists.research.bell-labs.com Date: Mon, 3 Jan 2000 10:25:33 -0500 Message-ID: <003001bf55fe$7b90bb00$0401a8c0@oleane.com> From: "Peter Lewis" Sender: owner-pint@lists.research.bell-labs.com Precedence: bulk To: Subject: VoDSL 2000 Conference Date: Mon, 3 Jan 2000 16:23:02 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002D_01BF5606.CEA9F2E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 This is a multi-part message in MIME format. ------=_NextPart_000_002D_01BF5606.CEA9F2E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, =20 The VoDSL 2000 Conference will stand in Paris next 28-31 March. Key = speakers, case studies: take a look at: = http://www.upperside.fr/bavodsl.htm =20 Regards ------=_NextPart_000_002D_01BF5606.CEA9F2E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

The VoDSL 2000 Conference will stand = in Paris=20 next 28-31 March. Key speakers, case studies: take a look at: http://www.upperside.fr/bavo= dsl.htm

Regards

------=_NextPart_000_002D_01BF5606.CEA9F2E0-- --------- This message came from the IETF PINT Working Group Mailing List. From owner-pint-outgoing@lists.research.bell-labs.com Fri Jan 7 06:44:14 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14225 for ; Fri, 7 Jan 2000 06:44:14 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 58C8252F2; Fri, 7 Jan 2000 06:41:23 -0500 (EST) Delivered-To: pint-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id BD91C52F7; Fri, 7 Jan 2000 06:41:22 -0500 (EST) Delivered-To: pint-local@paperless.dnrc.bell-labs.com Message-Id: <200001071139.GAA14129@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: pint@lists.research.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pint-conf-01.txt Date: Fri, 07 Jan 2000 06:39:30 -0500 Sender: owner-pint@lists.research.bell-labs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the PSTN and Internet Internetworking Working Group of the IETF. Title : A proposal for new PINT building blocks with applications to Conference Calling Author(s) : L. Slutsman Filename : draft-ietf-pint-conf-01.txt Pages : 8 Date : 06-Jan-00 The main purpose of this document is to propose new Conference Call Service for the PINT WG. This document contains a description of a Conference Call Service for PINT (CCSP), provides a non-exhaustive list of PINT requests (PINT Conference Building Blocks) to support them, and describes the needed extensions to the current PINT architecture. Current PINT services, such as Request to Call, use the Internet only to deliver service requests from an IP host to the PSTN to be executed there. However, limiting the PINT Conference service to just delivering the request to allocate the conference bridge to the PSTN, would hardly justify the practicality of the service. The PINT Conference Service described in this document allows for the following functionality: o manual or automated negotiation of conference parameters, such as date, agenda, etc., before the PSTN resources are committed; o requesting the PSTN to allocate the conference bridge; o requesting the PSTN to start the conference automatically by calling each participant at the specified time; A proposal for new PINT building blocks with applications to Conference Calling o monitoring real-time conference events by keeping track of the current speaker as well as of participants leaving or joining the conference bridge. Unlike the current PINT services, which require exactly one request per service, the proposed Conference Call Service with the above functionality, needs to be mapped into a number of PINT requests. In this paper we propose a non-exhaustive list of PINT requests to support the basic CCSP functionality. We also discuss the extensions to the current PINT architecture that are needed to support the CCSP. If the service proposal is approved by the PINT WG, the protocol issues such as profiling SIP, SDP, etc. will be addressed in the forthcoming documents. This document is intended for the PSTN-Internet Interworking (PINT) worki A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pint-conf-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pint-conf-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pint-conf-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000106131252.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pint-conf-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pint-conf-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000106131252.I-D@ietf.org> --OtherAccess-- --NextPart-- --------- This message came from the IETF PINT Working Group Mailing List. From owner-pint-outgoing@lists.research.bell-labs.com Fri Jan 7 19:57:39 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29596 for ; Fri, 7 Jan 2000 19:57:39 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id C951452B6; Fri, 7 Jan 2000 19:53:36 -0500 (EST) Delivered-To: pint-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 4ACA952C4; Fri, 7 Jan 2000 19:53:36 -0500 (EST) Delivered-To: pint-local@paperless.dnrc.bell-labs.com Date: Fri, 7 Jan 2000 19:51:45 -0500 (EST) From: Henning Schulzrinne Message-Id: <200001080051.TAA16209@tune.cs.columbia.edu> To: pint@lists.research.bell-labs.com Subject: CFP on JCN Special Issue on Internet QOS - Deadline Extended List: pint@lists.research.bell-labs.com Sender: owner-pint@lists.research.bell-labs.com Precedence: bulk JOURNAL OF COMMUNICATIONS AND NETWORKING (JCN) CALL FOR PAPERS - SPECIAL ISSUE ON QoS IN IP NETWORKS JUNE, 2000 ---> DEADLINE EXTENDED to January 31, 2000 A Special Issue of JCN dedicated to the realization of QoS-sensitive services in IP networks will be published in June, 2000. It will be Guest Edited by Prof. Henning Schulzrinne of Columbia University, Prof. Hideo Miyahara of Osaka University, and Prof. Luigi Fratta of the University of Milan. The topics include but are not limited to: Differentiated Services Integrated Services MPLS Real-time multicast IP network traffic engineering Performance measurement and evaluation Pricing and billing User perception of QOS QOS policy management Adaptive and other new service models Light-weight reservation protocols and aggregation Continuing JCN's tradition of fast turnaround together with full peer reviews, the following schedule has been set: Jan. 31, 2000 Submit manuscript via web page (see below) Mar. 31, 2000 First reviews returned to author, revisions returned within three weeks June, 2000 Special Issue published The guest editors are Prof. Luigi Fratta Prof. Hideo Miyahara Prof. Henning Schulzrinne Papers should be submitted via the procedure described at http://www.cs.columbia.edu/~hgs/edas/JCN Only PostScript and PDF formats are accepted. Further information about JCN is available at http://JCN.snu.ac.kr. JCN is a high-quality quarterly archival journal, published by the Korean Institute of Communications Sciences with the technical cosponsorship of the IEEE Communications Society, covering the fields of Communication Theory and Systems, Wireless Communications, and Networks and Services. JCN began publication in March, 1999. --------- This message came from the IETF PINT Working Group Mailing List. From owner-pint-outgoing@lists.research.bell-labs.com Sun Jan 9 23:18:16 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14312 for ; Sun, 9 Jan 2000 23:18:15 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 3BE3A52C4; Sun, 9 Jan 2000 23:15:23 -0500 (EST) Delivered-To: pint-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id AFA4952D6; Sun, 9 Jan 2000 23:15:22 -0500 (EST) Delivered-To: pint-local@paperless.dnrc.bell-labs.com User-Agent: Microsoft Outlook Express Macintosh Edition - 5.01 (1630) Date: Sun, 09 Jan 2000 23:13:59 -0500 Subject: Discussion on PINT Conference Call Draft From: David Shrader To: PINT List , "Slutsman, Lev A, ALSVC" Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-pint@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Lev, Thanks for bringing up the conference call topic. I find it to be an interesting service that I think could be quite useful. I think, however, that there are many things specified here that don't really belong in PINT. All of the material related to the committing of actions and coordination of the conference session prior to setup is really application specific and is outside the scope of a protocol like PINT, in my opinion. I think the capabilities to the have an IP host which is implementing such a conferencing service to request the PSTN to actually set up the call is the type of capability for PINT to address. One additional point, the discussion related to fax data. It seems to me that from the PINT Client to PSTN point of view this could be seen as simply another multiparty call requesting the fax to multiple destinations (which, the PSTN would translate to a one-many broadcast arrangement and not really a muliparty conference due to the bilateral handshakes required for a standard fax). From the PINT server perspective, this does not need to be related to the voice conference at all and may, in fact, be offered via another PSTN provider. David --------- This message came from the IETF PINT Working Group Mailing List. From owner-pint-outgoing@lists.research.bell-labs.com Tue Jan 11 05:56:00 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03244 for ; Tue, 11 Jan 2000 05:56:00 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 93A7052D6; Tue, 11 Jan 2000 05:45:46 -0500 (EST) Delivered-To: pint-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 1C9A152DB; Tue, 11 Jan 2000 05:45:44 -0500 (EST) Delivered-To: pint-local@paperless.dnrc.bell-labs.com To: pint@lists.research.bell-labs.com Date: Tue, 11 Jan 2000 05:43:02 -0500 Message-ID: <008501bf5c20$6b51e020$0401a8c0@oleane.com> From: "Peter Lewis" Sender: owner-pint@lists.research.bell-labs.com Precedence: bulk To: Subject: SIP 2000 Call for Paper Date: Tue, 11 Jan 2000 11:41:20 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0082_01BF5C28.C79F0D00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 This is a multi-part message in MIME format. ------=_NextPart_000_0082_01BF5C28.C79F0D00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SIP 2000: beyond H.323?=20 Discussing and debating in Paris May 10-12. A CFP is online at: http://www.upperside.fr/basip.htm =20 ------=_NextPart_000_0082_01BF5C28.C79F0D00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

SIP 2000: beyond H.323? =

Discussing and debating in Paris May = 10-12.

A CFP is online at:

http://www.upperside.fr/basip.= htm

------=_NextPart_000_0082_01BF5C28.C79F0D00-- --------- This message came from the IETF PINT Working Group Mailing List. From owner-pint-outgoing@lists.research.bell-labs.com Tue Jan 11 09:09:30 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09808 for ; Tue, 11 Jan 2000 09:09:28 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 7CDE552DD; Tue, 11 Jan 2000 08:56:56 -0500 (EST) Delivered-To: pint-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id B1A7552DC; Tue, 11 Jan 2000 08:56:55 -0500 (EST) Delivered-To: pint-local@paperless.dnrc.bell-labs.com Message-ID: <387A298D.625BD7B5@bell-labs.com> Date: Mon, 10 Jan 2000 13:48:45 -0500 From: Igor Faynberg Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: David Shrader Cc: PINT List , "Slutsman, Lev A, ALSVC" Subject: Re: Discussion on PINT Conference Call Draft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pint@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit David Shrader wrote: > > I think, however, that there are many things specified here that don't > really belong in PINT. All of the material related to the committing of > actions and coordination of the conference session prior to setup is really > application specific and is outside the scope of a protocol like PINT, in my > opinion. It is absolutley true that the subject is OUTSIDE of the PINT charter, which is why we have paid little attention to it while completing the work of the charter. Steve and I have discussed this subject with the ADs six months ago, and as the result of the discussion we admitted the first copy of this draft to PINT as a PINT WG document. The present document is a follow-up to replace the expiring draft. I personally would like to finish whatever little is left to finish with the present charter (see the Chairs' State of The Group Address, which will be sent today) before embarking full speed on a new project, but the discussion is welcome. My view of Lev's proposal is that it is consistent with the spirit of the present PINT charter (i.e., services initated with the PSTN), and I have a clear understanding of the need for the protocol as proposed by Lev. We must, however, make sure that the protocol can INTERWORK with the IN Call Party Handling (CPH) standardized in the ITU-T IN CS-2. A few experts had looked at Lev's proposal, which was brought to ITU SG 11 by Hui-Lan, and told me they agree with it and felt it could interwork with the CPH. So, yes, we can discuss the draft--although let us concentrate on technical issues, and when it is clear where we are going we will decide whether this should be done in re-chartered PINT, or another group, or independent of any group. But we also need to finish the work WITHIN the charter! With best regards, Igor --------- This message came from the IETF PINT Working Group Mailing List. From owner-pint-outgoing@lists.research.bell-labs.com Tue Jan 11 18:50:30 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23372 for ; Tue, 11 Jan 2000 18:50:29 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id AE09652AB; Tue, 11 Jan 2000 18:47:28 -0500 (EST) Delivered-To: pint-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 16F4552DF; Tue, 11 Jan 2000 18:47:27 -0500 (EST) Delivered-To: pint-local@paperless.dnrc.bell-labs.com Message-ID: <387BC0F6.737407F6@bell-labs.com> Date: Tue, 11 Jan 2000 18:47:02 -0500 From: Igor Faynberg Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: pint Cc: sob@harvard.edu, vern@aciri.org, smb@research.att.com Subject: State of the Working Group X-Priority: 2 (High) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pint@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Dear Members of PINT WG: Steve and I wish you best for the New Year! It is time to review the state of our working group, which is what we do in this message. There are still two items in our charter (the PINT Protocol RFC and the PINT MIB RFC) that we need to complete, and we address those items first. Then, there is a proposal for the new work outside of our old charter, and we address that, too. Finally, there is an on-going liaison with ITU-T SG 11, carried by ever-energetic Hui-Lan, and we will attach the latest news. So, here we go. 1. PINT Protocol Our RFC candidate "The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services" (draft-ietf-pint-protocol-02.txt) has undergone a thorough IESG review (pretty much positive), with a number of issues had been fed back. We have been discussing those with Scott and Lawrence, who are working on addressing them right now. With the omission of purely editorial comments and what the authors of comments identified as "nits," here are what we thing most important IESG suggestions: > It is better if the multipart types have a specific subtype and not use > mixed. For example multipart/pint. The fallback is always mixed for unknown > multipart subtypes, so this should not create any problems with > implementations. > > They should look at RFC 2387, which is multipart/related, which is supposed > to be used when more than one bodypart should be "grouped" together. That > is fine with me as a specific MIME-type. This should be checked with Ned > Freed as the "expert" on mimetypes. > > 2387 The MIME Multipart/Related Content-type. E. Levinson. August > 1998. (Format: TXT=18864 bytes) (Obsoletes RFC2112) (Status: PROPOSED > STANDARD) > > 3.4.2. Support for Data Objects within PINT > ... > The Media sub-field definition is relaxed to accept all of the discrete > "top-level" media types defined in [4]. In the milestone services the > discrete type "video" is not used, and the extra types "data" and "control" > are likewise not needed. The use of these types is not precluded, but the > behaviour expected of a PINT Gateway receiving a request including such a > type is not defined here. > > given the preceeding > > 3.3. REQUIRED and OPTIONAL elements for PINT compliance > ... > The "Require:" SIP header and the "require" attribute provide a mechanism > that can be used by clients and servers to signal their need and/or > ability to support specific "new" PINT protocol elements. > > has vague echos of a mandatory extensions loophole. especially given > > 3.4.4. The "require" attribute > > According to the SDP specification, a PINT server is allowed simply to > ignore attribute parameters that it does not understand. In order to > force a server to fail a request if it does not understand one of the > PINT attributes, a client should use the "require" attribute, specified > as follows: > > possibly s/fail/decline/ and let the requestor fail. > > and the server gets the blame in > > 3.5.4. The "Require:" header for PINT > ... > A client should only include a Require: header where it truly requires the > server to fail the request if the option is not supported. > > again s/fail/decline/ or something similar. > > --- > > 3.4.2.3. Support for GSTN-based Data Objects in PINT > > perpetuates the pull as opposed to push model in > > For example: > c= TN RFC2543 +1-201-406-4090 > m= text 1 fax plain > a=fmtp:plain opr:APPL.123.456 > > means send me the data that is indexed ON THE GSTN by the reference value > > seems to assume that +1-201-406-4090 == me, where it could be anybody to > whom the requestor wishes to receive the data object. > 3.5.3.1. Opening a monitoring session with a SUBSCRIBE request > > neglects to say to what entity SUBSCRIBE requests are sent. one would > assume a gateway, and this is reinforced by text in that section > > A successful response to the SUBSCRIBE request includes the session > description, according to the Gateway. > > but that is mildly ambiguous. i would let it pass, except that > > 3.5.3.3. Closing a monitoring session with an UNSUBSCRIBE request > At some point, either the Client's representative User Agent Server or the > Gateway may decide to terminate the monitoring session. This is achieved > by sending an UNSUBSCRIBE request to the correspondent server. > > i.e. a gateway may send an UNSUBSCRIBE? this seems quite odd, when it would > seem more sensible to send a NOTIFY with Expires: 0. > > i think the answer is hidden behind > > If the subscription period specified by the Client has expired, then the > Gateway may send an immediate UNSUBSCRIBE request to the Client's > representative User Agent Server. This ensures that the monitoring session > always completes with a UNSUBSCRIBE/response exchange, and that the > representative User Agent Server can avoid maintaining state in certain > circumstances. > > but it's all a bit confusing. maybe state transition diagrams would help. > > > --- > > 1. A BYE indicates that the requesting client will clear out all call > state as soon as it receives a successful response. A client SHOULD NOT > send a SUBSCRIBE request after it has sent a BYE. > > is contradicted by > > 2. A server may return an Expires: header within a successful response > to a BYE request. This indicates for how long the server will retain > session state about the telephone network session. At any point during > this time, a client may send a SUBSCRIBE request to the server to learn > about the session state. > > --- > 3. When engaged in a SUBSCRIBE/NOTIFY monitoring session, PINT servers > that send BYE to a URL listed in the Contact: header of a client request > > but the server sending a BYE was never mentioned in the [UN]SUBSCRIBE/NOTIFY > description! > > this thing REALLY needs a complete state machine description so it is very > clear what messages may be sent to whom and when. > > > The SUBSCRIBE request indicates that a user wishes to receive information > about the status of a session. The request identifies the session of > interest normally by including the original session description along > with the request. > > truely unambiguous? i send a page. it is not answered. i, being a very > impatient type, resend the same message to cause a second page. i wish to > monitor the second, or maybe check on progress of the first > > or, if this is an sdp global session id, then say so in literal words. or, > is it a sip session id as implied in > > 3.5.3.4. Timing of SUBSCRIBE requests > As it relies on the Gateway having a copy of the INVITEd session > description ... > > ...[Security considerations] seem a delicate balance that i am not sure would make conservatives > completely comfortable. e.g. > > A Requesting User has a reasonable expectation that their requests for > service are confidential. For some PINT services, no content data is > carried over the Internet; however, the telephone or fax numbers of the > parties to a resulting service calls may be considered sensitive. As a > result, it is likely that the Requestor (and their PINT service > provider) will require that any request that is sent across the > Internet be protected against eavesdroppers; in short, the requests > should to be encrypted. > > /should to/SHOULD/ maybe even MUST > > and should > > Thus, to ensure that the session identifier is not guessable the > techniques described in section 6.3 of [17] can be used when generating > the origin-field for a session description to be used inside a PINT > INVITE message. If all requests from (and responses to) a particular > PINT requesting entity are protected, then this is not needed. Where > such a situation is not assured, AND where session monitoring is > supported, then a method by which an origin-field within a session > description is not guessable SHOULD be used. > > specify HOW the protection is done so implementations are compatible? > > --- Many thanks to those who read the document so carefully! 2. PINT MIB. Well, the draft "Management Information Base for the PINT Services Architecture" () has been published by Dan and Myrali in October. Please read it; it will go for the WG last call as soon as we clear the protocol RFC. 3. New proposed PINT work item (Conference Calling) A new version of "A proposal for new PINT building blocks with applications to Conference Calling" () was just issued by Lev and posted to our Web site. Again, this work proposes the building blocks for services that are outside of the present PINT charter; however, with these blocks about ANY service may be constructed, and, in addition it fully . This particular work got much (positive) interest from call party handling experts in SG 11, of which later. Please feel free to comment on this. 4. Liaison with SG 11 Hui-Lan has introduced--on behalf of ISOC--the PINT Protocol, MIB, and new building blocks to WP 4/11, and Q.5/11. (She also introduced the SPIRITS draft and Antti's draft.) All material was received well. The new ITU Recommendation Q.1231 will describe supported PINT services. The architecture will be presented in CS-4 (Draft ITU-T Recommendation Q.1244). Hui-Lan will report on this in more detail in due time. So, that is where we are right now. With thanks for your support and best wishes for the year 2000, Steve Bellovin Igor Faynberg --------- This message came from the IETF PINT Working Group Mailing List. From owner-pint-outgoing@lists.research.bell-labs.com Wed Jan 26 07:18:06 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01430 for ; Wed, 26 Jan 2000 07:18:06 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 3A28752E7; Wed, 26 Jan 2000 07:15:24 -0500 (EST) Delivered-To: pint-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A1A6752E8; Wed, 26 Jan 2000 07:15:23 -0500 (EST) Delivered-To: pint-local@paperless.dnrc.bell-labs.com To: pint@lists.research.bell-labs.com Date: Wed, 26 Jan 2000 07:11:24 -0500 Message-ID: <008c01bf67f6$3f458680$0401a8c0@oleane.com> From: "Peter Lewis" Sender: owner-pint@lists.research.bell-labs.com Precedence: bulk To: Subject: SIP 2000 Call for Papaer Date: Wed, 26 Jan 2000 13:09:46 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0089_01BF67FE.9E62EA60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 This is a multi-part message in MIME format. ------=_NextPart_000_0089_01BF67FE.9E62EA60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SIP 2000: Beyond H.323? A scientific committe composed of the most = eminent experts in this technology will review the abstracts submitted = from the Call For Papers: http://www.upperside.fr/basip.htm Take a look at the exhibition list. ------=_NextPart_000_0089_01BF67FE.9E62EA60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

SIP 2000: Beyond H.323? A scientific = committe=20 composed of the most eminent experts in this technology will review the=20 abstracts submitted from the Call For Papers:

http://www.upperside.fr/basip.= htm

Take a look at the exhibition=20 list.

------=_NextPart_000_0089_01BF67FE.9E62EA60-- --------- This message came from the IETF PINT Working Group Mailing List.