Re: [Enum] ENUM Query

Bernie Hoeneisen <> Mon, 09 March 2020 14:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0333E3A1148 for <>; Mon, 9 Mar 2020 07:49:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6T9kRVLAELGz for <>; Mon, 9 Mar 2020 07:49:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 03C493A1158 for <>; Mon, 9 Mar 2020 07:49:51 -0700 (PDT)
Received: from localhost ([]) by with esmtp (Exim 4.86_2) (envelope-from <>) id 1jBJj2-0006eL-JU; Mon, 09 Mar 2020 15:49:48 +0100
Date: Mon, 9 Mar 2020 15:49:48 +0100 (CET)
From: Bernie Hoeneisen <>
To: Wayne Cutler <>
cc: "" <>
In-Reply-To: =?utf-8?q?=3CDB7PR04MB5418E392AD73AF330044E0F2C3FE0=40DB7PR04MB?= =?utf-8?q?5418=2Eeurprd04=2Eprod=2Eoutlook=2Ecom=3E?=
Message-ID: <>
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?=
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
Subject: Re: [Enum] ENUM Query
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Enum Discussion List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 09 Mar 2020 14:49:58 -0000

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

> 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
     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?