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

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