Re: [Enum] ENUM Query
Brian Rosen <br@brianrosen.net> Fri, 13 March 2020 16:01 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 85C903A0D9A for <enum@ietfa.amsl.com>; Fri, 13 Mar 2020 09:01:05 -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, 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 O56LXp09P3TF for <enum@ietfa.amsl.com>; Fri, 13 Mar 2020 09:01:00 -0700 (PDT)
Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 8F2A73A0D99 for <enum@ietf.org>; Fri, 13 Mar 2020 09:00:59 -0700 (PDT)
Received: by mail-qk1-x72b.google.com with SMTP id f28so13293207qkk.13 for <enum@ietf.org>; Fri, 13 Mar 2020 09:00:59 -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=ZI4miazjBo/MfqUWHUXWAGkSSJ4yHqBSgHSynYCrVco=; b=eCfe41+VNUxN0yE06v6wCT3lT5OIU9DzAuKHNPE/a1lOGjhkgy1W5v36Yjzq8uMwSl OekKXirRpXh7eO2Ga9YrQj0a7GcznmGevWCKSqJHPixNJUpL2+3uH/vOb48hB6i1U2JV uBTgYY8kEmzkWn8NNexoT5M61WVnbr+sWfEJC5qJBVuhMITlQZ2ydwyXtiGlpuRPaBAV GcetKHAIykin1bHnS3uzj3d0iqWkPDFih9iP2Sldi/S+ixEO2GEF2OhwsyFDuyL0tjWA G6CfgL3WxPKxf/xlbMcyL+3z4+FFQrJjK8Pwcj3I+lxIDQ7f6W8FtW5ZMN/bt8Vp7Bvt GGYA==
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=ZI4miazjBo/MfqUWHUXWAGkSSJ4yHqBSgHSynYCrVco=; b=n83WhKV3PcGrJbJdlYWZfHEL2Z0acgsi0n8QNv5Eq7di67bp0AvhiRvU0KYVfUkDxE jPY4u4/cxSOdxaWW1mKfcV5fCDXSA6JaMzvRZGNNfRwQTzgeJ1YykSpBVpCeMWLjQ7/R UdyvK+ZsdKPwtKA+t9zhCa9gZGXKNacTYaGtFNY7uK9ppuiO/2NxqJxf0JmYbufG7uu7 bDqzLSqqxd6dcAa539G9jAvFodw+/UOa5svbM6S8/vzNxbBICGtx8oRIP2VY/CunUltx xNKr3RCUAGJmNu2P/FIwgMQG+3L/vy1kn8D4P4/X4bklOeP8IQNmoRAScwDLEAneJlkZ axOQ==
X-Gm-Message-State: ANhLgQ2h9ZxfBmeETXNNYFnRf6BjjffJOlYzndE7BqGNvfAQpi7KQrUy HEBo75Pu04zws7vmMpZOhXVvC1wK00c2ButipbgPIA==
X-Google-Smtp-Source: ADFU+vtGYLUMthhe6/HalB2MNNCsNPU7K2ot1yjL2PDp+o9SLaMqNPeOQvl5H9vjIAhWwzYFt+s/rrXIwSGr0tY0W4o=
X-Received: by 2002:a37:4644:: with SMTP id t65mr12734880qka.58.1584115258391; Fri, 13 Mar 2020 09:00:58 -0700 (PDT)
MIME-Version: 1.0
References: <DB7PR04MB54183341C4145762B969A0B1C3E40@DB7PR04MB5418.eurprd04.prod.outlook.com><ADFB7C13-0783-46A8-B9C9-86D503FF87B9@brianrosen.net> <DB7PR04MB5418DCD96342D69A51AFDF3AC3E50@DB7PR04MB5418.eurprd04.prod.outlook.com><alpine.DEB.2.20.2003041130480.19506@softronics.hoeneisen.ch> <DB7PR04MB54186234B94264FEA913888EC3E50@DB7PR04MB5418.eurprd04.prod.outlook.com><alpine.DEB.2.20.2003071103230.19506@softronics.hoeneisen.ch> <DB7PR04MB5418E392AD73AF330044E0F2C3FE0@DB7PR04MB5418.eurprd04.prod.outlook.com> <alpine.DEB.2.20.2003091520500.23510@softronics.hoeneisen.ch> <A7704953-E79C-4835-9AE1-A97A567E37FC@brianrosen.net> <DB7PR04MB5418B9E732C770A3BC0788FBC3FA0@DB7PR04MB5418.eurprd04.prod.outlook.com><CAOPrzE14Sabbc3TEBm6n2ApPkQPTU2NyVkszuDCcGQzNPE4uYg@mail.gmail.com> <DB7PR04MB541844CC8809562BC5EB407AC3FA0@DB7PR04MB5418.eurprd04.prod.outlook.com> <CAOPrzE3zxuM3Ltfpr9Q_VhOKbLFVXRvtZgexG104Yw+Ed-BGHA@mail.gmail.com> <FD701EE7-989E-4478-A579-42FA40627AF4@shockey.us>
In-Reply-To: <FD701EE7-989E-4478-A579-42FA40627AF4@shockey.us>
From: Brian Rosen <br@brianrosen.net>
Date: Fri, 13 Mar 2020 12:00:47 -0400
Message-ID: <CAOPrzE1OehHB3aG4OQ2ShdYqztOQ5LCuNLOKKfHuRL=4u10gcA@mail.gmail.com>
To: Richard Shockey <richard@shockey.us>
Cc: Bernie Hoeneisen <bernie@ietf.hoeneisen.ch>, Wayne Cutler <wcutler@gsma.com>, "enum@ietf.org" <enum@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004292c205a0be930a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/enum/XiTkoRmS7yLFjZ0guEcplFsFk3Q>
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 16:01:06 -0000
Opinions differ :) I think we want the full review that AD sponsored gets. Independent stream just gets the “We don’t object” review. In this case I think we want the full review. On Fri, Mar 13, 2020 at 11:47 AM Richard Shockey <richard@shockey.us> wrote: > > > 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 > > www.shockey.us > > www.sipforum.org > > richard<at>shockey.us > > Skype-Linkedin-Facebook –Twitter rshockey101 > > PSTN +1 703-593-2683 > > > > > > *From: *enum <enum-bounces@ietf.org> on behalf of Brian Rosen < > br@brianrosen.net> > *Date: *Friday, March 13, 2020 at 10:14 AM > *To: *Wayne Cutler <wcutler@gsma.com> > *Cc: *"enum@ietf.org" <enum@ietf.org>, Bernie Hoeneisen < > bernie@ietf.hoeneisen.ch> > *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. > > > > Brian > > > > On Fri, Mar 13, 2020 at 10:10 AM Wayne Cutler <wcutler@gsma.com> wrote: > > Thanks for the response Brian. Is there a set procedure to get “an AD to > sponsor”? > > > > Regards, > > Wayne > > > > *From:* Brian Rosen [mailto:br@brianrosen.net] > *Sent:* 13 March 2020 12:09 > *To:* Wayne Cutler <wcutler@gsma.com> > > *Cc:* Bernie Hoeneisen <bernie@ietf.hoeneisen.ch>; 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” > > > > 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 > <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fe164enum.net%2F&data=02%7C01%7Cwcutler%40gsma.com%7C7679979c3c524581f83808d7c74762a7%7C72a4ff82fec3469daafbac8276216699%7C0%7C0%7C637196981754209838&sdata=kmAMbfvW8%2FRljQKrhZX%2F7kTp%2BOhtEI1eq4iK1N6DLB0%3D&reserved=0>" > 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 > <https://eur03.safelinks.protection.outlook..com/?url=http%3A%2F%2Fe164enum.net%2F&data=02%7C01%7Cwcutler%40gsma.com%7C7679979c3c524581f83808d7c74762a7%7C72a4ff82fec3469daafbac8276216699%7C0%7C0%7C637196981754219831&sdata=bimoboKOVoAtahauG%2FeIwNqVtiJES9AGX6vpd%2FlmJ8c%3D&reserved=0>" > 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>; 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 > <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fs.ietf.org%2F&data=02%7C01%7Cwcutler%40gsma.com%7C7679979c3c524581f83808d7c74762a7%7C72a4ff82fec3469daafbac8276216699%7C0%7C0%7C637196981754219831&sdata=iiJOlm7JcSniW3Ix4XOwgOzm1cYxvnXUg%2BD5%2BZB0N%2BA%3D&reserved=0> > %2Fhtml%2Frfc6117%23section-6&data=02%7C01%7Cwcutler%40g > > sma.com > <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsma.com%2F&data=02%7C01%7Cwcutler%40gsma.com%7C7679979c3c524581f83808d7c74762a7%7C72a4ff82fec3469daafbac8276216699%7C0%7C0%7C637196981754229827&sdata=qGupiox%2FXWxRi2ncOsKcBa9%2BWeYxlaL%2F2okiMV9hJs0%3D&reserved=0> > %7C7d31d0b4992a4b0afafe08d7c4419250%7C72a4ff82fec3469daafbac827 > > 6216699%7C0%7C0%7C637193658237974160&sdata=ZhNt08ISuQHn%2FYRJUWBFo > > HvmKS7MPI%2FI3SyUG9HWxY8%3D&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 > <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.org%2F&data=02%7C01%7Cwcutler%40gsma.com%7C7679979c3c524581f83808d7c74762a7%7C72a4ff82fec3469daafbac8276216699%7C0%7C0%7C637196981754229827&sdata=wY4Pt4dFpeKD2Spq3p1UB47gdXpHcDJ2GX1kp%2BWGo2Q%3D&reserved=0> > %2Fmailman%2Flistinfo%2Fenum&data=02%7C01%7Cwcutler%40gsma > > .com%7C7d31d0b4992a4b0afafe08d7c4419250%7C72a4ff82fec3469daafbac827621 > > 6699%7C0%7C0%7C637193658237974160&sdata=epNTFgp51vkSOeKW0PjJWVyHv9 > > wbuvpbvHzllK1C%2B4M%3D&reserved=0 > > .. > > . > > _______________________________________________ enum mailing list > enum@ietf.org https://www.ietf.org/mailman/listinfo/enum >
- [Enum] ENUM Query Wayne Cutler
- Re: [Enum] ENUM Query Brian Rosen
- Re: [Enum] ENUM Query Wayne Cutler
- Re: [Enum] ENUM Query Bernie Hoeneisen
- Re: [Enum] ENUM Query Wayne Cutler
- Re: [Enum] ENUM Query Bernie Hoeneisen
- Re: [Enum] ENUM Query Wayne Cutler
- Re: [Enum] ENUM Query Bernie Hoeneisen
- Re: [Enum] ENUM Query Brian Rosen
- Re: [Enum] ENUM Query Wayne Cutler
- Re: [Enum] ENUM Query Brian Rosen
- Re: [Enum] ENUM Query Bernie Hoeneisen
- Re: [Enum] ENUM Query Wayne Cutler
- Re: [Enum] ENUM Query Brian Rosen
- Re: [Enum] ENUM Query Richard Shockey
- Re: [Enum] ENUM Query Brian Rosen
- Re: [Enum] ENUM Query Jim Reid
- Re: [Enum] ENUM Query Brian Rosen
- Re: [Enum] ENUM Query Bernie Hoeneisen
- Re: [Enum] ENUM Query Richard Shockey
- Re: [Enum] ENUM Query Brian Rosen