Re: [Enum] ENUM Query

[Wayne Cutler <[e-mail]>]

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:[e-mail]]
Sent: 09 March 2020 15:50
To: Bernie Hoeneisen <[e-mail]>
Cc: Wayne Cutler <[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”


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]> 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
> [e-mail]
> 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

.