Re: [Enum] ENUM Query

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://tools.ietf.org/html/rfc6117#section-6
> 
>> 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://www.ietf.org/mailman/listinfo/enum