Re: [Enum] ENUM Query

[Wayne Cutler <[e-mail]>]

Hi Bernie,
Thanks for your email.

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.

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?

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.

Regards,
Wayne

-----Original Message-----
From: enum [mailto:[e-mail]] On Behalf Of Bernie Hoeneisen
Sent: 07 March 2020 10:55
To: Wayne Cutler <[e-mail]>
Cc: [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”


Hi Wayne

Thanks for your response.

I think I am getting closer to understand the challenges reagarding ENUM in IMS. (It's been a while since my last 3GPP/IMS meeting, which dates back to year 2002:ish.)

In the following a preliminery assessment of your options (incl. further
questions):

> · Enhance the current ProtocolBasedClass of SIP as defined in RFC 3764
> to add a sub-type - e.g. "SIP/MMTEL" & "SIP/RCS" - with the absence of
> a sub-type meaning "all services".

This is a no-go, as RFC 6117 does not forsee to use subtype strings other than different URI Schemes for Protocol-Based Enumservices. cf.
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc6117%23section-4.2.2.2&amp;data=02%7C01%7Cwcutler%40gsma.com%7C262c586851d74d20944d08d7c2860dfe%7C72a4ff82fec3469daafbac8276216699%7C0%7C0%7C637191753343095966&amp;sdata=J7CThb34%2FxNtzDR%2FtHv0d8Nq56HdtScQEcSf8x4CWc4%3D&amp;reserved=0

> · Re-use (or perhaps re-interpret?) an existing result (e.g.
> ApplicationBasedClass of IM or unifmsg) to mean RCS Messaging - but
> this feels like a kludge,

Questions:

- What are the differences between im (Enumservice) and RCS as used in IMS?

- What are the differences between unifmsg (Enumservice) and RCS as used in IMS?


> · Define a new ENUM registry entry to identify RCS Messaging.

Given the information I currently have/understand, this appears to be the cleanest approach, i.e.  to define a new Application-Based Enumservice:

- "rcs:sip" with URI Schemes "sip" and "sips"

or both

- "rcs:sip" with URI Scheme "sip"
- "rcs:sips" with URI Scheme "sips"

(depending on the implementation, see also:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc6117%23section-4.2.3.2&amp;data=02%7C01%7Cwcutler%40gsma.com%7C262c586851d74d20944d08d7c2860dfe%7C72a4ff82fec3469daafbac8276216699%7C0%7C0%7C637191753343095966&amp;sdata=usCYD0Ero7VeqEhJ%2B5JRW79ol5tHp754VDLnDlt8PL0%3D&amp;reserved=0 )


If we go down this road, you may also want to consider the same for MMTEL, to replace your legacy approach that uses the Protocol-Based Enumservice "sip", e.g.:

- "mmtel:sip" with URI Schemes "sip" and "sips"


Note that anything I write here is pre-liminery and MUST NOT be interpreted in any way as "decision by the Dedicated Expert for ENUM" (or alike), but rather help you to find the right direction for a possible upcoming formal IANA registration process.

cheers,
  Bernie

--

https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fucom.ch%2F&amp;data=02%7C01%7Cwcutler%40gsma.com%7C262c586851d74d20944d08d7c2860dfe%7C72a4ff82fec3469daafbac8276216699%7C0%7C0%7C637191753343095966&amp;sdata=GRQ1ZA4KkN%2BVemSIKST%2FXism9CmbbWvbwiPHTqH36hA%3D&amp;reserved=0
Modern Telephony Solutions and Tech Consulting for Internet Technology
.