Unused - dead cat bounce

From: "Peterson, Jon" <[email protected]>
Date: 7 January 2008 23:27:07 GMT
To: <[email protected]>
Cc: <[email protected]>, <[email protected]>
Subject: AD review of draft-ietf-enum-unused


Before I paste in my review here, just for the sake of Richard and Jim, Lawrence and I discussed this at some length in Vancouver. As I said then, I would really prefer that enum-unused not make use of the "data" URL scheme. Lawrence suggested that it might be possible to return to an HTTP URL instead. I also repeatedly entreated Lawrence to consider trying to flip this problem around (as the last sentence of my review below suggests) or otherwise try to turn this from a problem the DNS does not know how to solve into one that the DNS can solve easily. Ultimately, that may not be possible. Lawrence did ask to see my detailed review notes before further considering this, so, here they are.



I understand that a lot of work has gone into this proposal over the years, but I remain skeptical of the underlying requirements, the general architectural direction, and the specific technical solution.

The requirements text of 3.4 notes, quite rightly, that in cases 1 and 2, if the call is attempted on the PSTN, and error message will occur. It is also true that a resolver cannot distinguish between cases 4 and 5, and thus the application will not be able to tell whether or not attempting the call on the PSTN would succeed. But my question is this: what is the problem, exactly? A call on the PSTN can fail for a number of reasons that have nothing to do with whether or not a number is allocated - do we need to be able to anticipate all of those conditions too, before we place a call? Of course I agree that in an ideal world, terminals would be able to anticipate that a call would fail before it is placed if the condition is predictable. But I'm not sure it is ENUM's responsibility to know
  whether or not a call that is placed outside the Internet will succeed. 

I am also a bit skeptical that the looping behavior described in 3.5 would be instantiated in a reasonable deployment network. Even the most trivial gateways can be provisioned to distinguish number ranges which are considered "local" or "on-net" from those that are reachable through the PSTN. Just because a number cannot be reached over the Internet does not mean that it must be dropped to the PSTN; stipulating that a gateway's routing decision must be based solely on what it learns from ENUM speaks to a gateway implementation problem, not a problem that necessarily needs to be rectified by defining new enumservices.

Architecturally, as was the case with previous incarnations of this proposal, this mechanism seems to introduce a DNS response code in the form of an enumservice. The argument of 3.2 and 3.3 is basically "this is why the current RCODEs are not sufficient." The new response code appears as an enumservice because ENUM is where the perceived need for this RCODE has emerged. The idea that a DNS label is "unused" per cases 1, 2 and 6 in Section 3.1 is something for which no RCODE currently exists, though hypothetically one could imagine an RCODE that serves this purpose rather than an enumservice. I am not sure it is within the scope of the ENUM working group to provide new RCODEs or protocol elements that effectively serve the purpose of RCODEs. Certainly this is not something I would feel com
 fortable doing without substantial review and approval from the DNS community.

Since enumservices need to be associated with a regexp or replacement, the "unused" enumservice nominally contains a replacement to a data URI. I really don't feel that the data URI is an architecturally meaningful "replacement" for a telephone number - there is no sense in which transforming a telephone number into a data URI string identifies a resource. The examples in the draft (which include textual strings for "unassigned" and "unallocated") are unabashedly kludgey, and the syntax of the field is left open ("a national matter"). Suffice it to say that all this suggests to me that you don't really need a NAPTR record. There is no Naming Authority pointing going on in this record, even if the data URI seems to warp NAPTRs to the point where they don't signify anything more specific tha
 n a TXT record.

I feel pretty strongly that populating DNS labels with NAPTR records containing the "unused" service is an undesirable  solution to this problem. I wonder, though, if the problem is cast in a way that makes it prohibitively difficult to  solve. Did you ever consider flipping this around by applying a flag to particular delegations or labels which would  indicate that they are "ENUM-only"?

- J

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc strict="yes" ?>
<?rfc compact="no" ?>
<rfc category="std" docName="&lt;draft-ietf-enum-unused-04.txt&gt;" ipr="full3978">

<front>
<title abbrev="IANA Registration Enumservice UNUSED">IANA Registration for Enumservice UNUSED</title>

<!-- ************** Richard Stastny ***************-->

<author fullname="Richard Stastny" initials="R." surname="Stastny">
  <organization>Oefeg</organization>

  <address>
    <postal>
      <street>Postbox 147</street>
      <city>1103 Vienna</city>
      <country>Austria</country>
    </postal>
    <phone>+43-664-420-4100</phone>
    <email>[email protected]</email>
  </address>
</author>

<!-- ************** Lawrence Conroy ***************-->

<author fullname="Lawrence Conroy" initials="L." surname="Conroy">
  <organization abbrev="RMRL">Siemens Roke Manor Research</organization>
  <address>
    <postal>
      <street>Roke Manor</street>
      <city>Romsey</city>
      <country>United Kingdom</country>
    </postal>
    <phone>+44-1794-833666</phone>
    <email>[email protected]</email>
  </address>
</author>

<!-- ************** Jim Reid ***************-->

<author fullname="Jim Reid" initials="J." surname="Reid">
  <organization abbrev="DNS-MODA">DNS-MODA</organization>
  <address>
    <postal>
      <street>6 Langside Court</street>
      <city>Bothwell</city>
      <region>SCOTLAND</region>
      <country>United Kingdom</country>
    </postal>
    <phone>+44 1698 852881</phone>
    <email>[email protected]</email>
  </address>
</author>

<date month="March" year="2008" />

<area>Applications</area>
<workgroup>ENUM</workgroup>

<keyword>Internet-Draft</keyword>
<keyword>DNS</keyword>
<keyword>NAPTR</keyword>
<keyword>ENUMSERVICE</keyword>
<keyword>UNUSED</keyword>

<keyword>E.164</keyword>

<abstract>
<t>This document registers the Enumservice "unused" using the URI scheme "http:" as per the IANA registration process defined in the ENUM specification, RFC 3761. This Enumservice may be used to indicate that the E.164 number (or E.164 number range) tied to the domain in which the enclosing NAPTR is published is not allocated or assigned for communications service. When such an indication is provided, an ENUM client can detect calls that will fail "early".</t>
</abstract>
</front>

<middle>
<section anchor="I-D-Intro" title="Introduction">
<t>The Circuit Switched Network (CSN) of which the Public Switched Telephone Network (PSTN), Integrated Services Digital Network (ISDN), and Public Land Mobile Network (PLMN) are part is designed to use E.164 numbers <xref target="E164"></xref> as native global addresses. If a potential caller has an E.164 number, then to place a call using this address he or she needs a way to pass the request either directly or indirectly to systems "in" the CSN for them to forward.</t>

<t>ENUM ("E.164 Number Mapping") has introduced a mechanism to find other contact addresses when given an E.164 number. Thus, if the caller (or an agent somewhere in the call path) has access to the global Domain Name System (DNS), they can use ENUM as described in <xref target="RFC3761">RFC 3761</xref> to find alternative contacts to the E.164 number and place the call using whatever system was indicated in those contacts.

In its intended use, an ENUM query would return a set of NAPTR ("Naming Authority Pointer") resource records <xref target="RFC3403"></xref>, and these would be processed to select the appropriate communications contact choices. Each communications contact is held in a URI ("Universal Resource Indicator") generated from the contents of a NAPTR.</t>

<t>However, ENUM entries may not exist for a given E.164 number for two reasons. Either the assignee who is entitled to register an ENUM domain associated with the E.164 number they hold has chosen not to request this registration, or the number is not currently allocated or assigned for communications service.</t>

<t>In either situation, the caller has no other information and so no alternative to placing the call via the system that uses E.164 numbers as global identifiers; at present, this is the CSN.</t>
</section>

<section anchor="Terminology" title="Terminology">
<t>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 <xref target="RFC2119">RFC 2119</xref>.</t>


</section>

<section anchor="theCases" title="Background: ENUM Lookup Cases">
<t>This section describes the problems that arise where the ENUM system does not hold full information on all telephone numbers and clients display typical behaviour. The proposed solution to the problems described here is covered in <xref target='propSol'></xref> and in the unused Enumservice registration in <xref target='voidReg'></xref>. </t>

  <section anchor="useCases" title="ENUM Registration Cases">
<t>Traditionally, communications service is provided via a network that uses telephone numbers as global addresses. Examples of such networks are the PSTN, ISDN and PLMN.</t>

<t>ENUM registrations are normally allowed only to customers who receive communications service via a telephone number. There may or may not be an ENUM registration when such service is provided. An ENUM registration is usually not permitted when no customer receives service via the corresponding telephone number.</t>

<t>When considering ENUM registrations associated with telephone numbers, there are six scenarios:</t>

<t><list style="numbers">
<t>The number is not allocated to a service provider,</t>

<t>the number is not currently used by that provider for communications service for a customer,</t>

<t>the number is used to provide communications service to a customer and either that customer has not chosen to maintain an ENUM registration associated with that number, or the National Regulatory Authority (NRA) responsible for these numbers does not allow ENUM registrations,</t>

<t>the number is used to provide communications service to a customer and that customer has an ENUM registration associated with that number.</t>
</list></t>

<t>Communications service may alternatively be provided only by recourse to an ENUM lookup. Such numbers are known as "ENUM only" ranges.</t>

<t>For these numbers there are two further possibilities:</t>

<t><list style="hanging">
<t hangText="5.">There is an ENUM registration and that number may be used for communications service,</t>

<t hangText="6.">there is no ENUM registration and therefore the number is not used for communications service.</t>
</list></t>
  </section>

  <section anchor="enumOutcomes" title="ENUM Outcomes">
<t>Assuming properly configured name servers and protocol conformant software, an ENUM query on a domain associated with a telephone number may elicit one of several outcomes based on the DNS <xref target="RFC1034"></xref> response.</t>

<t>In uses cases 1,2,3,and 6, the DNS response will indicate Name Error (RCODE=3, commonly known as NXDOMAIN, signifying that the domain name referenced in the query does not exist).</t>

<t>In use cases 4 and 5, the DNS response will indicate No Error (RCODE=0). There are three possibilities here:</t>

<t><list style="symbols">
<t>There may be at least one usable NAPTR (meaning one in which the Enumservice is supported and the URI is resolved), in which case a communications attempt can be made.</t>

<t>Even though the DNS response indicates no error, there may not be any usable NAPTRs in that response. This may happen because the domain owner has chosen not to populate the zone with NAPTR records. This response (RCODE=0, Number of Answers=0) is also known as NOHOST, meaning that the queried name exists but not for the record type that was requested.</t>

<t>However, even if there are NAPTRs returned, none of the ones present may be usable. For example, the NAPTR RRSet may include only an "h323" Enumservice, whilst the client node is capable only of processing "sip" or "voice:tel" Enumservices.</t>
</list></t>

<t>As it cannot know the case it has encountered, if the client receives a DNS response with no usable NAPTRs or one with RCODE=3, it must decide whether or not to attempt to place the call using other means.</t>
  </section>

  <section anchor="defStrat" title='"Default" Strategy on receiving response with RCODE=3'>
<t>Not every customer has an ENUM registration if provided service via a network that uses telephone numbers natively, and until this is the case, a reasonable strategy has been to attempt to place the call via such a network if it receives an ENUM response with RCODE=3. This is especially true if the National Regulatory Authority has chosen not to permit ENUM registrations at all for the telephone numbers under its control.</t>

<t>This may also be the chosen strategy if the client receives a response with RCODE=0 (No Error), but with no usable NAPTRs.</t>
 </section>

  <section anchor="probIssue" title="The Problem">
<t>In the case of an ENUM client getting a DNS response with RCODE=3, the semantics of that reply are ambiguous. Is this case 1,2,3, or 6? It is useful for the client to know if this is case 3, as in this case the "default" strategy will succeed. In cases 1 and 2, trying to place the call via a network that uses such numbers natively will result in that network returning an error. However, in case 6 even this cannot be guaranteed.</t>

<t>Similarly, if the client finds no usable NAPTRs, is this case 4 or case 5? In the latter case the strategy will fail, whilst in the former case it will succeed.</t>
  </section>

  <section anchor="probEnumOnly" title='"ENUM only" query loop'>
<t>However, for the "ENUM only" cases, there is a further problem. If the call is placed via a network that uses such numbers natively, it can be processed only via an ENUM lookup, and typically this will involve a gateway from that network performing the lookup and delivering the call onwards based on the response. If that gateway receives a response with RCODE=3 or one including no usable NAPTRs, then employing the "default" strategy (attempting the call via a network that uses these numbers natively) will cause a "loop". The call will be redirected to this network, where it will be routed to a gateway, this gateway will perform a lookup, will receive the same response, will attempt to place the call back to that network, and so on.</t>
  </section>
</section>

<section anchor="propSol" title="The Proposed Solution">
<t>We propose an explicit indication of this "number unused" state (as described in points 1,2, and 6 in <xref target='useCases'></xref>). This uses a NAPTR in the zone associated with an unused telephone number, with an Enumservice called "unused" that should be taken as an assertion that the associated E.164 number is not assigned to a subscriber for communications service; it's an unused number.</t>

<t>This NAPTR can also be used by a National Regulatory Authority (NRA) to indicate number blocks that it has reserved, and has not allocated to a service provider.</t>

<t>It is a matter for individual countries whether or not they will support (or require) information giving the identity of the current "owner" of an E.164 number within their responsibility to be made available via IRIS/WHOIS. Thus it may not be possible to use these protocols to find out the entity responsible for a number or number range concerned, particularly where that number or range is not currently "in use".</t>

<t>Since the registration and syntax of a terminal NAPTR for "E2U" Enumservices requires at least one URI scheme to be defined, we propose that the Enumservice "unused" will use an "http:" URI. The content referenced in this "http:" URI is a national matter.
For example, it may be used to refer to a resource providing additional information about the reason for the existence of this record, and/or (where required by the competent regulatory authority) the identity of the entity responsible for this number.</t>
</section>

<section anchor="voidReg" title="ENUM Service Registration - UNUSED">
<t>Enumservice Name: "unused"</t>
<t>Enumservice Type: "unused"</t>
<t>Enumservice Subtypes: "data"</t>
<t>URI Schemes: "http:"</t>

<t>Functional Specification: The proposed solution in <xref target="propSol"></xref>.</t>

<t>Definition of expected action:
<list style="empty">
<t>When an ENUM lookup for a number explicitly returns the "unused" NAPTR, the response indicates to the client that the number is known to ENUM but there are no implicit communication end-points associated with it. The client can then signal an error to the application or end user instead of then trying and failing to terminate the call on the PSTN, which would have been the typical behaviour of an ENUM-aware VoIP/PSTN gateway if the ENUM lookup had returned a DNS response indicating NXDOMAIN or NOHOST.</t>

<t>Thus, if a NAPTR with this Enumservice is received and processed, it indicates that there are no possible communication methods that can be used to reach the end point. The queried E.164 number is currently not allocated, or unassigned to a subscriber for communications service.</t>

<t>The recipient SHOULD treat this response as if they had received a "number not in service" indication from a terminating network.</t>

<t>Note that the generated URI is not a potential target for any current call. The content referred to in the "http:" <xref target="RFC2616">URI</xref> MUST NOT be used in normal call processing but only if there is a non-call related reason.</t>
</list></t>

<t>Security considerations: see <xref target="Sec-Cons"></xref>.</t>

<t>Intended usage: COMMON</t>

