Re: [Enum] ENUM Query

Bernie Hoeneisen <bernie@ietf.hoeneisen.ch> Fri, 13 March 2020 13:51 UTC

Return-Path: <bernie@ietf.hoeneisen.ch>
X-Original-To: enum@ietfa.amsl.com
Delivered-To: enum@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 152B23A07EE for <enum@ietfa.amsl.com>; Fri, 13 Mar 2020 06:51:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjWdOq5Z2O2V for <enum@ietfa.amsl.com>; Fri, 13 Mar 2020 06:51:40 -0700 (PDT)
Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C8163A081B for <enum@ietf.org>; Fri, 13 Mar 2020 06:51:39 -0700 (PDT)
Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.86_2) (envelope-from <bernie@ietf.hoeneisen.ch>) id 1jCkit-0005C8-Gp; Fri, 13 Mar 2020 14:51:35 +0100
Date: Fri, 13 Mar 2020 14:51:35 +0100 (CET)
From: Bernie Hoeneisen <bernie@ietf.hoeneisen.ch>
X-X-Sender: bhoeneis@softronics.hoeneisen.ch
To: Brian Rosen <br@brianrosen.net>
cc: Wayne Cutler <wcutler@gsma.com>, "enum@ietf.org" <enum@ietf.org>
In-Reply-To: <CAOPrzE14Sabbc3TEBm6n2ApPkQPTU2NyVkszuDCcGQzNPE4uYg@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.2003131448390.19532@softronics.hoeneisen.ch>
References: =?utf-8?q?=3CDB7PR04MB54183341C4145762B969A0B1C3E40=40DB7PR04MB5?= =?utf-8?q?418=2Eeurprd04=2Eprod=2Eoutlook=2Ecom=3E?= =?utf-8?q?=3CADFB7C13-0783-46A8-B9C9-86D503FF87B9=40brianrosen=2Enet=3E_=3C?= =?utf-8?q?DB7PR04MB5418DCD96342D69A51AFDF3AC3E50=40DB7PR04MB5418=2Eeurprd04?= =?utf-8?q?=2Eprod=2Eoutlook=2Ecom=3E?= =?utf-8?q?=3Calpine=2EDEB=2E2=2E20=2E2003041130480=2E19506=40softronics=2Eh?= =?utf-8?q?oeneisen=2Ech=3E_=3CDB7PR04MB54186234B94264FEA913888EC3E50=40DB7P?= =?utf-8?q?R04MB5418=2Eeurprd04=2Eprod=2Eoutlook=2Ecom=3E?= =?utf-8?q?=3Calpine=2EDEB=2E2=2E20=2E2003071103230=2E19506=40softronics=2Eh?= =?utf-8?q?oeneisen=2Ech=3E_=3CDB7PR04MB5418E392AD73AF330044E0F2C3FE0=40DB7P?= =?utf-8?q?R04MB5418=2Eeurprd04=2Eprod=2Eoutlook=2Ecom=3E?= <alpine.DEB.2.20.2003091520500.23510@softronics.hoeneisen.ch> =?utf-8?q?=3CA7704953-E79C-4835-9AE1-A97A567E37FC=40brianrosen=2Enet=3E_=3C?= =?utf-8?q?DB7PR04MB5418B9E732C770A3BC0788FBC3FA0=40DB7PR04MB5418=2Eeurprd04?= =?utf-8?q?=2Eprod=2Eoutlook=2Ecom=3E?= <CAOPrzE14Sabbc3TEBm6n2ApPkQPTU2NyVkszuDCcGQzNPE4uYg@mail.gmail.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="37663318-217761771-1584107495=:19532"
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch
X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/enum/PWAwPRdD63r4gkqbjGqjDc9mLvQ>
Subject: Re: [Enum] ENUM Query
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/enum>, <mailto:enum-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/enum/>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/enum>, <mailto:enum-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Mar 2020 13:51:49 -0000

Wayne,

independent stream is also an option. But as Brian said, just make an 
Internet-Draft and I will help you to sort out the RFC-stream later. You 
may want to (re-)read the relevant section in RFC 6117 on the process, 
where all this stuff is specified.

cheers,
  Bernie


--

http://ucom.ch/
Modern Telephony Solutions and Tech Consulting for Internet Technology


On Fri, 13 Mar 2020, Brian Rosen wrote:

> The registry is “specification required” which allows an Informational. I would avoid discussing the root. You don’t need to do that.
> Just describe the problem and create the new enumservices. 
> 
> Since the work group doesn’t exist anymore, you need an AD to sponsor it.
> 
> Brian
> 
> On Fri, Mar 13, 2020 at 7:54 AM Wayne Cutler <wcutler@gsma.com> wrote:
>       Thanks Brian & Bernie for your feedback.
>
>       I can see that adding mmtel.sip does compliment rcs.sip and is unambiguous in the service set provided by such a result.
>
>       The current sip enumservice is currently used for MMTEL and both MMTEL & RCS. In the former case, a number of those MNOs
>       haven't launched RCS - and therefore the sip enumservice means "all SIP-based services" or unified communications. So, I
>       don't think we would deprecate the use of the sip enumservice - but could consider introducing the mmtel.sip service for
>       "MMTEL only". I will consult with parties internally and see what the consensus is.
>
>       As I've said previously, it is intended to use the new ENUM result(s) in the so-called "Carrier ENUM" - a private ENUM
>       infrastructure for the telecommunications industry which uses the top level domain of "e164enum.net" as opposed to
>       "e164.arpa". Given that this is a private infrastructure, using a different top level domain,  would this new ENUM service
>       be appropriate for a standards track or informational RFC and would it be permitted for the related internet draft to refer
>       to the private "e164enum.net" top level domain ?
>
>       Best Regards,
>       Wayne
>
>       -----Original Message-----
>       From: Brian Rosen [mailto:br@brianrosen.net]
>       Sent: 09 March 2020 15:50
>       To: Bernie Hoeneisen <bernie@ietf.hoeneisen.ch>
>       Cc: Wayne Cutler <wcutler@gsma.com>om>; enum@ietf.org
>       Subject: Re: [Enum] ENUM Query
>
>       “This email has been received from an external source – please review before actioning, clicking on links, or opening
>       attachments”
> 
>
>       I think adding new enumservices for both rcs and mmtel is a good way forward.
>
>       While we could eventually not see anyone using the sip enumservice for messaging, it is, and will be widely used for voice
>       calls.
>
>       Brian
>
>       > On Mar 9, 2020, at 10:49 AM, Bernie Hoeneisen <bernie@ietf.hoeneisen.ch> wrote:
>       >
>       > Hi Wayne
>       >
>       > My comments inline.
>       >
>       > On Mon, 9 Mar 2020, Wayne Cutler wrote:
>       >
>       >> So, we are after a mechanism to get a SIP URI for the RCS Messaging Services, and these services comprise things like 1:1
>       Chat, File Transfer, Geolocation Push etc.
>       >>
>       >> Regarding the differences between RCS Messaging and im/unifmsg, I
>       >> would say that :-
>       >> 1) im allows users to send and receive typically short, often textual messages in near real-time - which sounds a lot
>       like RCS Chat - and returns an IM URI. So, I think that RCS is more general than im and also the need to translate from the
>       im URI to a SIP URI is an additional minor nuisance.
>       >
>       >> 2) unifmsg is about having a unified (voice/video) mailbox capability in the event of a user being unreachable. The RCS
>       services aren't really about the user being unreachable and so this is not really a good fit IMO.
>       >
>       > Thanks for clarification.
>       >
>       >> So, I think the proposal to have a new Application-Based Enumservice seems reasonable to me. What would be the next
>       steps? Writing an Internet Draft presumably?
>       >
>       > RFC 6117 defines the process in details cf.
>       > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftool
>       > s.ietf.org%2Fhtml%2Frfc6117%23section-6&amp;data=02%7C01%7Cwcutler%40g
>       > sma.com%7C7d31d0b4992a4b0afafe08d7c4419250%7C72a4ff82fec3469daafbac827
>       > 6216699%7C0%7C0%7C637193658237974160&amp;sdata=ZhNt08ISuQHn%2FYRJUWBFo
>       > HvmKS7MPI%2FI3SyUG9HWxY8%3D&amp;reserved=0
>       >
>       >> Regarding the suggestion to also take a similar approach for MMTEL, I think there are backwards compatibility issues as
>       there are implementations already out there that use the Protocol-Based Enumservice "sip" for MMTEL. Therefore, this is
>       something we wouldn't want to do.
>       >
>       > Not sure this creates a new backward compatibility issue. AFAICT, using two new Enumservices, new systems would be more
>       efficient and less prone to ambiguities. And in the long run you'd get a clean system.
>       >
>       > - for old systems you probably need to maintain "sip" (only)
>       > (provision and lookup). You may add a recommendation to at  least
>       > provision also the new Enumservices "mmtel:sip" and "rcs:sip"
>       >  (pointing to the same as "sip"), which is easy to implement.
>       >
>       > - for new systems you could specify:
>       >
>       >  - Lookup: use "rcs:sip" or "mmtel:sip" (with priority);
>       >    use "sip", only if no hit with rcs or mmtel (fallback)
>       >
>       >  - Provision: "rcs:sip" and "mmtel:sip" would point to the respecive
>       >    services,
>       >    while "sip" could be provisioned to help old systems to find the
>       >    correct service, e.g. a redirection service (or alike) or a system
>       >    that can deal with requests for the "wrong" (mmtel vs. rcs) service.
>       >
>       > You could deprecate "sip" Enumservice and after a long enough transition period, you may get rid of the "sip" Enumservice
>       altogether.
>       >
>       > Does this make sense for your environment?
>       >
>       > cheers
>       > Bernie
>       >
>       > _______________________________________________
>       > enum mailing list
>       > enum@ietf.org
>       > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
>       > ietf.org%2Fmailman%2Flistinfo%2Fenum&amp;data=02%7C01%7Cwcutler%40gsma
>       > .com%7C7d31d0b4992a4b0afafe08d7c4419250%7C72a4ff82fec3469daafbac827621
>       > 6699%7C0%7C0%7C637193658237974160&amp;sdata=epNTFgp51vkSOeKW0PjJWVyHv9
>       > wbuvpbvHzllK1C%2B4M%3D&amp;reserved=0
>
>       .
> 
> 
>