From Carsten.Schiefner at t-com.net Tue Oct 4 10:40:52 2005 From: Carsten.Schiefner at t-com.net (Schiefner, Carsten) Date: Tue, 4 Oct 2005 10:40:52 +0200 Subject: [enum-wg] Draft RIPE 51 ENUM WG agenda Message-ID: Dear colleagues, Your co-chairs are pleased at the apparent level of general interest in ENUM, which has led to the inclusion of several ENUM-related presentations in the plenary sessions of RIPE 51. The extended draft agenda of the ENUM WG at RIPE 51 is thus as follows: - Tue, 11 October, 14:00-15:30/90 min Marcos Sanz, DENIC (20 min) 'Reasons for (not) using EPP for ENUM' Adrian Georgescu, AG Projects (20 min) 'ENUM Tier 2 provisioning techniques' Robert Schischka, enum.at, and Bernie Hoeneisen, SWITCH (20 min) 'ENUM validation Schemes and process flow' Panel discussion with the presenters and Andrzej Bartosiewicz, NASK (30 min) - Tue, 11 October, 16:00-16:30/30 min Michael Haberler, IPA/nic.at (30 min) 'Carrier ENUM and VoIP Peering' - Thu, 13 October, 14:00-15:30/90 min A. Preliminaries (5 min) . Welcome . Scribe . Confirm agenda B. Previous Meeting (5 min) . Note and approve minutes . Note open issues, if any C. Carsten Schiefner, Deutsche Telekom (10 min) News summary: . IETF 63 . I-D/RFC watch . DENIC's ENUM day D. Axel Pawlik, RIPE NCC (15 min) Status update of ENUM at the RIPE NCC . Statistics . Tier 0 status . misc E. Jim Reid, DNS-MODA (10 min) Update on the ETSI ENUM Plugtest F. Peter Koch, DENIC (10 min) 'Walking the 9.4.e164.arpa tree: first results' G. Jim Reid, DNS-MODA (10 min) E.164 testbed numbers: per country or directly from the ITU? H. Provisioning, Carrier ENUM and VoIP Peering (10 min) . Arising from plenary . Other, if any : Y. I/O with other WGs, AOB (10 min) Z. Close (5 min) . Summarize action items . Thank scribe and participants Last, but not least: can we kindly ask the presenters to send us a better wording for the title of their respective talk if they feel that the current one (basically made up by your co- chairs) doesn't really hit the spot? Best regards, Carsten Schiefner -- Carsten Schiefner | p: +49 441 234-4571 Deutsche Telekom AG | f: +49 431 7163-3972 T-Com Zentrale TK44 | m: +49 151 14525458 Ammerl?nder Heerstr. 138 | mailto:Carsten.Schiefner at t-com.net D-26129 Oldenburg | http://www.t-com.de/kundendienst From enumvoipsip.cs at schiefner.de Fri Oct 7 14:46:40 2005 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Fri, 07 Oct 2005 14:46:40 +0200 Subject: [enum-wg] FYI: DENIC Preparing Start of Full-Scale ENUM Operation Message-ID: <43466E30.50203@schiefner.de> Dear colleagues, please find DENIC's press release at: http://www.denic.de/en/denic/presse/press_72.html Best - enjoy your weekend and hope to see you all next week then: Carsten Schiefner From enumvoipsip.cs at schiefner.de Fri Oct 7 15:02:34 2005 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Fri, 07 Oct 2005 15:02:34 +0200 Subject: [enum-wg] ENUM-capable email client? Message-ID: <434671EA.1050105@schiefner.de> All, there is a Firefox ENUM plug-in (currently for Win only) available at: http://www.falb.at/ that resolves enum:[E.164 number] to an URL in case such web service is specified in the respective ENUM zone to that very E.164 number. E.g., with this plug-in, a click on enum:+43780325228 would get you to Juergen Falb's homepage, too. My question is: is anyone aware of a similar extension or even built-in function of a mail client, so that an E.164 number would be resolved to an email address? Best regards, Carsten Schiefner From enumvoipsip.cs at schiefner.de Fri Oct 7 15:42:26 2005 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Fri, 07 Oct 2005 15:42:26 +0200 Subject: [enum-wg] ENUM-capable email client? In-Reply-To: <434671EA.1050105@schiefner.de> References: <434671EA.1050105@schiefner.de> Message-ID: <43467B42.5020606@schiefner.de> Carsten Schiefner wrote: > [...] > > My question is: is anyone aware of a similar extension or even built-in > function of a mail client, so that an E.164 number would be resolved to > an email address? In the meantime I have been pointed at: http://www.enum.cn/Enum/EnumReg/member.php?language=English - has anyone already gained experience with these extensions? Two questions: 1) is it generic, i.e. does it work with all IE and Outlook installations, or does it require a localised-to-chinese version? Although I am not totally happy with either one of these programs, I do not have any need for a broken installion... 2) I stumbled over "The number should be registered ENUM number of www.enum.cn": does it only work with Chinese numbers or is it using the complete e164.arpa tree for resolution? Besides that: any other pointers are still welcome, of course! :-) Best, Carsten From kewin.stoeckigt at aarnet.edu.au Sat Oct 8 08:46:36 2005 From: kewin.stoeckigt at aarnet.edu.au (Kewin Stoeckigt) Date: Sat, 08 Oct 2005 16:46:36 +1000 Subject: [enum-wg] ENUM-capable email client? In-Reply-To: <43467B42.5020606@schiefner.de> References: <434671EA.1050105@schiefner.de> <43467B42.5020606@schiefner.de> Message-ID: <43476B4C.5020405@aarnet.edu.au> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Carsten, if you have a look at http://www.aarnet.edu.au/services/enum/enum_use.html you find a small list of tools you can use with ENUM. Kewin Carsten Schiefner wrote: > Carsten Schiefner wrote: > >> [...] >> >> My question is: is anyone aware of a similar extension or even >> built-in function of a mail client, so that an E.164 number would be >> resolved to an email address? > > > In the meantime I have been pointed at: > > http://www.enum.cn/Enum/EnumReg/member.php?language=English > > - has anyone already gained experience with these extensions? Two > questions: > > 1) is it generic, i.e. does it work with all IE and Outlook > installations, or does it require a localised-to-chinese version? > Although I am not totally happy with either one of these programs, I do > not have any need for a broken installion... > > 2) I stumbled over "The number should be registered ENUM number of > www.enum.cn": does it only work with Chinese numbers or is it using the > complete e164.arpa tree for resolution? > > Besides that: any other pointers are still welcome, of course! :-) > > Best, > > Carsten > - -- - ---------------------------------------------- Australian Academic and Research Network (AARNet) Kewin Stoeckigt Building 9, Banks Street Canberra ACT 2600 Australia Phone: +61 2 6222 3546 Fax: +61 2 6222 3535 Mobile:+61 4 2158 2563 Email: kewin.stoeckigt at aarnet.edu.au SIP: kewin.stoeckigt at aarnet.edu.au WWW: http://www.aarnet.edu.au/~kos/ - ----------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) iD8DBQFDR2tMbhxXquPpou8RAu8jAJ0SoZcPeKE9GaThfK0XR5NJbYgDgwCbBD/k 5+eOSuFcTLlOJWoj4cvz8p0= =c+hi -----END PGP SIGNATURE----- From enumvoipsip.cs at schiefner.de Tue Oct 11 14:10:51 2005 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Tue, 11 Oct 2005 14:10:51 +0200 Subject: [enum-wg] ENUM-capable email client? In-Reply-To: <43476B4C.5020405@aarnet.edu.au> References: <434671EA.1050105@schiefner.de> <43467B42.5020606@schiefner.de> <43476B4C.5020405@aarnet.edu.au> Message-ID: <434BABCB.4070109@schiefner.de> Hi Kewin, Kewin Stoeckigt wrote: > Hi Carsten, > if you have a look at > http://www.aarnet.edu.au/services/enum/enum_use.html you find a small > list of tools you can use with ENUM. thanks for the link! :-) Best, Carsten From chenhui at cnnic.cn Fri Oct 14 10:12:33 2005 From: chenhui at cnnic.cn (chenhui) Date: Fri, 14 Oct 2005 16:12:33 +0800 Subject: [enum-wg] ENUM-capable email client? References: <434671EA.1050105@schiefner.de> <328692573.22123@cnnic.cn> Message-ID: <329277553.29263@cnnic.cn> Hi Carsten, I have add some comment in your letter as following. Chenhui ----- Original Message ----- From: "Carsten Schiefner" To: Sent: Friday, October 07, 2005 9:42 PM Subject: Re: [enum-wg] ENUM-capable email client? > Carsten Schiefner wrote: >> [...] >> >> My question is: is anyone aware of a similar extension or even built-in >> function of a mail client, so that an E.164 number would be resolved to >> an email address? > > In the meantime I have been pointed at: > > http://www.enum.cn/Enum/EnumReg/member.php?language=English > > - has anyone already gained experience with these extensions? Two questions: > > 1) is it generic, i.e. does it work with all IE and Outlook > installations, or does it require a localised-to-chinese version? > Although I am not totally happy with either one of these programs, I do > not have any need for a broken installion... *** We have tested the Windows2000 and XP, IE V5 and newer, it shows ok. BTW, Could you please let me know what is the phenomenon of 'a broken installion'? > > 2) I stumbled over "The number should be registered ENUM number of > www.enum.cn": does it only work with Chinese numbers or is it using the > complete e164.arpa tree for resolution? > ***till now, it only supports Chinese number rule. And we will do the upgrade to let it support many kinds of number rule these days. > Besides that: any other pointers are still welcome, of course! :-) > > Best, > > Carsten From alexander.mayrhofer at enum.at Fri Oct 14 11:29:47 2005 From: alexander.mayrhofer at enum.at (Alexander Mayrhofer) Date: Fri, 14 Oct 2005 11:29:47 +0200 Subject: [enum-wg] please help us make the ENUM number range +43 780 a success Message-ID: <434F7A8B.4000806@enum.at> Hi, as you probably know, Austria has a dedicated ENUM driven number range in place since May 2005: +43 780. Reachability of numbers within this range from the PSTN is good within Austria, but still a patchwork from abroad (as with all new number ranges). it is very hard to debug PSTN connectivity from the receiving end - which is why we are asking you dedicate a few minutes of time and a phone call. To collect the information we've set up a Wiki page: http://www.voip-info.org/wiki/view/43780 To help us make it better, follow these steps: - take a "conventional" phone line of your choice (PSTN, mobile - the more data points, the better) - call the test number "+43 780 004711" - if you hear the word "ENUM" followed by some elevator music, routing from your telco is ok - perfect! - if it doesn't work, take a note of what happened (announcement, error message, error indication etc.) - leave a note about your success or failure to the wiki page indicated above. If possible, add rate information. - repeat this test for any carrier you have access to. If you detect a failure, and happen to know or work for the telco - please notify the relevant person to fix the problem, it is theirs. We're happy to talk to them if you get us in touch. Thanks for your help - we really appreciate it. Feel free to forward this message to people who might contribute more data points. thanks, Alex Mayrhofer enum.at From fw at deneb.enyo.de Mon Oct 17 15:07:12 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 17 Oct 2005 15:07:12 +0200 Subject: [enum-wg] ENUM-capable email client? In-Reply-To: <434671EA.1050105@schiefner.de> (Carsten Schiefner's message of "Fri, 07 Oct 2005 15:02:34 +0200") References: <434671EA.1050105@schiefner.de> Message-ID: <87k6gcxpfj.fsf@mid.deneb.enyo.de> * Carsten Schiefner: > My question is: is anyone aware of a similar extension or even built-in > function of a mail client, so that an E.164 number would be resolved to > an email address? Shouldn't this be part of the MTA, and not the MUA? After all, it's some kind of mail routing. From john-ietf at jck.com Mon Oct 17 16:35:26 2005 From: john-ietf at jck.com (John C Klensin) Date: Mon, 17 Oct 2005 10:35:26 -0400 Subject: [enum-wg] ENUM-capable email client? In-Reply-To: <87k6gcxpfj.fsf@mid.deneb.enyo.de> References: <434671EA.1050105@schiefner.de> <87k6gcxpfj.fsf@mid.deneb.enyo.de> Message-ID: --On Monday, 17 October, 2005 15:07 +0200 Florian Weimer wrote: > * Carsten Schiefner: > >> My question is: is anyone aware of a similar extension or >> even built-in function of a mail client, so that an E.164 >> number would be resolved to an email address? > > Shouldn't this be part of the MTA, and not the MUA? After > all, it's some kind of mail routing. The only way to make it part of the MTA would defeat what I consider the fundamental purpose of ENUM. I believe that purpose is not merely to establish a way to map between phone numbers and most of a a domain name (i.e., the reversing process established in RFC 1528 and 1530) but to provide a "single tree" so that the rightmost components of the domain name do not need to be specified by the user. At present, there is a firm SMTP requirement that any email address by expressed as local-part at fully-qualified-domain-name. Even if you could get community approval of the change, permitting, e.g., +12345678901234 as an email address would require changing of every MTA in the network before ENUM->email would work reliably. Such agreement is unlikely. For example, +12345678901234 at example.com could be a valid email address today, having nothing to do with ENUM. While RFC 2821 has a prohibition on MTAs accepting a local part and making up a domain name, precisely that is permitted for submission servers (first-hop MTAs under some circumstances). So, for example, suppose that smtp.bogus.domain.name is a submission server that now has the convention that, if it receives RCPT TO: it is to change it to RCPT TO: and "some-unqualified-name" might be all-digits or all-digits preceded by a plus-sign, it is going to have a very hard time figuring out which unqualified names should be mapped that way and which ones should be reversed and catenated to ".e164.arpa." This really is an MUA function, where there are any number of ways that those transformations might be determined. john From fw at deneb.enyo.de Mon Oct 17 19:23:09 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 17 Oct 2005 19:23:09 +0200 Subject: [enum-wg] ENUM-capable email client? In-Reply-To: (John C. Klensin's message of "Mon, 17 Oct 2005 10:35:26 -0400") References: <434671EA.1050105@schiefner.de> <87k6gcxpfj.fsf@mid.deneb.enyo.de> Message-ID: <87ach8ukg2.fsf@mid.deneb.enyo.de> * John C. Klensin: > permitting, e.g., > +12345678901234 > > as an email address would require changing of every MTA in the > network before ENUM->email would work reliably. Such agreement > is unlikely. For example, +12345678901234 at example.com could be > a valid email address today, having nothing to do with ENUM. You would use +12345678901234 at e164.arpa, I guess, where the @e164.arpa part could be supplied by the MUA. (Of course, e164.arpa should have a "MX ." RR.) If you opt for a purely MUA-based approach, you can never-ever put E.164 addresses in the message header. ENUM email addresses would remain second-class citizens, just like internationalized domain names implemented with IDNA. From pk at DENIC.DE Mon Oct 17 19:43:17 2005 From: pk at DENIC.DE (Peter Koch) Date: Mon, 17 Oct 2005 19:43:17 +0200 Subject: [enum-wg] ENUM-capable email client? In-Reply-To: <87ach8ukg2.fsf@mid.deneb.enyo.de> References: <434671EA.1050105@schiefner.de> <87k6gcxpfj.fsf@mid.deneb.enyo.de> <87ach8ukg2.fsf@mid.deneb.enyo.de> Message-ID: <20051017174317.GB2157@denics7.denic.de> On Mon, Oct 17, 2005 at 07:23:09PM +0200, Florian Weimer wrote: > You would use +12345678901234 at e164.arpa, I guess, where the @e164.arpa > part could be supplied by the MUA. (Of course, e164.arpa should have > a "MX ." RR.) It should not. Last news about the necessary A RR for "." came from a parallel universe and draft-delany-nullmx-00.txt just misses the operational consequences. Using the "@e164.arpa" part to deviate from the standard mail routing algorithm won't fly. -Peter From john-ietf at jck.com Mon Oct 17 19:51:55 2005 From: john-ietf at jck.com (John C Klensin) Date: Mon, 17 Oct 2005 13:51:55 -0400 Subject: [enum-wg] ENUM-capable email client? In-Reply-To: <87ach8ukg2.fsf@mid.deneb.enyo.de> References: <434671EA.1050105@schiefner.de> <87k6gcxpfj.fsf@mid.deneb.enyo.de> <87ach8ukg2.fsf@mid.deneb.enyo.de> Message-ID: --On Monday, 17 October, 2005 19:23 +0200 Florian Weimer wrote: > * John C. Klensin: > >> permitting, e.g., >> +12345678901234 >> >> as an email address would require changing of every MTA in the >> network before ENUM->email would work reliably. Such >> agreement is unlikely. For example, >> +12345678901234 at example.com could be a valid email address >> today, having nothing to do with ENUM. > > You would use +12345678901234 at e164.arpa, I guess, where the > @e164.arpa part could be supplied by the MUA. (Of course, > e164.arpa should have a "MX ." RR.) There are two ways (at least that I can think of) to implement that suggestion... * With one, the MTA would somehow look at that string and rewrite it into 4.3.2.1.0.9.8.7.6.5.4.3.2.1.e164.arpa. If any intermediate did that, it would really push the limits on the principle that intermediate MTAs not try to interpret or rewrite local-parts. * With the other, the mail would actually be delivered to the MTA for e164.arpa (that would be the effect of the wildcard MX I think you are suggesting). That would work, but raises two issues. First, it would create a single, or concentrated, point of failure, which is part of what ENUM was intended to avoid. Second, at least formally, the rewriting of +12345678901234 at e164.arpa into 4.3.2.1.0.9.8.7.6.5.4.3.2.1.e164.arpa and resending the mail is an MUA function, even if it is performed on behalf of the user by an MTA halfway out in the network. In thinking about this, you should be aware of something else if you are not: although +12345678901234 at e164.arpa is a perfectly valid email address under the rules of RFC 2821 and 2822, a huge number of web sites and web-based mail systems will treat it as invalid. If anything, the number seems to be on the rise despite efforts to turn back the tide. So, realistically, unless the transformation is handled in the MUA (or you assume that any all-digit local part is an E.164 address) strings starting in "+" are going to fail regularly enough to create their own set of problems. > If you opt for a purely MUA-based approach, you can never-ever > put E.164 addresses in the message header. ENUM email > addresses would remain second-class citizens, just like > internationalized domain names implemented with IDNA. As is the case with the work underway with internationalized email addressing (see, e.g., the "IEE" BoF scheduled for Vancouver and the documents listed in its agenda), we should go as far as possible in supporting new ways of doing things as long as we do not, in the process, break the existing infrastructure. If someone wants to provide, fund, and support mail servers for e164.arpa that perform the remapping you suggest, are robust and scalable enough to support the relevant workload, and can work out sufficient trust arrangements with the relevant communities, then so be it. But expecting MTAs to start rewriting addresses that have some particular set of syntax characteristics strikes me and being well within the range of breaking things that are legitimate uses today. john From enumvoipsip.cs at schiefner.de Tue Oct 18 08:37:12 2005 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Tue, 18 Oct 2005 08:37:12 +0200 Subject: [enum-wg] ENUM-capable email client? In-Reply-To: <329277553.29263@cnnic.cn> References: <434671EA.1050105@schiefner.de> <328692573.22123@cnnic.cn> <329277553.29263@cnnic.cn> Message-ID: <43549818.4090701@schiefner.de> Hi Chenhui, chenhui wrote: >>1) is it generic, i.e. does it work with all IE and Outlook >>installations, or does it require a localised-to-chinese version? >>Although I am not totally happy with either one of these programs, I do >>not have any need for a broken installion... > > *** We have tested the Windows2000 and XP, IE V5 and newer, it shows ok. this is good news. :-) > BTW, Could you please let me know what is the phenomenon of 'a broken installion'? Sure. What I was afraid of is that a plug-in might destroy my current installation of IE or Outlook because it was not made for the installation I am using. Disclaimer: I have no deep insight or technical background about the DOs and DONTs here, but heard stories... But with your assurance I am relieved that with these two extensions I will not put myself in jeopardy. :-) >>2) I stumbled over "The number should be registered ENUM number of >>www.enum.cn": does it only work with Chinese numbers or is it using the >>complete e164.arpa tree for resolution? > > ***till now, it only supports Chinese number rule. And we will do the upgrade to let it support many kinds of number rule these days. Can you please drop us a note on this mailing list once your extensions will support any ENUM delegation made under e164.arpa? Very much appreciated! Best, Carsten From fw at deneb.enyo.de Tue Oct 18 16:32:53 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 18 Oct 2005 16:32:53 +0200 Subject: [enum-wg] ENUM-capable email client? In-Reply-To: (John C. Klensin's message of "Mon, 17 Oct 2005 13:51:55 -0400") References: <434671EA.1050105@schiefner.de> <87k6gcxpfj.fsf@mid.deneb.enyo.de> <87ach8ukg2.fsf@mid.deneb.enyo.de> Message-ID: <877jcadhey.fsf@mid.deneb.enyo.de> * John C. Klensin: >> You would use +12345678901234 at e164.arpa, I guess, where the >> @e164.arpa part could be supplied by the MUA. (Of course, >> e164.arpa should have a "MX ." RR.) > > There are two ways (at least that I can think of) to implement > that suggestion... > > * With one, the MTA would somehow look at that string > and rewrite it into > 4.3.2.1.0.9.8.7.6.5.4.3.2.1.e164.arpa. If any > intermediate did that, it would really push the limits > on the principle that intermediate MTAs not try to > interpret or rewrite local-parts. This is just another form of forwarding, with a DNS-based alias database. I don't see a real conceptual problem with this approach. You can even keep the e164.arpa address across the network, although this might cause hassles for MTAs which are traditionally weak on local-part-based routing (I'm not sure if there are many of those left, though). > * With the other, the mail would actually be delivered > to the MTA for e164.arpa (that would be the effect of > the wildcard MX I think you are suggesting). No, the effect of "MX ." is that mail bounces immediately. > In thinking about this, you should be aware of something else if > you are not: although +12345678901234 at e164.arpa is a perfectly > valid email address under the rules of RFC 2821 and 2822, a huge > number of web sites and web-based mail systems will treat it as > invalid. Sure, you can't get full interoperability with an address that contains a "+" in the local-part, or a domain under the ARPA TLD. But even fewer sites will accept a plain "+12345678901234". If MUAs create the impression that phone numbers behave like email addresses, people will expect that they can be substituted for email addresses in other places as well. If the major MTA vendors adopt ENUM routing via e164.arpa in their default configurations, we have at least some chance that a lot of applications will do the right thing more or less by accident. That's why the local MTA on UNIX systems, the one behind /usr/sbin/sendmail, will implement ENUM routing, and not each mail client individually. From that, it's just a small step to support ENUM routing over Submission as well. Another thing worth considering: client-side NAPTR processing interferes badly with mobile hosts which are temporarily located on networks where the assigned DNS resolver does not support NAPTR records (and just returns SERVFAIL, for example). I expect such networks to be quite common for quite some time. > But expecting MTAs to start rewriting addresses that have some > particular set of syntax characteristics strikes me and being well > within the range of breaking things that are legitimate uses today. The introduction of the LOCAL TLD is well within that territory of breakage, and it was considered acceptable by the IETF. Yet another special case wouldn't be *that* different. From fw at deneb.enyo.de Tue Oct 18 17:08:50 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 18 Oct 2005 17:08:50 +0200 Subject: [enum-wg] ENUM-capable email client? In-Reply-To: <20051017174317.GB2157@denics7.denic.de> (Peter Koch's message of "Mon, 17 Oct 2005 19:43:17 +0200") References: <434671EA.1050105@schiefner.de> <87k6gcxpfj.fsf@mid.deneb.enyo.de> <87ach8ukg2.fsf@mid.deneb.enyo.de> <20051017174317.GB2157@denics7.denic.de> Message-ID: <87r7aic16l.fsf@mid.deneb.enyo.de> * Peter Koch: > It should not. Last news about the necessary A RR for "." came from a parallel > universe and draft-delany-nullmx-00.txt just misses the operational > consequences. Using the "@e164.arpa" part to deviate from the standard mail > routing algorithm won't fly. What about reusing the TPC.INT approach? (AFAIK, RegTP forbids adding MX records under 9.4.e164.arpa, but this impossible to enforce, of course. 8-) From john-ietf at jck.com Tue Oct 18 19:29:20 2005 From: john-ietf at jck.com (John C Klensin) Date: Tue, 18 Oct 2005 13:29:20 -0400 Subject: [enum-wg] ENUM-capable email client? In-Reply-To: <877jcadhey.fsf@mid.deneb.enyo.de> References: <434671EA.1050105@schiefner.de> <87k6gcxpfj.fsf@mid.deneb.enyo.de> <87ach8ukg2.fsf@mid.deneb.enyo.de> <877jcadhey.fsf@mid.deneb.enyo.de> Message-ID: <8988D32ED5F0A02490440AE7@scan.jck.com> --On Tuesday, 18 October, 2005 16:32 +0200 Florian Weimer wrote: >... >> There are two ways (at least that I can think of) to implement >> that suggestion... >> >> * With one, the MTA would somehow look at that string >> and rewrite it into >> 4.3.2.1.0.9.8.7.6.5.4.3.2.1.e164.arpa. If any >> intermediate did that, it would really push the limits >> on the principle that intermediate MTAs not try to >> interpret or rewrite local-parts. > > This is just another form of forwarding, with a DNS-based alias > database. I don't see a real conceptual problem with this > approach. You can even keep the e164.arpa address across the > network, although this might cause hassles for MTAs which are > traditionally weak on local-part-based routing (I'm not sure > if there are many of those left, though). Florian, We seem to be misunderstanding each other, and I don't why. In particular, I don't know what you mean by "weak on local-part-based routing" since any MTA, other than a final delivery one, that does _any_ routing on the content of the local part is in clear violation of the SMTP standard. I don't know if you think an MTA is weak because it follows the standard or weak because it violates it. As far as an empty data field in an MX record is concerned, which I now understand is what you are suggesting, there is, to put it mildly, no standard way to interpret one of those. SMTP considers them invalid as, I believe, do the DNS standards. There is no guarantee that an address that resolved to one would result in rejection or a bounce rather than in some very unpleasant failure behavior. john From klaus.mailinglists at pernau.at Thu Oct 20 14:20:45 2005 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Thu, 20 Oct 2005 14:20:45 +0200 Subject: [enum-wg] ENUM-capable email client? In-Reply-To: <87k6gcxpfj.fsf@mid.deneb.enyo.de> References: <434671EA.1050105@schiefner.de> <87k6gcxpfj.fsf@mid.deneb.enyo.de> Message-ID: <43578B9D.8000808@pernau.at> Florian Weimer wrote: > * Carsten Schiefner: > > >>My question is: is anyone aware of a similar extension or even built-in >>function of a mail client, so that an E.164 number would be resolved to >>an email address? > > > Shouldn't this be part of the MTA, and not the MUA? After all, it's > some kind of mail routing. IMO the ENUM lookup should be done in the client before sending the Email to the MTA. Because if there is no email address asscoiated with the E.164 phone number, the client can show the problem to the user immediately, wheras the the MTA would have to generate an error message. regards klaus From alexander.mayrhofer at enum.at Thu Oct 20 14:25:37 2005 From: alexander.mayrhofer at enum.at (Alexander Mayrhofer) Date: Thu, 20 Oct 2005 14:25:37 +0200 Subject: [enum-wg] ENUM-capable email client? In-Reply-To: <43578B9D.8000808@pernau.at> References: <434671EA.1050105@schiefner.de> <87k6gcxpfj.fsf@mid.deneb.enyo.de> <43578B9D.8000808@pernau.at> Message-ID: <43578CC1.5070603@enum.at> Klaus Darilion wrote: > Florian Weimer wrote: >> * Carsten Schiefner: >> >> >>> My question is: is anyone aware of a similar extension or even >>> built-in function of a mail client, so that an E.164 number would be >>> resolved to an email address? >> >> >> Shouldn't this be part of the MTA, and not the MUA? After all, it's >> some kind of mail routing. > > IMO the ENUM lookup should be done in the client before sending the > Email to the MTA. Because if there is no email address asscoiated with > the E.164 phone number, the client can show the problem to the user > immediately, wheras the the MTA would have to generate an error message. oh - another point for the "User experience" section in an Enumservice definition... cheers alex From fengw at cnnic.cn Fri Oct 21 07:32:58 2005 From: fengw at cnnic.cn (Wang Feng) Date: Fri, 21 Oct 2005 13:32:58 +0800 Subject: [enum-wg] ENUM-capable email client? Message-ID: <329872735.10496@cnnic.cn> An E.164 number may can considered as an identifier of some person, different applications can get corresponding address information by ENUM resolving. I also think that for MUA it should firstly turn an E.164 number into an appointed Email address, which is convenient to access destined person and also can be flexible to change when needed, not ENUM as a new fixed Email address like +861062619750 at e164.arpa. Wang Feng fengw at cnnic.cn ======= 2005-10-20 14:20:00 ======= >Florian Weimer wrote: >> * Carsten Schiefner: >> >> >>>My question is: is anyone aware of a similar extension or even built-in >>>function of a mail client, so that an E.164 number would be resolved to >>>an email address? >> >> >> Shouldn't this be part of the MTA, and not the MUA? After all, it's >> some kind of mail routing. > >IMO the ENUM lookup should be done in the client before sending the >Email to the MTA. Because if there is no email address asscoiated with >the E.164 phone number, the client can show the problem to the user >immediately, wheras the the MTA would have to generate an error message. > >regards >klaus >