<t>Authors
<list style="empty">
<t>Lawrence Conroy, Richard Stastny, Jim Reid (for authors contact details see Authors' Addresses section).</t>
</list></t>

<t>Any other information that the author deems interesting: None</t>
</section>

<section anchor="mistakes" title="Examples">
<!--   <t><list style="numbers">
<t>Unassigned number<vspace blankLines="1" />
$ORIGIN 0.6.9.2.3.6.1.4.4.e164.arpa.<vspace blankLines="0" />
3.8.0 NAPTR 10 100 "u" "E2U+unused:data"<vspace blankLines="0" />
&nbsp;&nbsp;&nbsp;&nbsp;"!^.*$!data:,unassigned!" .<vspace blankLines="1" />
This indicates that the controller of the number block +441632960 does not provide telephony service via the number +441632960083; it is not assigned to a subscriber.</t>

<t>Unallocated number<vspace blankLines="1" />
$ORIGIN 0.6.9.4.5.1.1.4.4.e164.arpa.<vspace blankLines="0" />
* NAPTR 10 100 "u" "E2U+unused:data"<vspace blankLines="0" />
&nbsp;&nbsp;&nbsp;&nbsp;"!^.*$!data:,unallocated!"<vspace blankLines="1" />
This indicates that the number block +441154960 is not allocated by the NRA to any service provider and therefore no number in this block provides any communication service.</t>
</list></t>
-->
<t><list style="numbers">
<t>Unassigned number<vspace blankLines="1" />
$ORIGIN 0.6.9.2.3.6.1.4.4.e164.arpa.<vspace blankLines="0" />
3.8.0 NAPTR 10 100 "u" "E2U+unused:http"<vspace blankLines="0" />
&nbsp;&nbsp;&nbsp;&nbsp;"!^.*$!http://www.nra.example/static/numbering/cupid.htm?cupid=001!" .<vspace blankLines="1" />
This indicates that the controller of the number block +441632960 does not provide telephony service via the number +441632960083; it is not assigned to a subscriber.</t>

<t>Unallocated number<vspace blankLines="1" />
$ORIGIN 0.6.9.4.5.1.1.4.4.e164.arpa.<vspace blankLines="0" />
* NAPTR 10 100 "u" "E2U+unused:http"<vspace blankLines="0" />
&nbsp;&nbsp;&nbsp;&nbsp;"!^.*$!http://www.nra.example/static/numbering/sabc.htm?SABC=1154!"<vspace blankLines="1" />
This indicates that the number block +441154960 is not allocated by the NRA to any service provider and therefore no number in this block provides any communication service.</t>
</list></t>

</section>

<section anchor="Sec-Cons" title="Security Considerations">
<t>DNS does not make policy decisions about the records that it shares with an inquirer. All DNS records must be assumed to be available to all inquirers at all times. The information provided within an ENUM record set must therefore be considered to be open to the public.</t>

<t>An analysis of threats specific to the dependence of ENUM on the DNS, and the applicability of <xref target="RFC4035">DNSSEC ("Domain Name Security") </xref> to these, is provided in <xref target="RFC3833"></xref>.</t>
</section>

<section anchor="Iana-Cons" title="IANA Considerations">
<t>This document requests registration of the "unused" Enumservice with the sub-type "unused:http" according to the guidelines and specifications in RFC 3761 <xref target="RFC3761"></xref> and the definitions in this document. This Enumservice is intended for use with the "http:" URI scheme.</t>
</section>

<section anchor="Shouts" title="Acknowledgements">
<t>Thanks to Patrik Faltstrom, Michael Mealling and Peter Koch for their thorough feedback, and colleagues in ETSI TISPAN who helped to clarify the operational features during the development of <xref target="ETSI-TS102172"></xref>. Thanks also to the members of the ENUM working group for their wide ranging discussions. These have helped to indicate where changes were needed in this document to help explain what is an intrinsically difficult subject. Finally, thanks to Alex Mayrhofer for his useful document review, picking up the remaining issues.</t>
</section>
</middle>

<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>

<author fullname="Scott O. Bradner" initials="S.O." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>Holyoke Center, Room 813</street>
<street>1350 Massachusettes Avenue</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>
<phone>+1 617 495 3864</phone>
<email>[email protected]</email>
</address>
</author>
<date month="March" year="1997" />
</front>
<seriesInfo name="RFC" value="2119" />
<seriesInfo name="BCP" value="14" />
</reference>

<reference anchor="RFC3761">
<front>
<title>The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)</title>

<author fullname="Patrick Faltsrom" initials="P." surname="Faltstrom">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author fullname="Micheal Mealling" initials="M." surname="Mealling">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date month="April" year="2004" />
</front>
<seriesInfo name="RFC" value="3761" />
</reference>

<reference anchor="E164">
<front>
<title>The International Public Telecommunication Number Plan</title>
<author>
<organization abbrev="ITU-T">ITU-T</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date month="February" year="2005" />
</front>
<seriesInfo name="Recommendation" value="E.164" />
</reference>

  <!--
