Subject: [Enum] New draft-brandner-enumservice-vovi-01.txt

From: "Rudolf Brandner" <[email-masked]>
Date: Tue, 18 Mar 2003 04:14:13 +0100

Hi all,

considering the discussion on the ENUM mailing list I would like to give you a heads up on a new draft-brandner-enumservice-vovi-01.txt we submitted. Due to the black out time, it will not be published after this IETF.

I have attached the text with change bars on the left hand side for your convenience.

We removed the 'voice:sip' and 'video:sip' registration (which is indicated by a change bar following appr. 20 '-' signs indicating where the removal took place). Other changed paragraphs are marked with change bars.

We believe that the text is now not contentious any more.

I am sorry for the late notice, but we really want to proceed with those registrations.

Many thanks,
Rudi

______________________________________________________________________________
Keine Zeit fur Firlefanz?  Blitz-SMS von WEB.DE FreeMail! Die SMS, die
direkt auf's Display kommt! http://freemail.web.de/features/?mc=021166

ENUM Working Group                                          R. Brandner
Internet Draft                                                  Siemens
                                                              L. Conroy
                                                                Siemens
                                                             R. Stastny
                                                                  OeFEG
Expires: September 2003                                      March 2003

            Registration for enumservices voice and video
              <draft-brandner-enumservice-vovi-01.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC2026 [1].

   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups.  Note that 
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six 
   months and may be updated, replaced, or obsoleted by other documents 
   at any time. It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html.

Abstract

   This document registers a group of 'enumservices' [2] to be used to 
   indicate that the associated resources are capable of interactive 
   media stream exchange.

   Specifically, the "enumservices" registered with this document are 
|  'voice' and 'video' using the URI schemes 'h323:' and 'tel:'

Table of Contents

   TBD

1.  Introduction

   ENUM (E.164 Number Mapping, RFC2916bis [2]) is a system that 
   transforms E.164 numbers [3] into domain names and then uses DNS 
   (Domain Name Service, RFC1034 [4]) services like delegation through 
   NS records and NAPTR records to look up what services are available 
   for a specific domain name.

   This document registers 'enumservices' according to the guidelines 
   given in RFC2916bis to be used for provisioning in the services 
   field of a NAPTR[6] resource record to indicate what class of 
   functionality a given end point offers. The registration is defined 
   within the DDDS (Dynamic Delegation Discovery System 
   [5][6][7][8][9]) hierarchy, for use with the "E2U" DDDS Application 
   defined in RFC2916bis

   The following 'enumservices' are registered with this document: 
   'voice' and 'video'. These share a common feature in that they each 
   indicate that the functionality of the given end points and the 
   associated resources are capable of exchanging interactive media 
   streams.

   According to RFC2619bis, the 'enumservice' registered must be able 
   to function as a selection mechanism when choosing one NAPTR 
   resource record from another. That means that the registration MUST 
   specify what is expected when using that very NAPTR record, and the 
   URI scheme which is the outcome of the use of it.

   Therefore an 'enumservice' acts as a hint, indicating the kind of 
   service with which the URI constructed using the regexp field is 
   associated. There can be more than one 'enumservice' included within 
   a single NAPTR; this indicates that there is more than one service 
   that can be achieved using the associated URI scheme.

   The common thread with this set of definitions is that they reflect 
   the kind of service that the end user will hope to achieve with the 
   communication using the associated URI. 

   The services specified here are intended NOT to specify the protocol 
   or even method of connection that MUST be used to achieve each 
   service. Instead they define the kind of interactive behavior that 
   an end user will expect, leaving the end system to decide (based on 
   policies outside the remit of this specification) how to execute the 
   service.

   Since the same URI scheme may be used for different services (e.g. 
   'tel:'), and the same kind of service may use different URI schemes 
   (e.g. for VoIP 'h323:' and 'tel:' may be used), it is necessary in 
   some cases to specify the service and the URI scheme used.

   The service parameters defined in RFC2916bis allow therefore a 
   'type' and a 'subtype' to be specified. Within this set of 
   specifications the convention is assumed that the 'type' (being the 
   more generic term) is defining the service and the 'subtype' is 
   defining the URI scheme.

2.  Abbreviations

   TBD

3.  Voice Service

3.1  Introduction

   The enumservices registered in this section indicate that the 
   resource identified by the associated URI is capable of being 
   contacted to provide a communication session during which 
   interactive media streams carrying voice data can be exchanged.

3.2  Voice Service Registration with 'tel:'

   Enumservice Name: "voice"

   Type: "voice"

   Subtype: "tel"

   URI Scheme: 'tel:'

   Functional Specification: 

   This enumservice indicates that the resource identified by the 
   associated URI scheme is capable of being called using a PSTN by 
   dialing the number of the URI in order to set up the voice 
   communication.

|  If a dialing device is not present, a SIP [12] or H.323 [14] Client, 
|  if available, can be invoked and, by using the tel: URI, set up a 
|  session for voice communication. The querying user is expecting a 
|  voice communication.

   Security Considerations: 

   There are no specific security issues with this 'enumservice'. 
   However, the general considerations of section 6 apply.

   Intended Usage: COMMON

   Author: Rudolf Brandner, Lawrence Conroy, Richard Stastny
           (for author contact detail see section 8)

   Any other information the author deems interesting:

   None

