RE: [Enum] Status of draft-ietf-enum-msg

["Fullbrook Kim (UK)" <[e-mail]>]

Some comments on "draft-ietf-enum-msg" are below. For those that aren't interested in a long explanation here is the summary of the enumservices that I'd recommend are registered. Some have been deleted and some are updated compared to the previous draft.

name = "email", type = "email", sub-type = "mailto", generated URI scheme = "mailto:"
name = "sms", type = "sms", sub-type = "mailto", generated URI scheme = "mailto:"
name = "mms", type = "mms", sub-type = "web", generated URI scheme = "http:"
name = "mms", type = "mms", sub-type = "web", generated URI scheme = "https:"
name = "mms", type = "mms", sub-type = "mailto", generated URI scheme = "mailto:"


Justification / explanation in no particular order:


1) "Use of Tel URI" in fax, mms, sms and ems
--------------------------------------------
I'm not convinced of the value of the Tel URI scheme in the Enum registration . I realise that a similar example is quoted for a "tel" enumservice in RFC 2916 and I feel the same comments apply. An interesting aside is that there does not appear to be an enumservice registration to correspond to the "tel" example - section 3.2.2 of RFC 2916.

Quoting RFC 3966 which describes Tel URI as follows: "tel URI .....does not refer to a specific physical device, only to a telephone number".  So the enum registration is saying that for a particular ENUM you can reach that number using a particular telephone number. It looks like a circular description that tells you nothing new. Remembering that the absence of a number from the ENUM system does not mean that the number can't be reached, there seems to be no value added here, unless redirection is involved, in which case a different question/concern is opened up. 

If the value of the "tel" URI scheme is seen to be for redirection (i.e. I want all calls to [phone] forwarded to tel:[phone]) the question then arises - when should we check for a existence of a Tel URI NAPTR record in order to see if there is redirection defined ? The rules on this are missing/unclear.

For example, if I want to make a SIP call to [phone] am I meant to check first for a Tel URI NAPTR record to see if there is redirection to a different number ? This isn't covered in any of the SIP RFCs. If I'm not meant to, what value does it have ?  Back to the question "what is the value of the tel URI scheme ?". I've left it out of my list above. Can anyone clarify the intention and implementation here ?


2) Registration of EMS
----------------------</FO
NT>
EMS is "Enhanced Message Service". Until I read this document I'd never even heard of EMS. Although it was specified by 3GPP in reference [16] I'm not aware of any deployments in the GSM cellular world, indeed it's not even been mentioned. Its role was taken over by MMS which is the current standard for multimedia messaging and is widely deployed in GSM and other cellular systems. Possibly there is an EMS deployment in one of the non-GSM cellular systems but I think it's unlikely. Perhaps other members could comment here. EMS is a nice acronym and there is the possibility that it might be re-used in future for something completely different. I'd suggest that EMS is not registered as described here because there is no need for it. It can be added later if required.

3) MMS enumservice types
------------------------
First a bit of background. 3GPP document 23.140 describes the various interfaces to the MMS relay/server, labelled as MM1 to MM8. Only some of these have been defined. The interfaces and their protocols are as follows:

MM1 - "user terminal <> MMS server - wap
MM3 - "Legacy Messaging <> MMS server" - examples are : http, smtp  (exact protocol not mandated)
MM4  - "MMS server <> MMS server" - smtp
MM7 - "VAS Applications <> MMS Server" - SOAP over http


In theory any of these could use ENUM for routing purposes although in practice only the MM4 interface is available outside a given network. This might change in future and messages may need to be routed via any of the above interfaces.  Which of these need ENUMservices defined ?  

The MM1 interface is normally a fixed relationship. I can't see a need for ENUM here. 
MM3 - I'd expect this to be a fixed relationship but there's a small chance in future there might be the need to route MMS's based on E164 number

MM4 - Routing based on E164 number is definitely required here. Today this is the primary interface between operators.
MM7 - As for MM3 above.


Summarising, we have three interfaces to MMS which will (or could potentially) require an external ENUM interface: MM4 requires smtp, MM7 requires http (and https presumably as well) and MM3 is less fussy with either smtp or http being possible. 

My suggested enumservice type / subtype / URI scheme would be as follows:
mms / web / http
mms / web / https
mms / mailto / mailto


Comments & clarifications welcome.


Kim Fullbrook 
O2 UK


-----Original Message-----
From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of Stastny Richard
Sent: 08 February 2005 12:04
To: Richard Shockey; enum at ietf.org
Cc: Harald Tveit Alvestrand; paf at cisco.com; Allison Mankin</FON
T>
Subject: [Enum] Status of draft-ietf-enum-msg



Folks,


I am not sure if this is an agenda item, but the authors
of draft-ietf-enum-msg are currently at a loss on how to move this 
draft forward within IESG and may want ask the enum WG and/or 
the AD how to proceed:


Just a short recap of the situation:


After the requested submission of a new draft -03 Mr. Harald Alvestrand
put the draft on hold by stating:


"Version -03 does not address the issue of "what does it mean to send an (sms, ems, mms) over email". My DISCUSS stands."

