Subject: [Enum] draft-ietf-enum-uri-00.txt

From: Patrik Fältström <[email-masked]>
Date: Thu, 28 Sep 2006 11:43:02 +0200

This document was requested to be published the other day, but  
publication seems to take some time.

This is the first document of two that together create RFC 3761bis.

     Patrik

ENUM                                                        P. Faltstrom
Internet-Draft                                                     Cisco
Intended status: Standards Track                              O. Kolkman
Expires: March 31, 2007                                            NLNet
                                                       September 27,  
2006

        The Uniform Resource Identifier (URI) DNS Resource Record
                        draft-ietf-enum-uri-00.txt

Status of this Memo

    By submitting this Internet-Draft, each author represents that any
    applicable patent or other IPR claims of which he or she is aware
    have been or will be disclosed, and any of which he or she becomes
    aware will be disclosed, in accordance with Section 6 of BCP 79.

    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.

    This Internet-Draft will expire on March 31, 2007.

Copyright Notice

    Copyright (C) The Internet Society (2006).

Abstract

    This document defines a new DNS resource record, called the Uniform
    Resource Identifier (URI) RR, for publishing mappings from hostnames
    to URIs.

Faltstrom & Kolkman      Expires March 31, 2007                 [Page 1]
Internet-Draft             URI Resource Record            September 2006

Table of Contents

    1.   
Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
    2.  Applicability  
Statement  . . . . . . . . . . . . . . . . . . .  3
    3.  DNS  
considerations . . . . . . . . . . . . . . . . . . . . . .  4
    4.  The format of the URI  
RR . . . . . . . . . . . . . . . . . . .  4
      4.1.  Ownername, class and  
type  . . . . . . . . . . . . . . . .  4
      4.2.   
Priority . . . . . . . . . . . . . . . . . . . . . . . . .  5
      4.3.   
Weight . . . . . . . . . . . . . . . . . . . . . . . . . .  5
      4.4.   
Target . . . . . . . . . . . . . . . . . . . . . . . . . .  5
      4.5.  URI RDATA Wire  
Format  . . . . . . . . . . . . . . . . . .  5
      4.6.  The URI RR Presentation  
Format . . . . . . . . . . . . . .  6
    5.  Definition of the flag 'D' for NAPTR  
records . . . . . . . . .  6
    6.   
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
      6.1.  Homepage at one domain, but two domains in  
use . . . . . .  6
      6.2.  Different providers for services for the same E. 
164  . . .  7
    7.  IANA  
Considerations  . . . . . . . . . . . . . . . . . . . . .  8
    8.  Security  
Considerations  . . . . . . . . . . . . . . . . . . .  9
    9.   
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
    10.  
References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
      10.1. Normative  
References . . . . . . . . . . . . . . . . . . .  9
      10.2. Non-normative  
references . . . . . . . . . . . . . . . . .  9
    Authors'  
Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9
    Intellectual Property and Copyright  
Statements . . . . . . . . . . 11

Faltstrom & Kolkman      Expires March 31, 2007                 [Page 2]
Internet-Draft             URI Resource Record            September 2006

1.  Introduction

    This document explains the use of the Domain Name System (DNS) for
    storage of URIs, and how to resolve hostnames to such URIs that can
    be used by various applications.  For resolution the application  
need
    to know both the hostname and the protocol that the URI is to be  
used
    for.  The protocol is registered by IANA.

    Currently, looking up URIs given a hostname uses the DDDS [RFC3401]
    application framework with the DNS as a database as specified in RFC
    3404 [RFC3404].  This have a number of implications as described in
    draft-iab-dns-choices [I-D.iab-dns-choices] such as the inability to
    select what NAPTR records that match the query is interesting.  The
    RRSet returned will always consist of all URIs "connected" with the
    domain in question.

    The URI resource record specified in this document create an ability
    for the querying party to select which ones of the NAPTR records one
    is interested in.  This because data in the service field of the
    NAPTR record is included in the owner part of the URI resource  
record
    type.

    Querying for the URI resource record type is not replacing querying
    for the NAPTR (or S-NAPTR [RFC3958]) resource record type.  Instead
    it is a complementary mechanism to use when one know already what
    service field is interesting.  One can with the URI resource record
    type directly query for the specific subset of the otherwise  
possibly
    large RRSet given back when querying for NAPTR resource records.

    This document updates RFC 3958 and RFC 3404 by adding the flag  
"D" to
    the list of defined terminal flags in section 2.2.3 of RFC 3958 and
    4.3 of RFC 3404.

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    document are to be interpreted as described in BCP 14, RFC 2119
    [RFC2119].

2.  Applicability Statement

    In general, it is expected that URI records will be used by clients
    for applications where the relevant protocol to be used is known,  
but
    for example extra abstraction given by separating a hostname from a
    point of service (as address by the URI) is needed.  Examples of  
such
    are many scenarios where telephony routing with the help of E.164
    [E164] numbers according to ENUM [RFC3761], or when an organisation
    have many domain names, but only one official web page.

