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

From: Allison Mankin <[email-masked]>
Date: Fri, 22 Apr 2005 21:00:05 -0400

>> Just for completeness:
>> The ifax draft:
>> http://www.ietf.org/internet-drafts/draft-ietf-fax-faxservice-enum-03.txt=
>> 
>> In RFC Ed Queue since 2004-07-12 ?!?
>
>Bad situation, stuck on a normative reference.

Being less terse about this.

The references (fax-ffpim -> fax-esmtp-conneg) are both in EDIT
now, so the document is not "STUCK" - it was stuck in the past,
but will now proceed, as they are proceeding.

There was coverage of this point on this list about a month ago.

Again, though, if there are publication deadlines from ETSI or 3GPP pertinent
to the ifax enumservice RFC publication, the IESG needs to know this.

Allison

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

---

From: "Stastny Richard" <[email-masked]>
Date: Sat, 23 Apr 2005 13:40:21 -0400

Hi Allison and Ted,
 
thank you for the quick response and also for the kind
offer to sort out the issue on msg in a teleconference.
 
I will contact the other autors after the weekend to be prepared
and arrange date and time.
 
Ted, I am not sure if you will also be available next week in Geneva
at the ITU-T Workshop on NGN in collaboration with IETF.
Rudi and I will be there, so we could meet there and would
only have Lawrence to call in. 
 
Irrespective of this, I would like to ask the IESG to re-consider
and clarify the requirements for the definition of Enumservices regarding
the underlying protocols.
 
I do not think that the definition of Enumservices require the
detailed clarification of all open protocol and interworking issues.
This was it least my impression with the already existing RFCs
for Enumservices, eg I personally have many open questions 
regarding Enumservice pres.
 
best regards
Richard

________________________________

Von: Ted Hardie [mailto:hardie at qualcomm.com]
Gesendet: Sa 23.04.2005 03:00
An: Allison Mankin; Stastny Richard
Cc: enum at ietf.org; iesg at ietf.org
Betreff: Re: [Enum] (Non)-Progress of certain Enumservices

>
>There is also still Ted's Discuss comment unaddressed, as you
>and I discussed in our verbal conversation in Minneapolis.  This
>is not only only fax: and tel: but also about a resolution on
>the uri usage related to mms and smtp interworking.  Please review
>the comment again, and perhaps the time has come to have a teleconference
>of Ted, you authors, the Chairs (if they want to get involved now, as
>not before), and me.

I would be very happy to participate in a teleconference to resolve
this.  Allison and I have discussed the points, and I suspect that
we will fairly quickly be able to resolve the tel: vs. fax: issue.
Allison has also sent me copies of the email exchange with Harald;
I believe, based on those, that we may be able to solve the remaining uri
issues fairly quickly with updated references and some very small
textual clarifications.    I do need to be sure that the references
describe carriage of MMS over "vanilla" SMTP; if that is not
correct, then some further discussion of how to include
mapping is required.
                        regards,
                                Ted Hardie

---

From: "Fullbrook Kim \(UK\)" <[email-masked]>
Date: Thu, 28 Apr 2005 11:40:58 -0400

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

---

From: "Stafford, Matthew" <[email-masked]>
Date: Thu, 28 Apr 2005 12:37:18 -0400

All- I'd like to reinforce some points in Kim Fullbrook's message below. I'm not aware of any EMS deployments. Our priority for the MSG draft is definitely MMS. I agree that there is a need for an ENUMservice registration that facilitates exchange across the MM4 interface (which is an SMTP interface).

Matt Stafford
Cingular Wireless 

-----Original Message-----
From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Fullbrook Kim (UK)
Sent: Thursday, April 28, 2005 10:41 AM
To: enum at ietf.org
Subject: RE: [Enum] (Non)-Progress of certain Enumservices

where
these
is
also
EM.

Kim Fullbrook 
O2 UK

---

From: "Stafford, Matthew" <[email-masked]>
Date: Thu, 28 Apr 2005 13:32:29 -0400

I have comments regarding the following statements from the message chain below:
>I'm also concerned about using a mailto: URI with MMS; the
>two are related, but not interoperable.

In my experience of the IETF specs, I've seen two ways to dereference a service to a protocol: with ENUMservice type & subtype (as in mms:mailto), or by mapping one URI scheme into another via SRV resource records (as is done, e.g., in RFC 3861 for im: and pres: URIs). I'll call these the ENUM method and the SRV method.

So, the alternative to dereferencing at the ENUM layer would seem to be define a new URI scheme and a means of mapping *that* to a mailto: URI. In fact, an attempt *was* made to define an mms: URI scheme (draft-wugofski-uri-scheme-00.txt). I understand there was lots of criticism; at any rate, that draft did not pass muster. Now, I'll admit that there were some problems with that draft- I don't think it associated mms: URI with SMTP.

That said, would it really be better to go via the SRV route? It seems like it would be more trouble- you'd have to define an _mms or similar tag. SRV records would have to be provisioned in DNS. And you'd still end up dereferencing to SMTP in the end. 

>3GPP TS 23.140 includes (see figure 3, section 6, section 8.5) an
>interface MM3 over which SMTP mails can be exchanged between the MMS
>Relay/Proxy and non-MMS mail systems (e.g. the Internet and SMTP
>servers).

Would it help if the service identifier was something that was clearly particular to the MM4 interface, such as "E2U+mm4:mailto" or similar? That would explicitly say that the interface in question is *not* carrying plain e-mail, but only bona fide multimedia messages.

What I would say about the MMS Stage 2 document (3GPP TS 23.140) is this: it's out of date. Specifically, appendix G is out of date. It was written before RFC 3761 obsoleted the previous ENUM RFC, and apparently was written under the assumption the mms: URI scheme would be approved in IETF.

In the options listed above, am I missing something? For example, is there a simple way to define an mms: or mm4: URI scheme and explicitly associate it with SMTP? My expertise is too limited to know the answer. But my fear hear (and the reason I'm speaking up) is further delay.

While I don't speak for 3GPP, I think it's clear that the MMS Stage 2 document cannot be brought up to date until the MMS ENUMService (or MM4 ENUMservice, if you prefer) has a stable definition.

Best,
Matt Stafford
Cingular Wireless

-----Original Message-----
From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Ted Hardie
Sent: Thursday, April 28, 2005 9:25 AM
To: Stastny Richard; Allison Mankin
Cc: enum at ietf.org; iesg at ietf.org
Subject: RE: [Enum] (Non)-Progress of certain Enumservices

At 2:55 PM +0200 4/28/05, Stastny Richard wrote:
>Hi Allison and Ted,
>
>I attach here the reply of the authors of the MSG draft
>(draft-ietf-enum-msg-04.txt)
>to your concerns raised in your DISCUSS on the PIDtracker.
>If you haveany additional questions we will be happy to
>discuss this further next Sunday/Monday in Geneva.
>
>Best regards
>Richard, Rudi and Lawrence
>
>---------------------------------------------------------------------
>[start of reply]
>
>PIDtracker shows the DISCUSS by Ted Hardie (Ted dot Hardie at QUALCOMM
>dot com) regarding the MSG draft (presumably -04 of February this year,
>but the date is last year) as:
>
>"Discuss [2004-08-30]:
>The fax registration lists the URI scheme as "tel", but the same
>document that registered "tel" (RFC 2806) also registered "fax".
>If this document doesn't want to use "fax" for some reason,
>it should explain why.
>
>I'm also very concerned about the description of the relationships
>among SMS, EMS, and MMS and the selected URI schemes.  The
>document lists MMS as a superset of SMS, which may be true
>in some environments but I am not sure it is necessarily true .
>I'm also concerned about using a mailto: URI with MMS; the
>two are related, but not interoperable.
>
>The best case there is undoubtedly to register MMS, a process that
>has been frustrated by the ongoing issues related to the revision
>of 2717 and the collision with Microsoft's use of MMS.  While
>I realize that is problematic, registering it with the wrong scheme
>seems like a worse problem".
>
>Taking these in turn:
>RFC3966 does not include the "fax:" URL scheme shown in RFC2806, which
>it obsoletes. Thus the URL scheme it does include ("tel:") is used.

This data has not been updated at the IANA registries (2806 is still listed
for tel and fax is still listed).  Offline I'll discuss with the Chair and
the AD how to get the registry updated and whether we need to
do anything else to deprecate fax.  In the mean time, I agree that
in the context of 3966, that tel is appropriate.

>MMS (as specified in 3GPP TS 23.140 and with MIME sup-parts specified
>in TS 26.140) includes a mechanism to carry SMS text as a sub-part
>within the Mobile Message (MM).

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.

>The final sentence of para.2 in this DISCUSS, with the first sentence
>of para.3, suggests that "mms:" is appropriate, and that "mailto:" is
>not appropriate.
>
>3GPP TS 23.140 includes (see figure 3, section 6, section 8.5) an
>interface MM3 over which SMTP mails can be exchanged between the MMS
>Relay/Proxy and non-MMS mail systems (e.g. the Internet and SMTP
>servers). As the email addresses used to specify the destination will
>be "mailto:" URLs, we cannot accept that this is incorrect - there is
>an "existence proof" of this in the services provided by some (but not
>all) mobile operators.

I think a conference call or other real time discussion may be needed to
resolve this.  As I read Section 6, the gateway function here does not
immediately look like it is appropriate for a mailto: URI.  The copy 
I have (V6.9.0.)
section 8.5 also seems to have just this text:   This clause may be specified
further in future releases. It may be that I am simply not looking at the same
versions, but the fastest way to resolve this may be in real time.

>
>As a final point, we believe that the applications that use information
>gleaned from an ENUM client, and the mechanisms used to deliver (in
>this case) messages, is out of scope for an ENUMservice registration,
>except insofar as the ENUMservice includes a description of the user
>interaction that will be expected to occur. Thus, for example, the
>presence ENUMservice describes the interaction expected, but not the
>mechanism by which that interaction is provided. Such an application is
>a user of the data retrieved from the ENUM client - the ENUM client
>itself is unaware of the communications mechanisms that may be used as
>a result of the information it returns.

While I understand your scope concerns, we also need to take care that
ENUM's use and understanding of the rest of the elements of the
Internet architecture remains consistent with other uses.
I appreciate your help in ensuring that these ENUM registrations
are used in a way consonant with other applications' uses of these
URIs.

                regards,
                                Ted

---

From: "Stafford, Matthew" <[email-masked]>
Date: Fri, 29 Apr 2005 11:34:33 -0400

Lawrence- Thanks for going to the trouble to post this message; I found the content informative.

To the mailing list in general:
I understand that my comments have come very late in the game. (By way of context, the MSG-04 draft is what's at issue here.) Probably I should have posted a much simpler message, along the following lines:

Far and away, MMS (specifically the MM4 interface) is my main concern. 
i) There is need in the wireless industry for the business with E2U+mms:mailto to get straightened out. For lack of a better term, it is needed for "intercarrier address resolution" in a number portability environment. If not E2U+mms:mailto, then we need some alternative that 

(a) satisfies the objections that have been raised (in IESG, I gather) and 
(b) still solves the address resolution problem. 
I don't speak for 3GPP but clearly appendix G of TS 23.140 is out of date and cannot be updated until this matter is settled.

ii) I know it's not crucial that I understand what the problem is with the MSG-04 draft, but in spite of myself I keep trying (unsuccessfully) to figure it out. I mean, the distinction between "regular" email over an SMTP interface and MMS content over an SMTP interface is embodied in E2U+email:mailto versus E2U+mms:mailto.

Best,
Matt Stafford
Cingular Wireless

-----Original Message-----
From: lconroy [mailto:lconroy at insensate.co.uk] 
Sent: Friday, April 29, 2005 5:06 AM
To: Stastny Richard
Cc: Fullbrook Kim; 'enum at ietf.org' ENUM; Stafford, Matthew
Subject: Re: [Enum] (Non)-Progress of certain Enumservices

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,
>
> 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:
---------------------------------------
lawrence conroy    |tel:+44-1794-833666