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

[lconroy <[e-mail]>]

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:[phone]
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum