Hi folks,
Please note that a brief I-D for this (discovery of IFax services
via IETF ENUM) is appended at the end of this note forwarded to
the IETF IFax WG list by Richard Shockey.
Cheers,
- Ira McDonald
High North Inc
-----Original Message-----
From: Toyoda, Kiyoshi [mailto:ktoyoda at rdmg.mgcs.mei.co.jp]
Sent: Tuesday, May 28, 2002 2:00 AM
To: Richard Shockey
Cc: Patrik F?tstr?; enum at ietf.org; ietf-fax at imc.org
Subject: Re: [Enum] SchemaSet strawman
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:paf at ifax.net!"
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
ktoyoda at rdmg.mgcs.mei.co.jp
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