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

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

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. 

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

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. 

For intra-(and trans-) MMSE (Mobile Message Service Environment) use, 
it is possible that the "mms:" URL scheme will be used. As mentioned in 
the DISCUSS, this putative URL scheme has not been fully specified yet. 
The MSG Registration can be (and, we trust, will be) updated at a later 
data if and when this occurs. However, the ENUMservice variants 
"mms:mailto" and "mms:mms" are disjoint, and such an update will 
consist only of addition of a new sub-section - these ENUMservices do 
not "interfere". 

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. 

In the case of this registration, the mechanism by which an MM is 
delivered to an end-user within an MMSE is wholly out of scope for this 
ENUMservice. The only thing that a message sender (i.e. the application 
that acts as the consumer of the ENUM gleaned information) needs to 
know is the media types that are specified for use in an MM and so 
presumably acceptable for transfer and presentation to the destination 
user. Otherwise, it would matter to the sender of an email whether the 
recipient used POP3 or IMAP4. We contend that it doesn't, and that in 
the case of this ENUMservice, the MMS system is merely a delivery 
mechanism. 

[end of reply]
------------------------------------------------------------------------

> -----Original Message-----
> From: Ted Hardie [mailto:hardie at qualcomm.com]
> Sent: Sunday, April 24, 2005 11:47 PM
> To: Stastny Richard; Allison Mankin
> Cc: enum at ietf.org; iesg at ietf.org
> Subject: Re: [Enum] (Non)-Progress of certain Enumservices
> 
> >At 7:42 PM +0200 4/23/05, Stastny Richard wrote:
> >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.
> >
> 
> I will be in Geneva.  Because of the  IESG retreat just prior I will
> have limited
> connectivity starting Tuesday of this week, but we should be
> able to sort something out via email.
> 
> >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.
> >
> 
> I'd certainly be happy to discuss how to get clarity, as well as the
> immediate issues.
> 			regards,
> 				Ted Hardie

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

---

From: Ted Hardie <[email-masked]>
Date: Thu, 28 Apr 2005 10:42:00 -0400

At 2:55 PM +0200 4/28/05, Stastny Richard wrote:
Hi Allison and Ted,
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