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

From: "Fullbrook Kim (UK)" <[email-masked]>
Date: Tue, 15 Feb 2005 12:46:46 -0500

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 +123-456-789 forwarded to tel:+123-456-222) 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 +123-456-789 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 +87810-13313-31331
> PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,  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

---

From: Richard Shockey <[email-masked]>
Date: Tue, 15 Feb 2005 15:35:25 -0500

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

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 +123-456-789 forwarded to
tel:+123-456-222) 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 +123-456-789 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 
-----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

MMS Centers 

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

Harald gave a presentation on "How to male an RFC" and the
basic message was: 

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

    
    
"Multimedia Messaging Service:  Functional description; Stage
2", TS 
    23.140 Release 5. 

    X.S0016-000 

    
"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 
> From: enum-bounces at ietf.org
[mailto:enum-bounces at ietf.org]
On Behalf Of 

> PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,  Fax:
+1 
<
mailto:richard(at)shockey.us> or
<
mailto:richard.shockey(at)neustar.biz> 
<
http://www.neustar.biz> ;
<http://www.enum.org> 

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

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 +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,  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>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: lconroy <[email-masked]>
Date: Tue, 15 Feb 2005 19:21:17 -0500

Hi Kim, folks,
 (CC list trimmed)
As our esteemed co-chair pointed out, this draft was updated to add  
clarifications
proposed by IESG - i.e. to make it a clearer document and at least tell  
the poor RFC
reader where they can go for more information. It has no substantive  
changes to the
version that was approved ages ago by the WGLC and the IETF LC. It's  
done, IMHO.
[BTW, gentle reader, I'd suggest avoiding 3GPP (or OMA) specs unless  
you have had at
 least one cup of coffee/tea first - think RFC340x on steroids :]
----
Your other possible options will have to await an updated RFC if and  
when formalised
specifications for application protocols to be carried over http/https  
are published
and implemented.

Also, note that there is some other work (with references to OMA specs)  
that would
*seem* to be applicable to MM1. The group dealing with this is called  
Lemonade, and
I'm sure they'll be able to clarify the use case:
See  
<http://www.ietf.org/internet-drafts/draft-ietf-lemonade-mms-mapping 
-02.txt>

----
However, you ask some questions that are ENUM-oriented, so - on the  
list:

Re. EMS - this is not only specified in 3GPP but is supported by your  
network :)p

One feature of EMS that's commonly used is also called "long SMS" or  
"concatenated
SMS" in the marketing blah of certain Scandinavian companies. A fine  
German company
does call it EMS in its marketing blah, as that's what it's called in  
the specs.
Your Suit May Vary.
--
Re. Tel URIs - I suspect there may be an underlying misunderstanding  
over the use to
which ENUM entries are put. I can register an ENUM domain associated  
with a telephone
number at which I'm provided telephony service - for example, my work  
landline number.
This means that I can put whatever resource records I like into the  
zone for
6.6.6.3.3.8.4.9.7.1.4.4.e164.arpa, as (at least in the UK ENUM  
pre-commercial phase)
I have this domain registered.

If I as an ENUM registrant wanted potential callers to know that they  
can send me
an SMS at a particular phone number, then I could "publish" such a  
NAPTR in my zone.
The NAPTR's generated URI would be the phone number or a device that  
can handle SMS,
whilst the Enumservice would say with what kind of communication the  
URI was associated.

Note that the client doesn't call the eNnumber - it does an ENUM lookup  
using DNS
to the associated zone to get the NAPTRs. That eNumber just happens to  
be tied to
the registered ENUM zone in which I publish the information.

Hence a NAPTR with the Enumservice "sms:tel" makes sense if your client  
can send an
SMS to that phone number (e.g. an ENUM client on a mobile phone). If it  
isn't capable
of sending an SMS to that telephone number, then the NAPTR will be  
discarded as "not
interesting" by the client.

Note - any SMS-capable device listed in the NAPTR sure isn't my work  
desk phone; it
would be just an SMS-capable handy I had, for which I was willing to  
publish the
phone number, and would indicate to clients what they could do with  
that phone number.
No - there isn't an SMS entry for my eNnumber visible to the "outside  
world" :).
----

In theory any of these could use ENUM for routing purposes although in
practice only the MM4 interface is available outside a given network.
Finally, MM3 most certainly is realised - it's how the MMRS sends to  
email
addresses from your mobile phone. It certainly does on Orange, and,  
local
picocell permitting, it does on O2 too.
MM4 is another story; less realised, more cobbled together.

all the best,
  Lawrence
I'm paid by Roke Manor Research Limited - there the similarity ends.
---------------------------------------
lawrence conroy    |tel:+44-1794-833666
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum