Subject: Re: [Enum] (Non)-Progress of certain Enumservices

From: "Stastny Richard" <[email-masked]>
Date: Thu, 28 Apr 2005 18:12:53 -0400

Kim,
 
thanx for your support regarding mms:mailto
 
I leave the response regarding EMS to Lawrence;
because I am not the expert here.
 
> I'm not aware of anywhere where an SMS
>enumservice is needed.
 
Although it is somewhat moot to discuss the principle
contents of a draft wich had WGLC half a year ago
(this discussion here is only to clarify the last
objection  within IESG  from Ted  (out of 16).

Both sms:tel and sms:mailto is useful and already used:

I have a java ENUM client on my mobile phone, so I am
able to query ENUM and if an sms.tel exist, I know may send
an sms to an sms enabled number e.g a fixed line
which is SMS enabled. I think this feature may also
useful in countirs where no disctinction exist between
mobile and fixed numbers, eg in the US

On the other hand, I may send an SMS from my mobile 
to a VoIP phone. The SMS gateway is able to look up
ENUM and if it sees a sms:mailto the SMS is delivered
via e-mail.

regards

Richard

________________________________

Von: enum-bounces at ietf.org im Auftrag von Fullbrook Kim (UK)
Gesendet: Do 28.04.2005 17:40
An: enum at ietf.org
Betreff: RE: [Enum] (Non)-Progress of certain Enumservices

>From a previous email:

>> I believe it would be valuable to add this data to the paragraph
where
>> this set out in the :
>>
>>      In the case of MMS, EMS, and SMS services, the capability of
these
>>     services is a nested superset; thus a service supporting MMS can
>>     support also delivery of EMS or SMS messages to a recipient that
is
>>     capable of receiving an MM, whilst a service supporting EMS can
also
>>     deliver SMS messages to a recipient that can accept receipt of
EM.
>>
>> If there is a similar reference for the EMS nesting, it would be
>> equally valuable.

This is untrue. If an MMS service is offered, it does not mean that EMS
is available. Indeed while MMS is widely deployed around the globe I'm
not aware of any EMS deployments. (Can anyone supply information about
any live EMS service in operation ?).  There is no general connection
between MMS and SMS either, although there may be some operators where a
link has optionally been implemented.

For the purpose of enumservice registrations my recommendation is to
treat MMS and SMS as separate services and to not bother with
registering EMS. There is a need for MMS enumservice registration using
the format outlined by Richard Stastny for use by the MM4 interface
(enumservice = mms:mailto). I'm not aware of anywhere where an SMS
enumservice is needed.

Kim Fullbrook
O2 UK

=====================================================
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

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

---

From: lconroy <[email-masked]>
Date: Fri, 29 Apr 2005 06:05:53 -0400

Hi Kim, Richard, Matt, folks,
  thanks for the comments, albeit they are rather late. We're all happy 
to clarify why
things are in the draft, and potentially how they can be used.

However, it is not common to specify the whole of the teleservice (in 
ITU-T/3GPP terms)
within an ENUMservice registration - that's an aspect of user-to-user 
interaction that
is left for people to develop using whatever other interaction 
specifications they choose.

In my experience, the IETF leaves folk to implement the protocols for 
their own purposes.
Hence SOAP is carried over HTTP - I'm not sure that this use was 
considered when HTTP
was specified, but it certainly accounts for a significant chunk of 
HTTP traffic now.

(i)  At this stage, we are just handling things that are WRONG, rather 
than things that
     are inelegant or may not be used. We are a LONG way past WGLC or 
IETF LC on this draft.
     In terms of the IETF process::
    I fully expect this ENUMservice registration to be updated in the 
future. As standards-track
    RFCs move up through the "standards maturity levels" (see RFC2026 
for a well written overview),
    if there are no interoperable implementations for a feature or 
element, then this is removed
    from the updated specification. Thus, if no-one has implemented, 
for example, EMS support in
    ENUM-aware clients, then it's history.
    Compare RFC3966 and 2806 for an example of this process in action; 
"data:" is no more.

(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.

----
    Thus the only question with nested message types is whether or not 
the message elements included
    in the EMS specifications are transportable and presentable within 
the MMSNA. At least some of
    these elements are - for example, the "long text" feature is 
supported. It is also supported via
    current Networks. In my experience, (i.e. looking at my bills), 
this support seems to be in the
    end devices, with the network seeing a sequence of SMS messages. 
However, the fact that this
    element of the EMS specs is supported VIA the network, rather than 
BY the network, is unimportant.

    "Untrue" may appear correct from the Operator's perspective, in 
that their existing infrastructure
    does not explicitly support these features, but it is not from the 
perspective of the end users
    - their devices can support these features directly, using the 
capabilities of the network to deliver
    them. This is similar to using Skype over 3G data network access. 
Skype is certainly not supported
    BY the IMS system. It is supported VIA the network. Richard has a 
one thousand Euro invoice for two
    weeks 3G network access use to prove the point.

all the best,
  Lawrence
On 28 Apr 2005, at 23:15, Stastny Richard wrote:
Kim,

between MMS and SMS either, although there may be some operators where 
a

For the purpose of enumservice registrations my recommendation is to
treat MMS and SMS as separate services and to not bother with
registering EMS. There is a need for MMS enumservice registration using
the format outlined by Richard Stastny for use by the MM4 interface
(enumservice = mms:mailto). I'm not aware of anywhere where an SMS
enumservice is needed.
Kim Fullbrook
O2 UK
---------------------------------------
lawrence conroy    |tel:+44-1794-833666
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum