idnits 2.17.1 draft-ietf-pint-basics-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 318 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 30 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 19 has weird spacing: '... may be updat...' == Line 25 has weird spacing: '...ries on ftp....' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 1997) is 9843 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force PINT WG 3 INTERNET-DRAFT Scott Petrack 4 draft-ietf-pint-basics-00.txt VocalTec Communications Ltd. 5 21st Nov 1997 petrack@vocaltec.com 6 Expires: 21st May 1997 8 IP Access to PSTN Services: 9 Basic Service Requirements, Definitions, and Architecture 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, and 15 its working groups. Note that other groups may also distribute working 16 documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference material 21 or to cite them other than as ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Distribution of this document is not limited. 31 This document is intended for the PSTN-Internet Interworking (PINT) 32 working group of the Internet Engineering Task Force. Comments are 33 solicited and should be addressed to the working group's mailing list at 34 pint@lists.research.bell-labs.com and/or the author at 35 petrack@vocaltec.com 37 Abstract 39 This document specifies those PSTN services which will be accessible 40 from the Internet via the PINT protocols. It defines these services in 41 terms of a simple set of architectural elements and atomic services. It 42 gives some concrete examples of these services, and indicates how to 43 build the examples out of the presented atomic services. 45 1. Introduction 47 The need to invoke and access a certain number of PSTN services from the 48 Internet has been identified by many different groups (public and 49 private network operators, call centre service providers, equipment 50 vendors, etc.). Obviously, before any protocol or its details can be 51 identified as suitable for the purpose, we must specify exactly which 52 PSTN services are to made accessible. This draft defines some simple 53 "service entities" and "atomic services" in terms of which we can 54 specify those services. After defining these architectural elements, we 55 verify that they are sufficient to define the example services that have 56 been agreed upon as test cases within the PINT working group. The set of 57 PSTN services that can be obtained from this architecture is what we 58 call "the PINT Services." Finally, we state some security requirements 59 for these new services. 61 Internet Engineering Task Force (PINT WG) Scott Petrack 62 draft-ietf-pint-basics-00.txt petrack@vocaltec.com 64 Because the PINT working group is attended by members of non- 65 intersecting language groups, it is important to define two key terms 66 used within this draft: 68 PSTN - "Public Switched Telephone Network." The term "PSTN" is used in 69 this document interchangeably with "GSTN" (general switched telephone 70 network) or "SCN" (switched circuit network). It refers to any switched 71 voice and/or voice-band data Telephone Network of any type anywhere in 72 the world. Thus it includes the ISDN and the GSM network, the various 73 private PBX networks in existence, etc. (As such, it means something 74 different from probably any other document which uses the term. PSTN is 75 absolutely the wrong term, but unfortunately it appears the name of the 76 working group. GINT, SINT, or TINT apparently didn't cut it). 78 Internet - The term as used here refers to any collection of IP 79 networks, including but not limited to the full Internet. It is useful 80 to make explicit that the discussion here applies equally well to 81 private intranet access to PINT services. The distinctions between 82 "internet," "Internet," and "intranet" are very popular among some 83 members of the PINT community, but are quite meaningless for the 84 purposes of this draft. 86 So the term "Internet" on the one hand and "PSTN" (or "GSTN") on the 87 other are meant to be basically comparable. The first means here "some 88 kind of IP network" and the second means "some kind of telephone 89 network." 91 2. Background 93 Initial discussions in PINT identified the following rather specific 94 services as requiring access from the Internet: 96 a. "request to call" - a request sent from an Client to a Server, which 97 causes phone A to call phone B. 98 b. "request to fax" - a request sent from a Client to a Server, which 99 causes a fax to be sent to fax machine B. The content of the fax would 100 be identified (possibly included) in the request. 101 c. "voice access to web content" - a request sent from a Client to a 102 Server, which causes a phone call to be made to phone B, and a certain 103 "web content" to be read out to phone B. 104 d. "request to conference call" - a request sent from a Client to a 105 Server, which causes a conference call to be set up and a certain number 106 of phones to ring, to invite the humans to join the conference. 107 e. "request to transfer" - a request sent from a Client to a Server, 108 which causes (at least) one of the phones to be disconnected from the 109 call and (at least) one new phone to be joined to the call. 110 f. "request to add new endpoint" - a request sent from a Client to a 111 Server, which causes a new phone to be added to the call. 113 In each request it should be possible to specify a time for the service 114 to be invoked, and in each request it should be possible to specify a 115 party C to whom a bill can be sent for the service (with some reasonable 116 expectation that payment will result). 118 It should be noted that within the current PINT list, there seems to be 119 universal agreement really only about the first three services listed 120 above (a,b, and c). There does seem to be rough consensus that the 122 Internet Engineering Task Force (PINT WG) Scott Petrack 123 draft-ietf-pint-basics-00.txt petrack@vocaltec.com 125 latter three are within PINT's scope as well, however. The definitions 126 of service elements and architecture outlined in this draft enable all 127 six services listed above. If it is desired to exclude the latter three 128 services, we shall see that this is very easy to do. 130 It should also be noted that although much of the original PINT 131 discussion was framed in terms of Intelligent Networking (IN), there is 132 wide agreement that the above services make sense in almost any GSTN 133 environment, regardless of the availability of IN. 135 The rest of this draft describes a simple set of natural GSTN service 136 elements that can be used to build the six services above, and which can 137 be invoked via a request from an IP client to an IP host. 139 3. Service Entities for PINT Services 141 There are five basic building blocks, which we call "service entities," 142 from which PINT services can be built: Terminals, Calls, PINT clients, 143 PINT Servers, and Billable Parties. They are defined as follows: 145 3.1 Terminals 146 A Terminal is a GSTN terminal, such as phone, a fax machine, a 147 voicemail machine, etc. Terminals have identifiers, which may be (but 148 are not limited to) E.164 numbers. These identifiers may be globally 149 unique, or only unique within some well defined context. A Terminal is 150 in principle callable and can in principal make calls. 152 3.2 Calls 153 A Call is a collection of GSTN resources (they can be internal to 154 the GSTN and/or within Terminals). A simple point-to-point Call might 155 consist of some resources within two Terminals and within the switches 156 in between them. Calls have identifiers. For the moment the form of 157 these identifiers is left unspecified, although it is required that it 158 can be done in some globally consistent way. 160 3.3 PINT Clients and Servers 161 A PINT Client sends a service request to a PINT Server and 162 receives a service reply from the PINT Server. 164 3.4 Billable Party 165 A Billable Party has an identifier and can accept or reject a Bill 166 for a particular PINT service. The Bill is sent by a PINT Server to one 167 or more Billable Party(ies). It is not yet decided if the the billing 168 protocol is within the scope of PINT. But it is within the scope of PINT 169 that a service request can contain a request that a Bill with some 170 specified content can be sent to a specified Billable Party, and also 171 that the service reply can contain secure notification of the acceptance 172 or rejection of the bill. 174 4. Atomic Services and Compound Services 176 The service entities together act to provide PINT services. A PINT 177 service is the result of a service request from a PINT client to a PINT 178 Server. The service requests can be for a single atomic service, or for 179 a combination of atomic services, called a compound service. The atomic 180 service requests are one of the following: 182 Internet Engineering Task Force (PINT WG) Scott Petrack 183 draft-ietf-pint-basics-00.txt petrack@vocaltec.com 185 4.4.1 Create a Call 186 The Client requests the Server to create a Call. 187 4.4.2 Destroy a Call 188 The Client requests the Server to tear down a Call. 189 4.4.3 Connect a Terminal to a Call 190 The Client requests the Server to connect a specified Terminal to 191 a specified Call. 192 4.4.4 Disconnect a Terminal to a Call 193 The Client requests the Server to disconnect a specified Terminal 194 from a specified Call. 195 4.4.5 Play some file data to a connected Terminal 196 The Client requests the Server to play some file data of a given 197 "type" into a Terminal that is connected to a particular Call. The file 198 data might be included in the service request, or it might be merely 199 identified (to be retrieved via some other means). Examples of types of 200 file data might be type "fax" or type "text". Of course the precise 201 meaning of "play" depends on the particular type of file data. 202 4.4.6 Check Status of a Request, Call, or Terminal 203 The Client requests the Server to return information about the 204 status of a particular Request, Call, or Terminal. The Check Status 205 requests may ask for an immediate reply, or for the reply to be delayed 206 until the relevant Request or Call is completed or an error occurs. 207 4.4.7 Send a Bill 208 The Client requests the Server to send a bill to a Billable Party 209 for one of the atomic or compound services. 211 Each service request may be for service at a specified later time. In 212 every case the request must contain the information about where to send 213 the reply, whether or not the request is to be executed immediately or 214 in the future. 216 A compound service is built up by combining atomic services. There are 217 three possibilities with respect to the time relations of the atomic 218 services within the compound service: it may be that the atomic services 219 are specified to run serially (so that one must complete before the next 220 can begin), or it may be that only the start of each atomic service is 221 specified to run serially (so that one must begin before the next can 222 begin), or there may be no time relationship at all between the atomic 223 services. 225 Sending a Bill is one of the atomic services. This is how a PINT client 226 asks the PINT Server to send a bill to a particular Billable Party. This 227 may be the only service requested (in which case the request is one 228 purely to send a bill to someone), or it may be one of several atomic 229 services requested in the query (for example in a request to perform 230 some service and send a bill for the service performed to a Billable 231 Party). It is perfectly reasonable to send several requests for atomic 232 billing services within a single service request. 234 5. Realisation of the Example Services of Section 2 236 It is not hard to define the particular example services of section 2 as 237 compound services. For example, the point-to-point "request to call" 238 service is simply a request to the PINT Server to create a Call, connect 239 Terminals A and B to the Call, and send a bill to Billable Party C. But 240 even in this simple case there is a point which requires comment: 242 Internet Engineering Task Force (PINT WG) Scott Petrack 243 draft-ietf-pint-basics-00.txt petrack@vocaltec.com 245 The original example service definition of section 2 had "phone A call 246 phone B." The service that we define in the previous paragraph is 247 symmetric between phone A and phone B - these two Terminals are 248 "connected to a Call." It is not clear who is calling whom. Of course, 249 the service required can be made more precise by specifying that the 250 compound service is built up from the atomic elements by executing them 251 serially: first the Call is created, then phone A is connected, then 252 phone B is connected, then a bill is sent. (Perhaps various audio prompt 253 file data are played into phones A and/or B at the appropriate times). 255 During some previous PINT discussions, a distinction was drawn between 256 "third party service control" and "sending an invitation to a proxy 257 server acting on behalf of a Terminal." The architecture presented here 258 is really an example of "third party service control" - the PINT Server 259 is connecting the two Terminals A and B, rather than a request being 260 sent to a proxy server for Terminal A to call Terminal B. It seems that 261 in order to include all the example scenarios in a single framework, it 262 is more natural to think in terms of third party service control. In 263 practise, the difference is more pedantic than really important. 265 Realising the other examples of section 2 as compound services is 266 equally straightforward. 268 6. Security Considerations and Requirements 270 There are two or more different IP hosts involved in each invocation of 271 a PINT request: a PINT client, a PINT Server, and zero or more Billable 272 Parties. It is required that each of these hosts can authenticate itself 273 to another, independently of the others. It is required that each 274 message exchange can be private and/or non-repudiatable. The process by 275 which two entities exchange keys or secrets in order to ensure 276 authentication, privacy, and non-repudiation, are beyond the scope of 277 the PINT service architecture or protocols. 279 7. Acknowledgements 281 The author would like to acknowledge input from the PINT mailing list as 282 a major source of ideas which appear in this draft. The archive of the 283 PINT mailing list can be found at the following URL: http://www.bell- 284 labs.com/mailing-lists/pint/. In particular, postings of Claudio 285 Catania, Igor Faynberg, Dave Oran, Lawrence Conroy, Wilhelm Wimmreuter 286 particularly informed parts of the discussion. 288 Internet Engineering Task Force PINT WG 289 INTERNET-DRAFT Scott Petrack 290 draft-ietf-pint-basics-00.txt VocalTec Communications Ltd. 291 21st Nov 1997 petrack@vocaltec.com 292 Expires: 21st May 1997