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

Hi Folks,
  I'm sending this for Rudi Brandner, who has mail problems
sending to the list. Enjoy
-----------------------------------------------------------------------
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

________________________________________________________________________

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:rudolf.brandner@siemens.com>
       voice: <tel:+49-89-72251003>
       web:   <http://www.siemens.com>

    Lawrence Conroy
       Siemens Roke Manor Research
       Roke Manor
       Romsey
       U.K.
       email: <mailto:lwc@roke.co.uk>
       voice: <tel:+44-1794-833666>

    Richard Stastny
       OeFEG
       Postbox 147
       1103 Vienna
       Austria
       email: <mailto:richard.stastny@oefeg.at>
       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.
_______________________________________________
enum mailing list
enum@ietf.org
https://www1.ietf.org/mailman/listinfo/enum