Faltstrom & Kolkman      Expires March 31, 2007                 [Page 3]
Internet-Draft             URI Resource Record            September 2006

    Applications MUST know the specific service fields to prepend the
    hostname with.  Using repetitive queries for URI records MUST NOT be
    a replacement for querying for NAPTR or S-NAPTR records.  NAPTR and
    S-NAPTR records are for discovery of the various services and URI  
for
    looking up access point for a given service.  Those are two very
    different kinds of needs.

3.  DNS considerations

    Prefixing names with the underscored service tags prevents wildcard
    based matching [I-D.iab-dns-choices].  Besides, underscored service
    tags used for the URI RR (based on the NAPTR service descriptions)
    may have slightly different semantics than service tags used for
    underscored prefix labels that are used in combination with other
    (yet unspecified) RR types.  This may cause subtle management
    problems when delegation structure that has developed within the
    context of URI RRs is also to be used for other RR types.  Since the
    service labels might be overloaded applications should carefully
    check that the application level protocol is indeed the protocol  
they
    expect.

    Subtle management issues may also arise when the delegations from
    service to sub service label involves several parties and different
    stake holders.

4.  The format of the URI RR

    This is the format of the URI RR, whose DNS type code is NNNN (to be
    assigned by IANA).

    Ownername TTL Class URI Priority Weight Target

4.1.  Ownername, class and type

    The URI ownername is subject to special conventions.

    Just like the SRV RR [ref] the URI RR has service information  
encoded
    in its ownername.  In order to encode the service for a specific
    owner name one uses service parameters.  Valid service parameters
    used are those as registered by IANA for NAPTR Records of any kind
    [ref to IANA registry name].  The service parameters are reversed,
    prepended with an underscore (_) and prepended to the owner name in
    separate labels.  The underscore is prepended to the service
    parameters to avoid collisions with DNS labels that occur in nature,

Faltstrom & Kolkman      Expires March 31, 2007                 [Page 4]
Internet-Draft             URI Resource Record            September 2006

    and the order is reversed to make it possible to do delegations, if
    needed, to different zones (and therefore providers of DNS).

    For example, suppose we are looking for the URI for a service with
    Service Parameter "A:B:C" for host example.com..  Then we would  
query
    for (QNAME,QTYPE)=("_C._B._A.example.com","URI")

    The type number for the URI record is NNNN (to be assigned by IANA).

    The URI resource record is class independent.

    The URI RR has no special TTL requirements.

4.2.  Priority

    The priority of this target URI.  A client MUST attempt to contact
    the URI with the lowest-numbered priority it can reach; URIs with  
the
    same priority SHOULD be tried in an order defined by the weight
    field.  The range is 0-65535.  This is a 16 bit unsigned integer in
    network byte order.

4.3.  Weight

    A server selection mechanism.  The weight field specifies a relative
    weight for entries with the same priority.  Larger weights SHOULD be
    given a proportionately higher probability of being selected.  The
    range of this number is 0-65535.  This is a 16 bit unsigned integer
    in network byte order.

4.4.  Target

    The URI of the target.  Resolution of the URI is according to the
    definitions for the URI Scheme the URI consists of.

    The URI is encoded as one or more <character-string> RFC1035 section
    3.3 [RFC1035].

4.5.  URI RDATA Wire Format

    The RDATA for a URI RR consists of a 2 octet Priority field, a two
    octet Weight field, and a variable length target field.

