Subject: [Enum] MMS and SMS (was "(Non)-Progress of certain Enumservices" )

From: "Fullbrook Kim \(UK\)" <[email-masked]>
Date: Thu, 05 May 2005 11:30:43 -0400

<FONT 
size=2>Am getting confused over the status 
of these various registrations but thought it was worth clearing up what appears 
to be a mis-understanding over the relationship between MMS and SMS. For 
enumservices they should be considered as different 
services. 
<?xml:namespace prefix = o ns = 
"urn:schemas-microsoft-com:office:office" /><FONT face=Arial 
size=2> 
<FONT 
size=2>Previous emails (extracts from one 
of these below) mention MMS as a container for SMS which to me (and maybe to 
other readers as well) implies that the SMS service is a subset of MMS. <SPAN 
class=764514310-05052005>Apologies to the author(s) if this point was not 
intended but having read the emails several times feel that this is one of 
the key points being implied. The clarification is to indicate that MMS 
and SMS are completely different services. SMS is not a subset of MMS. Their 
characteristics, capabilities, protocols (internal & external), tariffs are 
all different. There may be isolated 
circumstances in which some operators use an SMS to deliver an MMS but this is 
very much an exception and does not demonstrate that SMS is a subset of 
MMS.
<FONT face=Arial 
size=2> 
<FONT 
size=2>The 3GPP references quoted<SPAN 
class=764514310-05052005> are only talking about message formats and 
addressing:
TS 23.140 
section 5.1.3.1. Not sure which version of the spec is being quoted here. The 
latest version of the Release 5 spec is V5.11.0 and the relevant section is 
5.1.2.1, not 5.1.3.1. This deals with message encapsulation and only specifies 
that MMS in certain circumstances uses an encapsulation format which is 
compatible with SMS.
TS 
23.140 section 8.3.2  This says that 
delivery of an MMS should use the same MSISDN (delivery address) as is used for 
SMS.
3GPP TS 
26.140 section 4.1 talks about text formats in SMSs and MMS.
<FONT face=Arial 
size=2> 
<FONT 
size=2><?xml:namespace prefix = st1 ns = 
"urn:schemas-microsoft-com:office:smarttags" />Kim 
Fullbrook
O2 
UK
<FONT face=Arial color=#000000 
size=2>----------------------------------
<FONT face=Arial color=#000000 
size=2>From a previous email:
<FONT face=Arial color=#000000 
size=2><snip>
<FONT face=Arial color=#000000 
size=2>(ii) re. MMS as a "container" for SMS or 
EMS.
<FONT 
face=Arial><SPAN 
style="mso-spacerun: yes">      Here's something 
that was send last October as part of the IESG 
evaluation.
<FONT 
face=Arial><SPAN 
style="mso-spacerun: yes">      I repeat it here 
on the list:
<FONT 
face=Arial>    
"We understand from 3GPP TS 23.140 that an MMS Relay Proxy WILL be able 
to handle messages holding a plain text sub-part that carries SMS text, and that 
the MMS User Agent will be able to receive and process them<SPAN 
style="mso-spacerun: yes">  (see, for example, sections 5.1.3.1 and 
8.3.2 of TS 23.140 and also section 4.1 of 3GPP TS 
26.140).
<FONT 
face=Arial>     
It is also one of the high level requirements specified in TS 22.140 
(section 4.1), where it is stated that:
<FONT 
face=Arial>     
- 'Regardless of the message type / format, MMS shall be capable of 
supporting integration of all types of messaging (e.g. fax, SMS, Multimedia , 
voicemail, e-mail etc.) in a consistent manner'.
<FONT face=Arial 
color=#000000 size=2> 
<FONT 
face=Arial>     
We contend that this means that, if an end system is capable of sending 
an MMS towards the addressed destination URI, and if this message only includes 
plain text according to the SMS specifications (and as described in 23.140 and 
26.140), the MMS system will be able to process that message. Thus MMS is a 
candidate for "upgrade" even if the end user prefers to send SMS 
only.
<FONT face=Arial 
color=#000000 size=2> 
<FONT 
face=Arial>     
There *is* a tariff issue here, in that sending an MMS may be charged 
differently from sending an SMS; however, indication of the use of MMS rather 
than SMS is an issue for the end system, not for the protocol as 
such".
<FONT face=Arial 
color=#000000 size=2> 
<FONT 
face=Arial>     
As I have stated before, there is an existence proof in that Mobile 
Operators *do* allow one to send are receive MMs with just a plain text part. 
The specifications spell out that this is a standard part of the MMS design. As 
such I have little choice but to assume that these systems follow the 
specifications rather than completely ignore them, or at least that they will be 
updated to reflect the specifications at some point if they are, as yet, 
non-compliant.
<FONT face=Arial color=#000000 
size=2><snip>
<FONT face=Arial 
color=#000000 size=2> 
<FONT face=Arial 
color=#000000 size=2> 
===================================================== 

This electronic message contains information from O2 which may be privileged or confidential. The information is intended to 

be for the use of the individual(s) or entity named above. If you are not 

the intended recipient be aware that any disclosure, copying 

distribution or use of the contents of this information is prohibited. If you 

have received this electronic message in error, please notify us 

by telephone or email (to the numbers or address above) immediately. 

=====================================================  
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: lconroy <[email-masked]>
Date: Thu, 05 May 2005 17:42:03 -0400

Hi again Kim, folks,
Re. status::
 We will be updating MSG again shortly, so look for a new version next 
week.

This is to reflect clarifications requested during IESG evaluation. It 
will
go directly to the IESG for their review and we hope will clear any 
remaining
questions. I trust that this next version will be ready to be approved, 
and then
it will be released to the RFC-Editor for publication.

The VOID draft will also be up-issued to add clarification of the 
Acronyms.