|--------------------
3.3  Voice Service Registration with 'h323:'

   Enumservice Name: "voice"

   Type: "voice"

   Subtype: "h323"

   URI Scheme: 'h323:'

   Functional Specification: 

   This enumservice indicates that the resource identified by the 
   associated URI scheme is capable of engaging in a voice 
   communication using H.323 [14]. Note that H.323 has its own 
   negotiation method within the protocol set, so that the client MAY 
   be offered another kind of communication session after negotiation.

   However, this combination gives more information to the querying 
   user than would be the case for the "h323" enumservice [15]. The 
   implication of this combination is that, if selected, the querying 
   user can engage in an interactive voice communication; thus the 
   registrant SHOULD include such an entry only for those cases where 
   this is possible.

   Security Considerations:

   There are no specific security issues with this 'enumservice'. 
   However, the general considerations of section 6 apply.

   Intended Usage: COMMON

   Author: Rudolf Brandner, Lawrence Conroy, Richard Stastny
           (for author contact detail see section 8)

   Any other information the author deems interesting:

   None

4.  Video Service

4.1  Introduction

   The enumservices registered in this section indicate that the 
   resource identified by the associated URI is capable of being 
   contacted to provide a communication session during which 
   interactive media streams carrying audio and video data can be 
   exchanged.

4.2  Video Service Registration with 'tel:'

   Enumservice Name: "video"

   Type: "video"

   Subtype: "tel"

   URI Scheme: 'tel:'

   Functional Specification: 

   This enumservice indicates that the resource identified by the 
   associated URI scheme is capable of being called using the PSTN by 
   dialing the number of the URI in order to set up a audio/video 
   communication.

|  If a dialing device is not present, a SIP [12] or H.323 [14] Client, 
|  if available, can be invoked and, by using the tel: URI, set up a 
|  session for voice communication. The querying user is expecting a 
|  voice communication.

   Security Considerations: 

   There are no specific security issues with this 'enumservice'. 
   However, the general considerations of section 6 apply.

   Intended Usage: COMMON

   Author: Rudolf Brandner, Lawrence Conroy, Richard Stastny
           (for author contact detail see section 8)

   Any other information the author deems interesting:

   None

|--------------------
4.3  Video Service Registration with 'h323:'

   Enumservice Name: "video"

   Type: "video"

   Subtype: "h323"

   URI Scheme: 'h323:'

   Functional Specification: 

   This enumservice indicates that the resource identified by the 
   associated URI scheme is capable of engaging in an audio/video 
   communication using H.323 [14]. Note that H.323 has its own 
   negotiation method within the protocol set, so that the client MAY 
   be offered another kind of communication session after negotiation.

   However, this combination gives more information to the querying 
   user than would be the case for the "h323" enumservice [15]. The 
   implication of this combination is that, if selected, the querying 
   user can engage in an interactive call that can include video 
   communication; thus the registrant SHOULD include such an entry only 
   for those cases where this is possible.

   Security Considerations:

   There are no specific security issues with this 'enumservice'. 
   However, the general considerations of section 6 apply.

   Intended Usage: COMMON

   Author: Rudolf Brandner, Lawrence Conroy, Richard Stastny
           (for author contact detail see section 8)

   Any other information the author deems interesting:

   None

5.  Additional Information

   Editor note: Is there any necessary additional information? TBD

6.  Security Considerations 

   DNS, as used by ENUM, is a global, distributed database. Thus any 
   information stored there is visible to anyone anonymously. Whilst 
   this is not qualitatively different from publication in a Telephone 
   Directory, it does open the data subject to having "their" 
   information collected automatically without any indication that this 
   has been done or by whom.

   Such data harvesting by third parties is often used to generate 
   lists of targets for unrequested information; in short, they are 
   used to address "spam". Anyone who uses a Web-archived mailing list 
   is aware that the volume of "spam" email they are sent increases 
   when they post to the mailing list; publication of a telephone 
   number in ENUM is no different, and may be used to send "junk faxes" 
   or "junk SMS" for example.

   Many mailing list users have more than one email address and use 
   "sacrificial" email accounts when posting to such lists to help 
   filter out unrequested emails sent to them. This is not so easy with 
   published telephone numbers; the PSTN E.164 number assignment 
   process is much more involved and usually a single E.164 number (or 
   a fixed range of numbers) is associated with each PSTN access. Thus 
   providing a "sacrificial" phone number in any publication is not 
   possible.

   Due to the implications of publishing data on a globally accessible 
   database, as a principle the data subject MUST give their explicit 
   informed consent to data being published in ENUM.

   In addition, they should be made aware that, due to storage of such 
   data during harvesting by third parties, removal of the data from 
   publication will not remove any copies that have been taken; in 
   effect, any publication may be permanent.

   However, regulations in many regions will require that the data 
   subject can at any time request that the data is removed from 
   publication, and that their consent for its publication is 
   explicitly confirmed at regular intervals.

   When placing a voice or video call via the PSTN or sending a message 
   via the Public Land Mobile Network, the sender may be charged for 
   this action. In both kinds of network, calling or messaging to some 
   numbers is more expensive than sending to others; both networks have 
   "premium rate" services that can charge considerably more than a 
   "normal" call or message destination. As such, it is important that 
   the end user be asked to confirm sending the message, and that the 
   destination number be presented to them. It is the originating 
   user's choice on whether or not to place a call to this destination 
   number, but they SHOULD be shown the destination number so that they 
   can make this decision

   Where voice or video terminals are configured to accept incoming 
   calls, there SHOULD be an indication presented to the user that an 
   incoming call is being offered. Particularly with some video 
   systems, the terminal may be configured to "auto-accept" the call. 
   In this case there MUST be an obvious indication presented to the 
   calling user that this has been done.

   Systems configured to auto-accept audio/video calls that are sent to 
   a number published in a global public directory may be used by 
   unexpected individuals to check for the presence or otherwise of 
|  people with a view to stealing property or other unwelcome acts. 
   Whilst "security through obscurity" may have seemed acceptable when 
   the access address was known to only a few, publication within ENUM 
   removes the obscurity, so leaving (for example) a "WebCam" switched 
   on after such publication is even less wise than in other 
   situations.

   In addition to the specific security considerations given above, all 
   security considerations given in RFC2916bis apply.

7.  References

1  Scott Bradner, RFC2026,
      "The Internet Standards Process - Revision 3",
      October 1996.

2  P. Faltstrom, M. Mealling,
      "The E.164 to URI DDDS Application (ENUM)",
      draft-ietf-enum-rfc2916bis-03.txt,
      Work in progress, January 2003

3  ITU-T,
      "The International Public Telecommunication Number Plan",
      Recommendation E.164,
      May 1997

4  P. Mockapetris, RFC1034,
      "DOMAIN NAMES - CONCEPTS AND FACILITIES",
      November 1987

5  M. Mealling, RFC 3401,
      "Dynamic Delegation Discovery System (DDDS) Part One:
      The Comprehensive DDDS",
      October 2002

6  M. Mealling, RFC 3402,
      "Dynamic Delegation Discovery System (DDDS) Part Two:
      The Algorithm",
      October 2002

7  M. Mealling, RFC 3403,
      "Dynamic Delegation Discovery System (DDDS) Part Three:
      The Domain Name System (DNS) Database",
      October 2002

8  M. Mealling, RFC 3404,
      "Dynamic Delegation Discovery System (DDDS) Part Four:
      The Uniform Resource Identifiers (URI)",
      October 2002

9  M. Mealling, RFC 3405,
      "Dynamic Delegation Discovery System (DDDS) Part Five:
      URI.ARPA Assignment Procedures",
      October 2002

10  H. Schulzrinne, A. Vaha-Sipila, 
      "URIs for Telephone Calls",
      draft-antti-RFC2806bis-08.txt,
      Work in progress, February 2003

11  ETSI TS 102 172,
      "Minimum Requirements for Interoperability of 
      European ENUM Trials",
      February 2003

12  J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston,
      J. Peterson, R. Sparks, M. Handley, E. Schooler,
      RFC 3261,
      "SIP: Session Initiation Protocol",
      June 2002

13  J. Peterson,
      "enumservice registration for SIP Addresses-of-Record",
      draft-peterson-enum-sip-00.txt,
      Work in progress, September 2002

14  ITU-T Recommendation H.323,
      "Packet-based multimedia communications systems",
      Nov 2000

15  O. Levin,
      "ENUM Service Registration for H.323 URL",
      draft-ietf-enum-h323-00.txt,
      Work in progress, February 2003

8.  Author's Addresses

   Rudolf Brandner
      Siemens ICN
      Hofmannstrasse 51
      Munich
      Germany
      email: <mailto:[email-masked]>
      voice: <tel:+49-89-72251003>
      web:   <http://www.siemens.com>

   Lawrence Conroy
      Siemens Roke Manor Research
      Roke Manor
      Romsey
      U.K.
      email: <mailto:[email-masked]>
      voice: <tel:+44-1794-833666>

   Richard Stastny
      OeFEG
      Postbox 147
      1103 Vienna
      Austria
      email: <mailto:[email-masked]>
      voice: <tel:+43-664-420-4100>

9.  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to 
   others, and derivative works that comment on or otherwise explain it 
   or assist in its implementation may be prepared, copied, published 
   and distributed, in whole or in part, without restriction of any 
   kind, provided that the above copyright notice and this paragraph 
   are included on all such copies and derivative works.  However, this 
   document itself may not be modified in any way, such as by removing 
   the copyright notice or references to the Internet Society or other 
   Internet organizations, except as needed for the purpose of 
   developing Internet standards in which case the procedures for 
   copyrights defined in the Internet Standards process must be 
   followed, or as required to translate it into languages other than 
   English.

   The limited permissions granted above are perpetual and will not be 
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an 
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.