Although the authors did not really get the problem since:
1. they are sending sms and mms back and forth between mobile phones and 
e-mail accounts since years.
2. 3GPP has standardized the use of smtp as protocol to send mms between
MMS Centers
3. It was not considered to get into details of other protocols
In enumservice registrations
4. the relevant standards have nevertheless been referenced in the 
draft, namely:


[16]  3GPP, "Technical realization of the Short Message Service
         (SMS);  (Release5)", 3GPP TS 23.040.


[17]  3GPP, "Multimedia Messaging Service (MMS); Functional
         description;  Stage 2 (Release 5)", 3GPP TS 23.140.


[21]  3GPP, "Multimedia Messaging Service (MMS); Media formats and
         codecs;  (Release 5)", 3GPP TS 26.140.


we forwarded the drafts to Harald, and Allison arranged a meeting
during the last IETF in Washington between Harald, Allison and myself.


I explained the drafts and the past and current situation regarding 
interworking between sms, mms and mail exchanges. Harald promised
to look at the drafts and to inform Allison and me of the outcome.


I did not hear anything from Harald until last week, when I had a 
chance to talk to him at a meeting in Vienna.


Harald gave a presentation on "How to male an RFC" and the basic message was:
You have to write one, you have to talk to many people and you have
to wait - How true ;-)


I asked Harald if he still has problems and he answered: Yes, I have
read the documents and still have loose ends. Maybe you could send
me a MMS to my e-mail account.


What we did.


<FONT
 SIZE=2>He also sent me an e-mail back with the following text:


>Richard,


>per our brief conversation in Vienna:


>What I said in October (recorded in the I-D tracker) was:


>>  Version -03 does not address the issue of "what does it mean to send 
>> an (sms, ems, mms) over email". My DISCUSS stands.


>I was informed by Allison that -03 was intended to address other issues, >and did not add the references I had asked for.

>I remember an exchange of messages about the document subsequent to this, >but I don't carry many messages more than a month old on my laptop while >I'm on the road, so I can't look it up now.

>However - it's likely that I ended that conversation with something like >"I'll be fine once those references are added to the document". The >document hasn't been updated.

>Over to you.....


>Harald


The problem with this statement is that we added the references already
to the drafts, so bringing at a new version may not help.


The only possibility is to add some additional references. We found e.g.
in draft-ietf-lemonade-mms-mapping-02.txt in addition to two of
our references from 3GPP the following references to 3GPP2:


[Stage_3] "MMS MM1 Stage 3 using OMA/WAP", X.S0016-310
    
"MMS MM4 Stage 3 Inter-Carrier Interworking", X.S0016-340
    
"Multimedia Messaging Service:  Functional description; Stage 2", TS
    23.140 Release 5.
    
[Formats] "Multimedia Messaging Service (MMS) Media Format and
    Codecs for cdma2000 Spread Spectrum SystemsÔ, C.S0045
    
[Overview] "Multimedia Messaging Services (MMS) Overview",
    X.S0016-000
    
[Stage_1] "Multimedia Messaging Services (MMS); Stage 1",
    Requirements, October 2002, S.R0064-0.
    
[Stage_2] ÓMultimedia Messaging Service (MMS); Stage 2", Functional
    Specification, April 2003, X.S0016-200.
    
"Multimedia Messaging Service; Media formats and codecs",
    TS26.140Release 5.


If this is considered helpful we could add the 6 3GPP2 references
in addition.


We ask the group, the shepherding AD and Harald
for advise.


Best regards
Richard



> -----Original Message-----
> From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of
> Richard Shockey
> Sent: Saturday, February 05, 2005 4:24 PM
> To: enum at ietf.org
> Subject: [Enum] Agenda Items for Minneapolis
> 
> 
> I'd like suggestions again for agenda items.
> 
> What we would have so far is
> 
> 1. Discussion of the ENUM dip indicator on behalf of the IPTEL WG.
> 
> 2. Status from Patrik on what is happening with the IANA and enumservice
> registrations.
> 
> 3. There seems to be a sense that we need to at least discuss some of the
> structure issues in enumservice registrations in general terms ..this
> seems
> to be a warm issue recently.
> 
> 4. Issues related to  Iris for ENUM  -- We have had no in-depth discussion
> of this draft on the list and we'd like to see more.
> http://www.ietf.org/internet-drafts/draft-ietf-enum-iris-ereg-00.txt
> 
> 5. WG next steps ?
> 
> Thoughts ?
> 
> 
> 
>  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> Richard Shockey, Senior Manager, Strategic Technology Initiatives
> NeuStar Inc.
> 46000 Center Oak Plaza  -   Sterling, VA  20166
> sip:rshockey(at)iptel.org   sip:57141 at fwd.pulver.com
> ENUM [phone]
> PSTN Office +1 571.434.5651 PSTN Mobile: [phone],  Fax: +1
> 815.333.1237
> <mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz>
> <http://www.neustar.biz> ; <http://www.enum.org>
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<&l
t;<<<<<<<<<<<<<<<<<<<<<<<
> 
> 
> _______________________________________________
> 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


========================================================This electronic message contains information from the mmO2 plc Group which may be privileged or confidential. The information is intended tobe for the use of the individual(s) or entity named above. If you are notthe intended recipient be aware that any disclosure, copyingdistribution or use of the contents of this information is prohibited. If youhave received this electronic message in error, please notify usby telephone or email (to the numbers or address above) immediately.========================================================
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum