Re: [Enum] ENUM Query

Richard Shockey <> Fri, 13 March 2020 15:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4F1393A0D09 for <>; Fri, 13 Mar 2020 08:47:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.118
X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (768-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xczsbvJ9COY0 for <>; Fri, 13 Mar 2020 08:47:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 697623A0D1C for <>; Fri, 13 Mar 2020 08:47:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EF6B036BD6D for <>; Fri, 13 Mar 2020 10:47:44 -0500 (CDT)
Received: from ([]) by cmsmtp with SMTP id CmXIjxGjB8vkBCmXIjpQqr; Fri, 13 Mar 2020 10:47:44 -0500
X-Authority-Reason: nr=8
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-type:Mime-version:In-Reply-To:References:Message-ID:CC: To:From:Subject:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=1KQippNjYlQO9lqo+CziK1yJ/zJEtryXBHaXcT/IbSA=; b=Y9/ldeN2HCrKnR3PnaS85FaYLG R3akIuM3qh8nHYYDv40w6FLQW7r5TUg/HSHlxt0iD3cVDdPou8frK0ULk2DgUtAxJ5FWA+Qj6Gwei 5nlxlgdonaEEympEcMO91M6eK;
Received: from ([]:49599 helo=[]) by with esmtpa (Exim 4.92) (envelope-from <>) id 1jCmXI-0013cZ-8q; Fri, 13 Mar 2020 09:47:44 -0600
User-Agent: Microsoft-MacOutlook/16.35.20030802
Date: Fri, 13 Mar 2020 11:47:42 -0400
From: Richard Shockey <>
To: Brian Rosen <>, Wayne Cutler <>
CC: "" <>, Bernie Hoeneisen <>
Message-ID: <>
Thread-Topic: [Enum] ENUM Query
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?= <> =?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?= =?utf-8?q?=3CCAOPrzE14Sabbc3TEBm6n2ApPkQPTU2NyVkszuDCcGQzNPE4uYg=40mail=2Eg?= =?utf-8?q?mail=2Ecom=3E_=3CDB7PR04MB541844CC8809562BC5EB407AC3FA0=40DB7PR04?= =?utf-8?q?MB5418=2Eeurprd04=2Eprod=2Eoutlook=2Ecom=3E?= <>
In-Reply-To: <>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3666944864_1680481825"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-BWhitelist: no
X-Source-L: No
X-Exim-ID: 1jCmXI-0013cZ-8q
X-Source-Sender: ([]) []:49599
X-Email-Count: 2
X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NTUyNy5ibHVlaG9zdC5jb20=
X-Local-Domain: yes
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: Fri, 13 Mar 2020 15:47:56 -0000


I certainly don’t have a problem with the independent stream. IMHO this is exactly what the system was designed to do.




Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum


Skype-Linkedin-Facebook –Twitter  rshockey101

PSTN +1 703-593-2683



From: enum <> on behalf of Brian Rosen <>
Date: Friday, March 13, 2020 at 10:14 AM
To: Wayne Cutler <>
Cc: "" <>rg>, Bernie Hoeneisen <>
Subject: Re: [Enum] ENUM Query


Nope, you just ask one. As a practical matter, you should probably recruit an experienced IETFer to help you through this. It will be much easier on everyone. 


I’m personally not a fan of independent stream for this. It’s squarely in the IETF area of expertise and I think we want the full IETF consensus process. 


But it’s up to you how you do it.




On Fri, Mar 13, 2020 at 10:10 AM Wayne Cutler <> wrote:

Thanks for the response Brian. Is there a set procedure to get “an AD to sponsor”?





From: Brian Rosen [] 
Sent: 13 March 2020 12:09
To: Wayne Cutler <>

Cc: Bernie Hoeneisen <>ch>;
Subject: Re: [Enum] ENUM Query


“This email has been received from an external source – please review before actioning, clicking on links, or opening attachments”


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.




On Fri, Mar 13, 2020 at 7:54 AM Wayne Cutler <> 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 "" as opposed to "". 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 "" top level domain ?

Best Regards,

-----Original Message-----
From: Brian Rosen []
Sent: 09 March 2020 15:50
To: Bernie Hoeneisen <>
Cc: Wayne Cutler <>om>;
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.


> On Mar 9, 2020, at 10:49 AM, Bernie Hoeneisen <> 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.
> 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
> .com%7C7d31d0b4992a4b0afafe08d7c4419250%7C72a4ff82fec3469daafbac827621
> 6699%7C0%7C0%7C637193658237974160&amp;sdata=epNTFgp51vkSOeKW0PjJWVyHv9
> wbuvpbvHzllK1C%2B4M%3D&amp;reserved=0



_______________________________________________ enum mailing list