We will up-issue the Experiences draft - this has been delayed whilst I 
check
the behaviour of implementations of RegExp parsing functions - both I 
and my
eagle-eyed co-author want this to be right.

Finally, we will up-issue the VOVI draft for the group's reading (and, 
from
experience, ranting) pleasure.

To your comments::
--  This has been a LONG process, so the TS quoted in the current draft 
(and
so the section numbers within the referenced documents) may well have 
drifted.
This is an IETF standards track document, so we can only refer to 
documents
that are officially released - the latest approved version of TS 23.140 
for
Release 5 is 5.9.0, according to the 3GPP document service. Likewise, 
the
latest approved Release 5 version of TS 26.140 is 5.2.0.

Sigh...  A quick scan of TS 23.140 version 5.9.0 shows section 5.1.2.1 
and
8.4.4 to be still current, and 26.140 version 5.2.0 still covers text 
media
processing in section 4.1, but I'll check again to ensure that any 
section
references are reasonable before up-issuing the draft.
Thanks for the query.

-- The MSG draft does specify the SMS & MMS registrations as separate 
Enumservices.

-- We contend that it is possible to send an MMS containing only a 
plain text
part. That's ALL we contend.

As mentioned, a new version will be issued shortly (after I've 
re-checked the
latest published versions of the referenced TSes, and added reference 
to the
associated Lemonade MMS mapping draft which is also going through IESG 
Review).

all the best,
  Lawrence

On 5 May 2005, at 16:30, Fullbrook Kim (UK) wrote:
Am getting confused over the status of these various registrations but
thought it was worth clearing up what appears to be a mis-understanding
over the relationship between MMS and SMS. For enumservices they should
be considered as different services.

Previous emails (extracts from one of these below) mention MMS as a
container for SMS which to me (and maybe to other readers as well)
implies that the SMS service is a subset of MMS. Apologies to the
author(s) if this point was not intended but having read the emails
several times feel that this is one of the key points being implied. 
The
clarification is to indicate that MMS and SMS are completely different
services. SMS is not a subset of MMS. Their characteristics,
capabilities, protocols (internal & external), tariffs are all
different. There may be isolated circumstances in which some operators
use an SMS to deliver an MMS but this is very much an exception and 
does
not demonstrate that SMS is a subset of MMS.

The 3GPP references quoted are only talking about message formats and
addressing:
TS 23.140 section 5.1.3.1. Not sure which version of the spec is being
quoted here. The latest version of the Release 5 spec is V5.11.0 and 
the
relevant section is 5.1.2.1, not 5.1.3.1. This deals with message
encapsulation and only specifies that MMS in certain circumstances uses
an encapsulation format which is compatible with SMS.

TS 23.140 section 8.3.2  This says that delivery of an MMS should use
the same MSISDN (delivery address) as is used for SMS.
3GPP TS 26.140 section 4.1 talks about text formats in SMSs and MMS.

Kim Fullbrook
O2 UK
----------------------------------
From a previous email:
<snip>
(ii) re. MMS as a "container" for SMS or EMS.
      Here's something that was send last October as part of the IESG
evaluation.
      I repeat it here on the list:
    "We understand from 3GPP TS 23.140 that an MMS Relay Proxy WILL be
able to handle messages holding a plain text sub-part that carries SMS
text, and that the MMS User Agent will be able to receive and process
them  (see, for example, sections 5.1.3.1 and 8.3.2 of TS 23.140 and
also section 4.1 of 3GPP TS 26.140).
     It is also one of the high level requirements specified in TS
22.140 (section 4.1), where it is stated that:
     - 'Regardless of the message type / format, MMS shall be capable 
of
supporting integration of all types of messaging (e.g. fax, SMS,
Multimedia , voicemail, e-mail etc.) in a consistent manner'.

     We contend that this means that, if an end system is capable of
sending an MMS towards the addressed destination URI, and if this
message only includes plain text according to the SMS specifications
(and as described in 23.140 and 26.140), the MMS system will be able to
process that message. Thus MMS is a candidate for "upgrade" even if the
end user prefers to send SMS only.

     There *is* a tariff issue here, in that sending an MMS may be
charged differently from sending an SMS; however, indication of the use
of MMS rather than SMS is an issue for the end system, not for the
protocol as such".

     As I have stated before, there is an existence proof in that 
Mobile
Operators *do* allow one to send are receive MMs with just a plain text
part. The specifications spell out that this is a standard part of the
MMS design. As such I have little choice but to assume that these
systems follow the specifications rather than completely ignore them, 
or
at least that they will be updated to reflect the specifications at 
some
point if they are, as yet, non-compliant.

<snip>

=====================================================
This electronic message contains information from O2 which may be 
privileged or confidential. The information is intended to
be for the use of the individual(s) or entity named above. If you are 
not
the intended recipient be aware that any disclosure, copying
distribution or use of the contents of this information is prohibited. 
If you
have received this electronic message in error, please notify us
by telephone or email (to the numbers or address above) immediately.
=====================================================

_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum
---------------------------------------
lawrence conroy    |tel:+44-1794-833666
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: Allison Mankin <[email-masked]>
Date: Sun, 15 May 2005 12:54:50 -0400

Lawrence, Richard, Enum-folks,

The IESG is now all clear on the enum-msg draft.  

Reviewing the exchange with Kim here, and the 05 draft:

- The references now look like they are as good as IETF
  can get them.

- The draft says precisely that an MMS can deliver an SMS, so a user 
  can use the enumservices accordingly.  It has given enough
  basis for this from the specifications.  The draft contains
  a statement that there are potential tariff and other differences
  between the encapsulated usage and direct SMS.

So my note is really just a heads-up that the approval will go forward
during the next day or so.  I believe the draft is all in order now.

Allison