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

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.

If there is a similar reference for the EMS nesting, it would be
equally valuable.

>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

_______________________________________________
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