One document matched: draft-ietf-enum-calendar-service-04.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="no" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<rfc category="std" docName="draft-ietf-enum-calendar-service-04.txt" ipr="full3978">
  <front>
    <title abbrev="IM Enumservice">A Telephone Number Mapping (ENUM) Service
    Registration for Internet Calendaring Services</title>

    <author fullname="Rohan Mahy" initials="R." surname="Mahy">
      <organization>Plantronics</organization>

      <address>
        <postal></postal>

        <email>rohan@ekabal.com</email>
      </address>
    </author>

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

    <area>RAI</area>

    <workgroup>ENUM WG</workgroup>

    <keyword>I-D</keyword>

    <keyword>Internet-Draft</keyword>

    <keyword>ENUM</keyword>

    <keyword>iCal</keyword>

    <abstract>
      <t>This document registers a Telephone Number Mapping (ENUM) service for
      Internet Calendaring Services. Specifically, this document focuses on
      provisioning 'mailto:' (iMIP) and 'http:' (CalDAV) URIs in ENUM.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>ENUM (E.164 Number Mapping, <xref target="RFC3761">RFC 3761</xref>)
      is a system that uses DNS (Domain Name Service, <xref
      target="RFC1034">RFC 1034</xref>) to translate telephone numbers, such
      as '+12025550100', into URIs (Uniform Resource Identifiers, <xref
      target="RFC3986">RFC 3986</xref>), such as 'mailto:user@example.com'. ENUM
      exists primarily to facilitate the interconnection of systems that rely
      on telephone numbers with those that use URIs to identify resources. The ENUM registration here could be used to allow phones for example to check the free/busy status of a user in their address book or propose a meeting with him or her from the user's phone number.</t> 
      
      <t>The <xref target="RFC3283">Guide to Internet Calendaring</xref> describes
      the relationship between various internet calendaring specifications like this:
      "<xref target="RFC2445">iCalendar</xref> is the language used to describe calendar
      objects.  <xref target="RFC2446">iTIP</xref> [Transport-Independent Interoperability
      Protocol] describes a way to use the iCalendar 
      language to do scheduling.  <xref target="RFC2447">iMIP</xref> [Message-Based
      Interoperability Protocol] describes how to do iTIP scheduling via e-mail."</t>

      <t>
        Recently another standard track protocol for calendar and scheduling access 
        has appeared.  

        <xref target="RFC4791">CalDAV</xref> (Calendaring Extensions 
        to WebDAV) is a <xref target="RFC4918">WebDAV</xref> (Web-based Distributed 
        Authoring and Versioning) based mechanism for manipulating 
        internet calendars, viewing free/busy lists, and via a planned <xref target="I-D.desruisseaux-caldav-sched">scheduling extension</xref>, could be used for proposing calendar events as well. 
      </t>
      
      <t>
        The existing 'mailto:' URI scheme (defined in 
        <xref target="RFC3986">RFC 3986</xref>) is already used to 
        address iMIP compatible Calendar Services.  Likewise the 
        existing 'http:' and 'https:' URI schemes (defined in 
        <xref target="RFC2616">RFC 2616</xref> and 
        <xref target="RFC2818">RFC 2818</xref>) are already
        used to address CalDAV compatible Calendar Services.  
        
      </t>  

      <t>This document registers an
      enumservice for advertising internet calendaring information associated 
      with an E.164 number, using the 'mailto:', 'http:', or 'https:' schemes.</t>
    </section>

    <section title="ENUM Service Registration - ical" anchor="meat">
      <t>As defined in <xref target="RFC3761">RFC 3761</xref>, the following
      is a template covering information needed for the registration of the
      enumservice specified in this document:</t>

<list style="hanging">
<t hangText="Enumservice Name:"></t><t>"ical"</t>
<t hangText="Enumservice Type:"></t><t>"ical"</t>
<t hangText="Enumservice Subtypes:"></t><t>sched</t>  
<t hangText="URI scheme(s):"></t><t>"mailto:", "http:", "https:"</t> 
<t hangText="Functional Specification:"></t><t> 
  This Enumservice indicates that the resource identified is a
  URI used for scheduling using Internet Calendaring.  Supported URI schemes are the 'mailto:' URI for the <xref target="RFC2447">iMIP</xref> protocol, and 'http:' or 'https:' URIs for a planned <xref target="I-D.desruisseaux-caldav-sched">scheduling extension</xref> to the <xref target="RFC4791">CalDAV</xref> protocol.
</t>
<t hangText="Security considerations:"></t><t>See section 3.</t> 
<t hangText="Intended usage:"></t><t>COMMON</t> 
<t hangText="Author:"></t><t>Rohan Mahy (rohan@ekabal.com)</t>
</list>

