Re: [Enum] ENUM Query

[Brian Rosen <[e-mail]>]

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]> 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:[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
>
> .
>