Subject: RE: [Enum] SchemaSet strawman

From: "Stastny, Richard" <[email-masked]>
Date: Mon, 27 May 2002 14:28:39 +0200

Patrik wrote, to which I respond:

> -----Original Message-----
> From: Patrik Fältström [mailto:[email-masked]] 
> Sent: Monday, May 27, 2002 1:32 PM
> To: Stastny, Richard; Lawrence Conroy; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Enum] SchemaSet strawman
> 
> 
> --On 2002-05-27 11.34 +0200 "Stastny, Richard" 
> <[email-masked]>
> wrote:
> 
> > I want to announce 3 services in ENUM: a phone, a fax and an sms 
> > enabled number. There may be the two extremes and any combination 
> > between:
> > 
> > 1. All services are on one E.164 number (e.g. a sms-enabled fixed 
> > number) 2. The services are all on differnt E.164 numbers, all with 
> > tel: URIs
> 
> You use tel uri and nothing else. Then you probably need one 
> enumservice for the phone where you do voice, one for the tel 
> uri where you do fax and one for the tel uri where you do 
> sms. Especially as they use different E.164 numbers. So, for 
> each number, you have one NAPTR which specify whatever 
> enumservice you define. If people need to differentiate 
> between tel uri for voice and tel uri for fax, then that 
> needs to be in the enumservicefield.
> 
> This is by the way I have heard.

Ok, the "simplfied" NAPTR records will then either look like:

NAPTR blabla "E2U+tel+voice+fax+sms" blabla
tel:+43179780;svc=voice;svc=fax;svc=sms

Or 

NAPTR blabla "E2U+tel+voice" blabla tel:+4317978032;svc=voice
NAPTR blabla "E2U+tel+fax" blabla tel:+4317978013;svc=fax
NAPTR blabla "E2U+tel+sms" blabla tel:+436644204100;sms=sms
 
> If you used SIP instead, the sip people say that one URI is 
> enough, and negotiation is done inside the sip negotiation 
> phase, so only one NAPTR is enough which have one enumservice 
> regardless of whether it is phone, fax or pager.
> 
> I.e. we need MUCH more information from people which actually 
> will use the NAPTR. Technical information.
> 
> > Question:
> > How does the one? NAPTR record look like in the first case, and how 
> > does the three NAPTR records look the second case. I a 
> scheme does not 
> > solve this problem, it is useless.
> 
> As you have three different E.164, there will be three 
> different NAPTR.
> 
> If you have one number which you publish which will lead to 
> the three different services, then you have three NAPTR 
> aswell, each one of them via the rewrite lead to a different 
> tel URI. I.e. the final URI's people get will be different. 
> Have to be different.

This I do not understand. So do I have now three times the same number, so
the first of my examples is invalid? I have to write instead:

NAPTR blabla "E2U+tel+voice" blabla tel:+4317978032;svc=voice
NAPTR blabla "E2U+tel+fax" blabla tel:+4317978032;svc=fax
NAPTR blabla "E2U+tel+sms" blabla tel:+4317978032;sms=sms

Please clarify.

> 
> > I also want to forward another problem we detected with defining the
> > trials: The definition of the enumservices is not only 
> important for 
> > the client applications resolving the NAPTR records, it is also 
> > important for the user-interface for entering data to the DNS. This 
> > issue has never been discussed, but we should keep in mind, 
> that there 
> > has to be a web-portal provided by the Tier 2 Name Service 
> providers, 
> > which enables "normal" users to enter their data to the DNS.
> 
> I would never ever have "web" interface to a DNS I run! For 
> security reasons if nothing else.
> 
> > Since we cannot expect the normal
> > users to be D3S and NAPTR experts, we also have to provide some 
> > "translation". How does e.g. a user friendly webpage look for the 
> > above mentioned example. Does the user have to know, how many NAPTR 
> > records have to be created for a give combination?
> 
> How the translation is to be done is up to the 
> "enumserviceproviders". An excellent for _NON_ 
> standardization and instead competition can work.

Agree, but there is a minor misunderstanding: I definitely do NOT want the
"web" interface standardized, I only wanted to remember, that we should not
only think about how clients are evaluating or parsing the NAPTRs, but also
keep in mind, that on the other side the NAPTRs have to be generated by some
software.

And BTW, I do not really see a problem for a piece of SW to read in the
complete set of NAPTRs and do some kind of calculation on it, e.g. peeking
ahead in the URLs, if we can avoid some duplication of obvious information
like in the examples above. Anyway, I do not really care, as long as we come
to a conclusion a.s.a.p.

Regards
Richard

>   paf

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

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 27 May 2002 18:13:52 +0200

> NAPTR blabla "E2U+tel+sms" blabla tel:+436644204100;sms=sms

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".

> NAPTR blabla "E2U+tel+sms" blabla tel:+4317978032;sms=sms

Yes. One NAPTR can only give back one URI. If you have three different
URI's (as you have above) you need three NAPTR.

> "web" interface standardized, I only wanted to remember, that we should
> not only think about how clients are evaluating or parsing the NAPTRs,
> but also keep in mind, that on the other side the NAPTRs have to be
> generated by some software.

Agreed.

> like in the examples above.

There will be problems if you have non-terminal NAPTR records.

And, applying the regular expressions in the NAPTR might be non-trivial. Or
rather, think about how much calculations you have to do. I think we should
try (I don't claim we can succeed) to minimize the amount of false
positives (and of course see that we don't get any positives we miss) we
get after the client only look at the enumservices, and choose/discard
records accordingly.

With that I mean that a client which get back M NAPTR records after doing a
lookup first of all of course select the X out of M which have a
servicefield which start with E2U. Then out of the X, by looking at the
rest of the servicefield Y will be selected. If among the Y records, only N
can be used by the client, of course a selection will be done after looking
at the URI's, but, I want Y to be as close to N as possible.

 M >= X >= Y >= N

Where

  M - The total number of NAPTR for a given owner
  X - The number of NAPTR were service field start with "E2U"
  Y - The number of NAPTR where the whole service field is ok
  N - The number of URI's which are actually usable by the client

    paf

---

From: Richard Shockey <[email-masked]>
Date: Mon, 27 May 2002 13:10:21 -0400

>I really mean needed from a technical standpoint and not only "because the

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.

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
45980 Center Oak Plaza   Bldg 8     Sterling, VA  20166
1120 Vermont Ave NW Suite 400 Washington DC 20005
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
<mailto: [email-masked]> or
<mailto: [email-masked]>
<http://www.neustar.biz>
<http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

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.

>and "E2U+smptfaxf" for Full Mode or something like that. A single 

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