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