Subject: Re: [Enum] SchemaSet strawman

From: "Toyoda, Kiyoshi" <[email-masked]>
Date: Tue, 28 May 2002 15:00:00 +0900

Shockey-san,

I would like to propose ifax services of ENUM. I comment
below.

Richard Shockey wrote:
>>
>>What I have heard is more like:
>>
>>  NAPTR blabla "E2U+telvoice" blabla tel:+4317978032;svc=voice
>>  NAPTR blabla "E2U+telfax" blabla tel:+4317978013;svc=fax
>>  NAPTR blabla "E2U+telsms" blabla tel:+436644204100;sms=sms
>>
>>I.e. in your first example, what is the meaning of "tel"? What is the
>>registration of "voice"? What if only "tel" exists and not "voice"? What if
>>"voice" exists and not "tel"?
>>
>>The '+' sign is to separate enumservices alltogether. If we are going down
>>the path of "subservices" then we need to use a different separator, like
>>'-'. I would like to NOT go down that path if not really really needed. And
>>I really mean needed from a technical standpoint and not only "because the
>>design looks nice".
>
>On reflection, I stand corrected Patrik ..I think you are right ... the '+' 
>should separate distinct services.
>
>So to follow your example in the case of SMTP you would 
>suggest  "E2U+smtpfaxs" for possibly designating Simple Mode Fax [RFC2503] 
>and "E2U+smptfaxf" for Full Mode or something like that. A single 
>enumservice designator.
>

I want to use ENUM for two services of IFAX. One is a service to get 
simply e-mail address of destination. Another is a service to get
URI of directory server such as LDAP which has the e-mail address 
and capability of destination IFAX. I think that the former service 
will be acceptable easier by IFAX WG and ENUM WG than latter. So,
I made a simple draft below at first. Please comment.

-------------------------------------------------------------------
Network Working Group                        K. Toyoda, MGCS
Internet Draft                      
                                                    May 2002
Expires: November 2002

                   IFAX service of ENUM

     STATUS OF THIS MEMO
     
     This document is an Internet-Draft and is in full
     conformance with all provisions of Section 10 of
     RFC2026. 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.
     
     COPYRIGHT NOTICE
     
     Copyright (C) The Internet Society (2001).  All Rights
     Reserved.

     The key words "MUST", "MUST NOT", "SHOULD", "SHOULD
     NOT", and "MAY" in this document are to be interpreted
     as defined in "Key words for use in RFCs to Indicate
     Requirement Levels" [KEYWORDS].

Abstract
     
     This document describes the functional specification 
     and the definition of the ENUM NAPTR record, for IFax 
     service. IFax is "Facsimile using Internet Mail".  For 
     this use, the DNS returns the email address of the 
     referenced IFax system.

1.   Functional Specification

    An IFax client makes an Enum DNS query with the target 
    system's telephone number.  The returned NAPTR record 
    specifies an email address that is to be used for reaching
    the target system.  The email address is then used in 
    accordance with "Simple Mode of Facsimile using Internet 
    Mail" [RFC2305] or "Extended Facsimile using Internet 
    Mail" [RFC2532]

2.   Definition of NAPTR record
2.1 Service Name   
    Service Name = "ifax"
    The scope of this service is facsimile using Internet mail.
    It includes "Simple Mode of Facsimile using Internet Mail"
    and "Extended Facsimile using Internet Mail". "Full Mode 
    Fax Profile for Internet Mail" is applied when it is 
    approved as an Internet standards-track specification.

2.2 URI Scheme
    Scheme = "mailto"

    The URI Scheme is "mailto" because facsimile using 
    Internet Mail is a profile for standard Internet mail and
    uses standard Internet mail addressing. 

    Example
    $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa
      IN NAPTR 10 10 "u" "E2U+ifax" "!^.*$!mailto:[email-masked]!"

2.3 Intended usage
    COMMON

3 Security Consideration
    The Security Considerations section of [RFC2305] and 
    [RFC2532] applies to this document.

4.   ACKNOWLEDGEMENTS
     Dave Crocker provided useful suggestions to an earlier
     draft.

5.   REFERENCES
     [ENUMbis]  Falstrom, P., M. Mealling, "The E.164 to URI 
     DDDS Application", draft-ietf-enum-rfc2916bis-00, 
     February 22, 2002

     [RFC2305] Toyoda, K., Ohno, H., Murai, J. and  D. Wing, "A
     Simple Mode of Facsimile Using Internet Mail", RFC 2305,
     March 1998. 

     [RFC2532] Masinter, L., D. Wing, "Extended Facsimile Using 
     Internet Mail", March 1999

     [FFPIM] Crocker, D., G. Klyne, L. Masinter, "Full-mode 
     Fax Profile for Internet Mail", DRAFT-IETF-FAX-FFPIM-03,
     March, 2002

6.       AUTHORS' ADDRESSES
     
     Kiyoshi Toyoda
     Matsushita Graphic Communication Systems,Inc
     2-3-8 Shimomeguro, Meguro-Ku
     Tokyo 153  JAPAN
     
     +81.3.5434.7161
     [email-masked]

7.       FULL COPYRIGHT STATEMENT
     
     Copyright (C) The Internet Society (2001).  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.

Kiyoshi Toyoda