Re: [Enum] ENUM Query

Brian Rosen <br@brianrosen.net> Fri, 13 March 2020 12:09 UTC

Return-Path: <br@brianrosen.net>
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 829503A16C4 for <enum@ietfa.amsl.com>; Fri, 13 Mar 2020 05:09:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com
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 dl9Nr5c6iHNk for <enum@ietfa.amsl.com>; Fri, 13 Mar 2020 05:09:30 -0700 (PDT)
Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (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 6B9A53A16C0 for <enum@ietf.org>; Fri, 13 Mar 2020 05:09:30 -0700 (PDT)
Received: by mail-qv1-xf34.google.com with SMTP id p60so4400334qva.5 for <enum@ietf.org>; Fri, 13 Mar 2020 05:09:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=az9UrpMv42sd8fIKln/a5WJuacjGEiCs3tWAQ5h5N28=; b=XWkcMRJlLHadYPuQwkF8Sug1mNjCqIEx3uSwmApurVQDIZeTqAI2XB1sVWRg1E5uyY 1RpYd66Cg0ciO4Rd/lGVk8HTJuVK2id7o2rv3ZjKrd2JKCz18uRvKRkCAntO4o641YGn Wgdd1h3v1Lkug0XQq25JqvysGKTZV6f2DxxX6WMNaNuXqmcmbwAI2xGBjrapsl4eigeC IyvQ4VrLj/P7b1dWvs5ppwyNT6oZr24U3LWnbR1ZrzP9YIVqgjw9lFw8B3SKPsSOrPP8 y/TRxCd8Sfgj0cxxMgfEecxKB6tN4jhlZR/O16F9elUlxiJ1IXZ5qSXOtX5rUPx6nPe9 97sg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=az9UrpMv42sd8fIKln/a5WJuacjGEiCs3tWAQ5h5N28=; b=UD/gZsLfUiJ4XJRlKyd7QS+wPT38b2KZMMd3Gc/pFAYMAngh8JsEF3ELaM2lMMjJ/c 9P+qLV6ZvM6xL+QFgl9sELYXRWVYZ4/RRT8+CeFsNn/93uDHD5Ip4UC0MjEEH0Yvz4H7 cstTESmxMkcJ4+YrmgNv+5fCPe31p49lSsPg0oV18HksNK8zjm6XFsEEWW8QZSr0sAgs QtLHHW/Ysgb9r9z0ykBuGMhMbRe7VlWySK5pEnwH9UEzaNCOfnwoEA3k6Ocf+YcJujY+ gsIHrkWXHj+wYcOtLEKw7SFOEjdlwRkxdr1jBrHDJprllWhU4ED+UJ+YEY7rpj7WAu5n dPcg==
X-Gm-Message-State: ANhLgQ1relhT5lR4ZbOg9kQcGc6zW4NU66bCek3rp5vNdETHkt3yxkSw Ux4A9JTcdVGCZEl6JcwGNvOCqWMg9TFJ0ylPMhVIBeJA
X-Google-Smtp-Source: =?utf-8?q?ADFU+vtxgE+GlRwTCqxjM5Ada8J9wbsm32XTLHBTfudN?= =?utf-8?q?hKd/qgRFdzSAaDbNy0EvCHAGSzrZoUUt/ECNlwH8sI/QLLo=3D?=
X-Received: by 2002:a0c:f788:: with SMTP id s8mr554862qvn.236.1584101369253; Fri, 13 Mar 2020 05:09:29 -0700 (PDT)
MIME-Version: 1.0
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?=
In-Reply-To: =?utf-8?q?=3CDB7PR04MB5418B9E732C770A3BC0788FBC3FA0=40DB7PR04MB?= =?utf-8?q?5418=2Eeurprd04=2Eprod=2Eoutlook=2Ecom=3E?=
From: Brian Rosen <br@brianrosen.net>
Date: Fri, 13 Mar 2020 08:09:18 -0400
Message-ID: <CAOPrzE14Sabbc3TEBm6n2ApPkQPTU2NyVkszuDCcGQzNPE4uYg@mail.gmail.com>
To: Wayne Cutler <wcutler@gsma.com>
Cc: Bernie Hoeneisen <bernie@ietf.hoeneisen.ch>, "enum@ietf.org" <enum@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000067203205a0bb57d7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/enum/nr7x-mq8n9I3G9XzgUIFAOgv76c>
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 12:09:35 -0000

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