<reference anchor="RFC3401">
<front>
<title>Dynamic Delegation Discovery System (DDDS) 
Part One: The Comprehensive DDDS</title>
<author initials="M." surname="Mealling" fullname="Micheal Mealling">
<organization />
<address>
<postal><street /><city /><region /><code /><country /></postal>
<phone /><facsimile /><email /><uri />
</address>
</author>
<date month="October" year="2002" />
</front>
<seriesInfo name="RFC" value="3401" />
</reference>

<reference anchor="RFC3402">
<front>
<title>Dynamic Delegation Discovery System (DDDS) 
Part Two: The Algorithm</title>
<author initials="M." surname="Mealling" fullname="Micheal Mealling">
<organization />
<address>
<postal><street /><city /><region /><code /><country /></postal>
<phone /><facsimile /><email /><uri />
</address>
</author>
<date month="October" year="2002" />
</front>
<seriesInfo name="RFC" value="3402" />
</reference>
  -->

<reference anchor="RFC3403">
<front>
<title>Dynamic Delegation Discovery System (DDDS) 
Part Three: The Domain Name System (DNS) Database</title>
<author initials="M." surname="Mealling" fullname="Micheal Mealling">
<organization />
<address>
<postal><street /><city /><region /><code /><country /></postal>
<phone /><facsimile /><email /><uri />
</address>
</author>
<date month="October" year="2002" />
</front>
<seriesInfo name="RFC" value="3403" />
</reference>

  <!--
<reference anchor="RFC3404">
<front>
<title>Dynamic Delegation Discovery System (DDDS) 
Part Four: The Uniform Resource Identifiers (URI)</title>
<author initials="M." surname="Mealling" fullname="Micheal Mealling">
<organization />
<address>
<postal><street /><city /><region /><code /><country /></postal>
<phone /><facsimile /><email /><uri />
</address>
</author>
<date month="October" year="2002" />
</front>
<seriesInfo name="RFC" value="3404" />
</reference>

<reference anchor="RFC3405">
<front>
<title>Dynamic Delegation Discovery System (DDDS) 
Part Five: URI.ARPA Assignment Procedures</title>
<author initials="M." surname="Mealling" fullname="Micheal Mealling">
<organization />
<address>
<postal><street /><city /><region /><code /><country /></postal>
<phone /><facsimile /><email /><uri />
</address>
</author>
<date month="October" year="2002" />
</front>
<seriesInfo name="RFC" value="3405" />
</reference>
  -->

<reference anchor="RFC1034">
<front>
<title>DOMAIN NAMES - CONCEPTS AND FACILITIES</title>

<author fullname="" initials="P." surname="Mockapetris">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date month="November" year="1987" />
</front>
<seriesInfo name="RFC" value="1034" />
</reference>

<!--
<reference anchor="RFC2397">
<front>
<title>The "data" URL scheme</title>

<author fullname="L. Masinter" initials="L." surname="Masinter">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date month="August" year="1998" />
</front>
<seriesInfo name="RFC" value="2397" />
</reference>
-->

<reference anchor='RFC2616'>
<front>
<title abbrev='HTTP/1.1'>Hypertext Transfer Protocol -- HTTP/1.1</title>
<author initials='R.' surname='Fielding' fullname='Roy T. Fielding'>
<organization></organization>
<address><postal><street></street><city></city><region></region><code></code><country></country></postal><phone></phone><facsimile></facsimile><email></email><uri></uri>
</address>
</author>
<author initials='J.' surname='Gettys' fullname='James Gettys'>
<organization></organization>
<address><postal><street></street><city></city><region></region><code></code><country></country></postal><phone></phone><facsimile></facsimile><email></email><uri></uri>
</address>
</author>
<author initials='J.' surname='Mogul' fullname='Jeffrey C. Mogul'>
<organization></organization>
<address><postal><street></street><city></city><region></region><code></code><country></country></postal><phone></phone><facsimile></facsimile><email></email><uri></uri>
</address>
</author>
<author initials='H.' surname='Frystyk' fullname='Henrik Frystyk Nielsen'>
<organization></organization>
<address><postal><street></street><city></city><region></region><code></code><country></country></postal><phone></phone><facsimile></facsimile><email></email><uri></uri>
</address>
</author>
<author initials='L.' surname='Masinter' fullname='Larry Masinter'>
<organization></organization>
<address><postal><street></street><city></city><region></region><code></code><country></country></postal><phone></phone><facsimile></facsimile><email></email><uri></uri>
</address>
</author>
<author initials='P.' surname='Leach' fullname='Paul J. Leach'>
<organization></organization>
<address><postal><street></street><city></city><region></region><code></code><country></country></postal><phone></phone><facsimile></facsimile><email></email><uri></uri>
</address>
</author>
<author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'>
<organization></organization>
<address><postal><street></street><city></city><region></region><code></code><country></country></postal><phone></phone><facsimile></facsimile><email></email><uri></uri>
</address>
</author>
<date year='1999' month='June' />
</front>
<seriesInfo name='RFC' value='2616' />
<format type='TXT' target='http://www.ietf.org/rfc/rfc2616.txt' />
</reference>