<list style="hanging">
<t hangText="Enumservice Name:"></t><t>"ical"</t>
<t hangText="Enumservice Type:"></t><t>"ical"</t>
<t hangText="Enumservice Subtypes:"></t><t>access</t>  
<t hangText="URI scheme(s):"></t><t>"http:", "https:"</t> 
<t hangText="Functional Specification:"></t><t> 
  This Enumservice indicates that the resource identified is a
  URI used for Internet Calendaring which is available to access a user's calendar (for example free/busy status).  
  Supported URI schemes are 'http:' or 'https:' URIs for the 
  <xref target="RFC4791">CalDAV</xref> protocol.
</t>
<t hangText="Security considerations:"></t><t>See section 3.</t> 
<t hangText="Intended usage:"></t><t>COMMON</t> 
<t hangText="Author:"></t><t>Rohan Mahy (rohan@ekabal.com)</t>
</list>
    </section>

<section title="Example of Usage">
<t>Below is a set of sample resource records for this enumservice.</t>
<figure><artwork>
$ORIGIN 3.2.1.0.5.5.5.2.1.2.1.e164.arpa. 
@ NAPTR 10 100 "u" "E2U+ical:access"
  "!^.*$!http://cal.example.com/home/alice/calendars/!" .

$ORIGIN 3.2.1.0.5.5.5.2.1.2.1.e164.arpa. 
@ NAPTR 10 100 "u" "E2U+ical:sched"
  "!^.*$!mailto:alice@example.com!" .
</artwork></figure>
</section>


    <section title="Security Considerations">
<t>The Domain Name System (DNS) does not make policy decisions about 
   which records it provides to a DNS resolver. 
   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 open to the public -- which
   is a cause for some privacy considerations.
</t><t>
   Revealing a calendaring URI by itself is unlikely to introduce many
   privacy concerns, although, depending on the structure of the URI, it
   might reveal the full name or employer of the target.  The use of
   anonymous URIs mitigates this risk.  
</t><t>   
As ENUM uses DNS, which in its current form is an insecure protocol, there is no mechanism for ensuring that the answer returned to a query is authentic.  An analysis of threats specific to the dependence of ENUM on the DNS is provided in RFC 3761 and a thorough analysis of threats to the DNS itself is covered in <xref target="RFC3833">RFC 3833</xref>.  Many of these problems are prevented when the resolver verifies the authenticity of answers to its ENUM queries via <xref target="RFC4035">DNSSEC</xref> in zones where it is available.
</t><t>  
  More serious security concerns are associated with potential attacks against 
  an underlying calendaring system (for example, unauthorized modification or viewing).  
  For this reason, iTIP discusses a number of
   security requirements (detailed in <xref target="RFC2446">RFC 2446</xref>) 
  that call for authentication, integrity and confidentiality properties,
   and similar measures to prevent such attacks.  Any
   calendaring protocol used in conjunction with a URI scheme currently meets 
  these requirements.  The use of CalDAV with the 'https:' scheme makes use of 
  <xref target="RFC4346">TLS</xref> (Transport Layer Security) to provide server authentication, confidentiality, and message integrity.
</t><t>
   Unlike a traditional telephone number, the resource identified by an
   calendaring URI is often already guessable and often requires that 
   users provide cryptographic credentials
   for authentication and authorization before calendar data can be
   exchanged.  Despite the public availability of ENUM records, the
   use of this information to reveal an unprotected calendaring resource
   is unlikely in practice.
</t>
    </section>

    <section title="IANA Considerations">
      <t>This document requests registration of the "iCal" Enumservice according
      to the definitions in <xref target="meat"/> of this document and <xref target="RFC3761">RFC
      3761</xref>.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.3761" ?>
      <?rfc include="reference.RFC.1034" ?>
      <?rfc include="reference.RFC.3986" ?>
      <?rfc include="reference.RFC.2445" ?>
      <?rfc include="reference.RFC.2446" ?>
      <?rfc include="reference.RFC.2447" ?>
      <?rfc include="reference.RFC.4791" ?>
      <?rfc include="reference.RFC.4918" ?>
      <?rfc include="reference.RFC.4035" ?>      
    </references>

    <references title="Informational References">
      <?rfc include="reference.RFC.3283" ?>
      <?rfc include="reference.RFC.2616" ?>
      <?rfc include="reference.RFC.2818" ?>
      <?rfc include="reference.RFC.4346" ?>
      <?rfc include="reference.RFC.3833" ?>
      <?rfc include="reference.I-D.desruisseaux-caldav-sched" ?>
    </references>
    
    <section title="Acknowlegments">
      <t>Thanks to Lisa Dusseault and Alexander Mayrhofer for reviewing this document.</t>
    </section>
  </back>
</rfc>