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

[Richard Shockey <[e-mail]>]

At 11:11 AM 2/15/2005, Fullbrook Kim (UK) wrote:
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.
Kim there seems to be some mis-understanding here.
This document has gone through both Working Group Last Call and IESG Last
call.
The revisions to the document were made at the request of the
IESG.
This document is essentially done and ready to enter the RFC Editors
queue.

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.
I believe this will eventually be taken care of ...

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 
---------------------- 
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 
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. 
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
to
be for the use of the individual(s) or entity named above. If you are
not
the intended recipient be aware that any disclosure, copying
distribution or use of the contents of this information is prohibited. If
you
have received this electronic message in error, please notify us
by telephone or email (to the numbers or address above) immediately.
========================================================
_______________________________________________
enum mailing list
enum at ietf.org

https://www1.ietf.org/mailman/listinfo/enum


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


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