<!--
<reference anchor='RFC3986'>
<front>
<title abbrev='URI Generic Syntax'>Uniform Resource Identifier (URI): Generic Syntax</title>

<author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'>
<organization>W3C/MIT</organization>
</author>
<author initials='R.T.' surname='Fielding' fullname='Roy T. Fielding'>
<organization>Day Software</organization>
</author>
<author initials='L.' surname='Masinter' fullname='Larry Masinter'>
<organization>Adobe Systems</organization>
</author>
<date year='2005' month='January' />
</front>
<seriesInfo name='RFC' value='3986' />
<format type='TXT' target='http://www.ietf.org/rfc/rfc3986.txt' />
</reference>
-->

</references>

<references title="Informative References">
<reference anchor="RFC4035">
<front>
<title>Protocol Modifications for the DNS Security Extensions</title>
<author fullname="Roy Arends" initials="R." surname="Arends">
<organization></organization>
</author>
<author fullname="" initials="et al." surname="">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date month="March" year="2005" />
</front>
<seriesInfo name="RFC" value="4035" />
</reference>

<reference anchor="RFC3833">
<front>
<title>Threat Analysis of the Domain Name System (DNS)</title>
<author fullname="Derek Atkins" initials="D." surname="Atkins">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author fullname="Rob Austein" initials="R." surname="Austein">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date month="August" year="2004" />
</front>
<seriesInfo name="RFC" value="3833" />
</reference>

<reference anchor="ETSI-TS102172">
<front>
<title>Minimum Requirements for Interoperability of ENUM Implementations</title>
<author>
<organization abbrev="ETSI">ETSI</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date month="January" year="2005" />
</front>
<seriesInfo name="ETSI TS" value="102 172" />
</reference>

  <!--
<reference anchor="RFC2026">
<front>
<title>The Internet Standards Process - Revision 3</title>
<author initials="S.O." surname="Bradner" fullname="Scott O. Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>Holyoke Center, Room 813</street>
<street>1350 Massachusettes Avenue</street>
<city>Cambridge</city> <region>MA</region> <code>02138</code>
<country>US</country>
</postal>
<phone>+1 617 495 3864</phone>
<email>[email protected]</email>
</address>
</author>
<date month="October" year="1996" />
</front>
<seriesInfo name="RFC" value="2026" />
<seriesInfo name="BCP" value="9" />
</reference>

<reference anchor="RFC3978">
<front>
<title>IETF Rights in Contributions</title>
<author initials="S.O." surname="Bradner" fullname="Scott O. Bradner">
<organization /></author>
<date year="2005" month="March" /></front>
<seriesInfo name="BCP" value="78" />
<seriesInfo name="RFC" value="3978" />
</reference>

<reference anchor="RFC3979">
<front>
<title>Intellectual Property Rights in IETF Technology</title>
<author initials="S.O." surname="Bradner" fullname="Scott O. Bradner">
<organization /></author>
<date year="2005" month="March" /></front>
<seriesInfo name="BCP" value="79" />
<seriesInfo name="RFC" value="3979" />
</reference>
-->
</references>
</back>
</rfc>