Faltstrom & Kolkman      Expires March 31, 2007                 [Page 5]
Internet-Draft             URI Resource Record            September 2006

                         1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Priority             |          Weight               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /                                                               /
    /                             Target                            /
    /                                                               /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.6.  The URI RR Presentation Format

    The presentation format of the RDATA portion is as follows:

    Priority field MUST be represented as an unsigned decimal integer.

    The Weight Type field MUST be represented as an unsigned decimal
    integer.

    The target URI is enclosed in double-quotes (").  If the total  
length
    of the URI exceeds 255 characters the URI will be encoded in  
multiple
    <character-strings>.

5.  Definition of the flag 'D' for NAPTR records

    This document specifies the flag "D" for use as a flag in NAPTR
    records.  The flag indicate a terminal NAPTR record because it
    denotes the end of the DDDS/NAPTR processing rules.  In the case  
of a
    "D" flag, the Replacement field in the NAPTR record is used as the
    Owner of a DNS query for URI records, and normal URI processing as
    defined in this document is applied.

    The Regexp field in the NAPTR record MUST be empty when the 'D' flag
    is in use.

6.  Examples

6.1.  Homepage at one domain, but two domains in use

    An organisation have the domain names example.com and example.net,
    but the official URI http://www.example.com/.  Given the Service Tag
    "web" for the imagined "homepage" application service, the following
    URI Resource Records could be made available in the respective  
zones:

Faltstrom & Kolkman      Expires March 31, 2007                 [Page 6]
Internet-Draft             URI Resource Record            September 2006

    _web.example.com. IN URI 10 1 "http://www.example.com/"

    _web.example.net. IN URI 10 1 "http://www.example.com/"

6.2.  Different providers for services for the same E.164

    An organisation have the E.164 +442079460148, but different
    organisations handle routing of calls for the number on the Internet
    (with the help of SIP) and traditional PSTN.  More specifically, the
    two providers want to run DNS for the record(s) that refer to the
    services they provide.

    The ENUM provider for the +44 country code in this case not only do
    delegations on the full E.164 number, but delegations on the service
    parameter values, as can be seen below:

    In this example we also include the NAPTR records that with the help
    of the 'D' flag refer to the URI records.  We also include NAPTR
    records according to RFC 3761 [RFC3761] that give backward
    compatibility.

    In zone 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa.:

Faltstrom & Kolkman      Expires March 31, 2007                 [Page 7]
Internet-Draft             URI Resource Record            September 2006

    $ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa.

    ;; NAPTR records that refer to URI records
      IN NAPTR 1 1 "D" "E2U:sip"               ( ; service
                       ""                        ; regexp
                       _sip._e2u                 ; replacement
                                               )

      IN NAPTR 1 1 "D" "E2U:tel"               ( ;service
                       ""                        ;regexp
                       _tel._e2u                 ;replacement
                                               )

    ;; NAPTR records for RFC 3761 compatibility
      IN NAPTR 1 1 "U" "E2U:sip"               ( ;service
      "!.*!sip:[email-masked]!"   ; regexp
      .                                          ; replacement
                                               )

      IN NAPTR 1 1 "U" "E2U:tel"               ( ;service
      "!.*!sip:[email-masked]!"   ; regexp
      .                                          ; replacement
                                               )

    ;; Delegations to child zones
    _sip._e2u IN NS    ns1.example.net.
    _tel._e2u IN NS    ns1.example.com.

    In zone _sip._e2u.8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa:

    $ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa.
    _sip._e2u IN URI "sip:[email-masked]"

    In zone 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa:

    $ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa.
    _tel._e2u IN URI "tel:+442079460148"

7.  IANA Considerations

8.  Security Considerations

Faltstrom & Kolkman      Expires March 31, 2007                 [Page 8]
Internet-Draft             URI Resource Record            September 2006

9.  Acknowledgements

    Ideas on how to split the two different kind of queries "What
    services exists for this domain name" and "What is the URI for this
    service" came from Scott Bradner and Lawrence Conroy.  Other people
    that have contributed to this document include Olafur Gudmundsson,
    Maria Hall, Peter Koch and Penn Pfautz.

10.  References

10.1.  Normative References

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

    [RFC1035]  Mockapetris, P., "Domain names - implementation and
               specification", STD 13, RFC 1035, November 1987.

    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

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

    [RFC3958]  Daigle, L. and A. Newton, "Domain-Based Application
               Service Location Using SRV RRs and the Dynamic Delegation
               Discovery Service (DDDS)", RFC 3958, January 2005.

10.2.  Non-normative references

    [I-D.iab-dns-choices]
               Faltstrom, P., "Design Choices When Expanding DNS",
               draft-iab-dns-choices-03 (work in progress), April 2006.

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

    [RFC3761]  Faltstrom, P. and M. Mealling, "The E.164 to Uniform
               Resource Identifiers (URI) Dynamic Delegation Discovery
               System (DDDS) Application (ENUM)", RFC 3761, April 2004.

Faltstrom & Kolkman      Expires March 31, 2007                 [Page 9]
Internet-Draft             URI Resource Record            September 2006

Authors' Addresses

    Patrik Faltstrom
    Cisco Systems

    Email: [email-masked]

    Olaf Kolkman
    NLnet Labs

    Email: [email-masked]

Faltstrom & Kolkman      Expires March 31, 2007                [Page 10]
Internet-Draft             URI Resource Record            September 2006

Full Copyright Statement

    Copyright (C) The Internet Society (2006).

    This document is subject to the rights, licenses and restrictions
    contained in BCP 78, and except as set forth therein, the authors
    retain all their rights.

    This document and the information contained herein are provided  
on an
    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE  
REPRESENTS
    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
    ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

    The IETF takes no position regarding the validity or scope of any
    Intellectual Property Rights or other rights that might be  
claimed to
    pertain to the implementation or use of the technology described in
    this document or the extent to which any license under such rights
    might or might not be available; nor does it represent that it has
    made any independent effort to identify any such rights.   
Information
    on the procedures with respect to rights in RFC documents can be
    found in BCP 78 and BCP 79.

    Copies of IPR disclosures made to the IETF Secretariat and any
    assurances of licenses to be made available, or the result of an
    attempt made to obtain a general license or permission for the  
use of
    such proprietary rights by implementers or users of this
    specification can be obtained from the IETF on-line IPR  
repository at
    http://www.ietf.org/ipr.

    The IETF invites any interested party to bring to its attention any
    copyrights, patents or patent applications, or other proprietary
    rights that may cover technology that may be required to implement
    this standard.  Please address the information to the IETF at
    [email-masked].

Acknowledgment

    Funding for the RFC Editor function is provided by the IETF
    Administrative Support Activity (IASA).

Faltstrom & Kolkman      Expires March 31, 2007                [Page 11]

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum