Re: [Enum] ENUM Query

[Wayne Cutler <[e-mail]>]

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

Regards,
Wayne

From: Brian Rosen [mailto:[e-mail]]
Sent: 13 March 2020 12:09
To: Wayne Cutler <[e-mail]>
Cc: Bernie Hoeneisen <[e-mail]>; [e-mail]
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 <[e-mail]<mailto:[e-mail]>> 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:[e-mail]<mailto:[e-mail]>]
Sent: 09 March 2020 15:50
To: Bernie Hoeneisen <[e-mail]<mailto:[e-mail]>>
Cc: Wayne Cutler <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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&amp;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&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
> [e-mail]<mailto:[e-mail]>
> 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&amp;data=02%7C01%7Cwcutler%40gsma
> .com%7C7d31d0b4992a4b0afafe08d7c4419250%7C72a4ff82fec3469daafbac827621
> 6699%7C0%7C0%7C637193658237974160&amp;sdata=epNTFgp51vkSOeKW0PjJWVyHv9
> wbuvpbvHzllK1C%2B4M%3D&amp;reserved=0

.

.