Subject: [Enum] Comments about draft-brandner-enumservice-msg-00.txt

From: [email-masked]
Date: Fri, 14 Mar 2003 12:09:00 +0200

Hi,

I have some comments regarding the I-D
draft-brandner-enumservice-msg-00.txt.

In sections 5.2 and 5.3 the services "SMS" and "EMS" are proposed to
be registered.

EMS uses the same infrastructure and bearer as SMS -- In fact EMS in
practise just means that some additional content has been standardised
to be carried over the SMS bearer besides plain text or unspecified
binary data.

However, the problem is that EMS was extended with new functionality
over a period of time with several releases of the specification
released by 3GPP. A terminal supporting the 3GPP REL-99 version of
TS23.040 (Technical Specification that defines both SMS and the
additional EMS content) is not able to show or render new types of
content defined in 3GPP REL-5 version of TS23.040. Also, the EMS
additions have been defined in such a way that one can do cherry
picking -- only choose to implement certain features.

Based on this I don't see much use to have the separate service "ems"
defined. Your only safe bet is that the recipient supports SMS.

For a "fascinating" reading exercise, the latest version of TS23.040
can be found from
http://www.3gpp.org/ftp/Specs/latest/Rel-5/23_series/23040-551.zip

I went through last year's mail archives and couldn't find any
discussion about adding EMS as a service type, but I apologize if this
opens up an old, buried thread.

Another comment I have is about the sentence

   Note that an indication of MMS can be taken as implying that the
   recipient is capable of receiving EMS or SMS messages at this
   address.

in 5.4. I don't think this statement is necessarily true. What should
be said here is that MMS can be used as an alternative to deliver an
SMS RP-DATA RPDU if for example the SMS bearer is not supported.
While in practise all terminals supporting MMS today support SMS as well,
it might not necessarily be the case in the future.

[from TS23.140, MMS Stage 2, version 5.5.0:

5.1.2.1 Interoperability with SMS

    In order to guarantee SMS interoperability, SMS 3GPP TS 24.011
[11] RP-DATA RPDU encapsulation defined in clause 7.3.1 shall be
supported. MIME type "application/vnd.3gpp.sms" shall be used for this
purpose. In order to maintain backward compatibility, MIME type
"application/x-sms" shall be supported by the MMS UA for
mobile-terminated messages only.

The spec can be found from
http://www.3gpp.org/ftp/Specs/latest/Rel-5/23_series/23140-550.zip
]

As last thing, a short comment about abbreviations: The E in EMS is
Enhanced, not Extended, "Enhanced Messaging Service", and MMS is
"Multimedia Messaging Service".

Best regards,
Ville Warsta
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Fri, 14 Mar 2003 12:00:09 +0000

Hi Ville, Folks,
   many thanks for working through the msg draft, and for
the clarifications - particularly finding the mangled EMS
and MMS definitions and pointing out the References.
Great!

I wholeheartedly agree that EMS was not as "standard" as
either SMS or MMS. To be honest, it's not something that
I expect to be important in the future. IMHO, it
does have some major inter-operability problems due to
the "cherry picking of features" that you mention. The
current discussions (in GERAN, for example) make me
wonder if R5/R6+ will ever complete and be rolled out,
but that's another story.

We included SMS to indicate a "pure" SMS compliant service
only must be expected at this end point (i.e. DON'T try
to use EMS), and added EMS as an option for people whose
system claims to support it and want to try it. The EMS
service tag is only because EMS exists "out there" now.
I must say that some features of EMS are quite commonly
implemented, and it is these where we expected it to be
used - extended texts, for example.

As you hint, some companies make a bigger "push" on EMS
than others. I would leave it in through politeness; their
customers are more likely to specify this as Registrants
than any others (and it is their customers who are more
likely to be interested in trying this as end users :).

As for MMS not being guaranteed to support EMS or SMS in
the future... well, yes, that's strictly true, but do you
really believe that the MMS systems and 3G R5 and beyond
phones will not support SMS in the short term or even the
medium term; there is a demand for this and I'd be amazed
if a phone didn't - certainly yours does, as does ours ;).
In the longer term the only reason for lack of SMS or EMS
support is that it is no longer used, and everyone has
swapped over to using an MMS capable 'phone. I hope this
happens sooner rather than later, if only for the IMS
support.

We will be happy to add your text in the next version;
you have spelled out exactly what is going on in better
terms than I could have done, for which many thanks.

all the best,
   Lawrence

-- 
-----------------------------------------------------------------------
Roke Manor Research    : This information is provided "as is" and is not
<mailto:[email-masked]>: intended to create any contractual or legal
<tel:+441794833666>    : relationship.
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum