Subject: RE: [Enum] Comments on ID on new ENUM service "mobileweb"

From: "Fullbrook Kim \(UK\)" <[email-masked]>
Date: Fri, 15 Jul 2005 06:49:56 -0400

Nick Russell has already commented on the proposal and I would agree
with much of what he says. My view is that the proposal uses DNS
technology inappropriately, is easily broken and potentially there are
better solutions available, although with development work required.
These comments are from the point of view of a GSM operator. Equipment
may work differently in a non-GSM network.

It appears that the proposal is trying to store handset information in
the DNS. This is a very bad idea for a number of reasons:
- There is no easy way of updating the DNS with the new or updated
handset information other than by a manual process. If you're going to
update it in some automated fashion then you might as well do the job
properly and enhance the EIR (Equipment Identity Register) whose job it
is to record equipment details 
- In many countries operators sell SIMs only and users put them in their
handsets. How does the DNS get updated ?
- Mobile operators would be unhappy about the extra work required to
provision this information and keep it updated
- DNS has never been intended as a "real time" store for information.
Even if the DNS did get updated there would be propagation delays as is
usual with DNS
- Many users frequently swap their SIM card between handsets. Again
there is no way of updating the DNS with this information.
- As Nick has already said there are operators with a service that
allows one E.164 number to be associated with multiple devices. Updating
the DNS with this information is not realistic.

It's not clear to me how  this proposal would deal with handsets then
potentially can support more than one of Wap, Web, i-mode.

A better way to deal with this sort of requirement and get a
standardised implementation that everyone is happy with would be to take
it to 3GPP or OMA.

Another opportunity is created by the recent agreement by Icann to
introduce the .mobi TLD.   Use of this in URIs requested by users
immediately shows that they want to use mobile format web pages rather
than full size PC-optimised pages. 

Kim Fullbrook
O2 UK

-----Original Message-----
From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of
Russell, Nick, VF UK - Technology (TS)
Sent: 15 July 2005 10:46
To: enum at ietf.org
Subject: [Enum] Comments on ID on new ENUM service "mobileweb"

Dear All,

Having read the ID draft-ra-shin-enum-mobileweb-00 my interpretation of
it is that it is used by network equipment to determine which web
"protocol" (in the loosest terms) a device supports by looking up the
E.164 number associated with it in the ENUM/DNS.

If my assumption is wrong, please tell me. Otherwise, I see a number of
scenarios where this will fail and/or not be viable, particularly in
GSM/UMTS.

In GSM/UMTS, the E.164 number (or the "MSISDN") is NOT associated with a
device, it is associated with an IMSI (International Mobile Subscriber
Identity). The IMSI is stored in the network and on the UICC (Universal
Integrated Circuit Card) which has a SIM application on it. Such a chip
is more commonly known as a "SIM card", and can be moved freely between
different hand-sets by the user at any time they choose. This therefore
allows the user to change their handset whenever they like, *without
informing the network*! Such a different handset could support a
different "mobileweb" sub-type e.g. if I move my SIM card from my
SonyEricsson V800 to an HP iPAQ.

How are such updates going to be catered for in the ENUM/DNS? Static
configuration by a human will not suffice so I presume your thinking is
that the ENUM/DNS could be dynamically updated when the user turns on
the phone (i.e. the network detects a new handset and alters the ENUM
fields appropriately).

Today, operators currently cater for different devices by examining the
IMEI (International Mobile Equipment Identity) when the subscriber
establishes the data session (GPRS session). This IMEI value is used as
a key to a look-up table to determine such things as screen size, colour
depth, WAP browser capabilities (and however strict the WAP specs are,
there ARE differences in implementations of WAP browsers between mobile
handset manufacturers) etc. We then cache this information for the life
time of the data session. This cache value is therefore dependant on the
protocol layers below the IP layer.

Now, from what is being proposed in the ID in question, it seems
everything is going to be done at the IP layer (and above). Presuming
there is some undocumented dynamic way to update the "mobileweb" service
field (such as that described above), the TTL of the DNS resource
records are going to have to be fairly low in order to account for the
times when a subscriber changes his handset/device, as a DNS TTL can't
be set to expire when the user decides to turn-off his handset.

Now let's consider another service. Multi-SIM. This essentially allows
subscribers to "share" an E.164 number and is achieved by the network
storing the same MSISDN for a two or more IMSIs. So if there are, say,
two subscribers sharing the same MSISDN but both using different
handsets, and they both request a mobile web page of some sort within a
few seconds of each other, one subscriber will get the correctly
formatted page and the other won't.

So in conclusion, I don't believe this ID serves it's intended purpose
due to the two facts of:

1) DNS cache time can't be matched to a time period of the user's
preferred time of using the same handset (at least, without setting a
very low DNS cache time which is bad DNS design).

2) There is not always a one-to-one mapping between E.164 number and
mobile device.

In my mind, a better idea would be to create a whole new DDDS
application (is that the right term?) that uses IMEIs as the input
instead of E.164 numbers and re-write the general DNS caching rules (!)
to specify lower layer protocol events as expiration time (e.g. PDP
Context deactivation), rather than an actual time period (e.g. 1
minute)! ;-)

Cheers,
Nick Russell

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

=====================================================
This electronic message contains information from O2 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

---

From: Jim Reid <[email-masked]>
Date: Fri, 15 Jul 2005 07:29:35 -0400

On Jul 15, 2005, at 11:49, Fullbrook Kim ((UK)) wrote:
It appears that the proposal is trying to store handset information in
the DNS. This is a very bad idea for a number of reasons:
- There is no easy way of updating the DNS with the new or updated
handset information other than by a manual process. If you're going to
update it in some automated fashion then you might as well do the job
properly and enhance the EIR (Equipment Identity Register) whose job it
is to record equipment details
Wrong. Dynamic Update has been around since 1997. See RFC2136. Clients 
just send updates to the master name server.
This technology is at the core of how Active Directory works (albeit in 
a somewhat bastardised form). There is no reason for manual 
intervention at all. DNS zones don't have to be managed with someone's 
favourite screen editor and/or a bunch of shell scripts.

Putting the extra data in the EIR appears to makes sense. Buy why not 
put the EIR in the DNS? :-)

- In many countries operators sell SIMs only and users put them in 
their
handsets. How does the DNS get updated ?
The handset could have a DNS client that makes DDNS (Dynamic DNS) 
requests. These can even be authenticated using the identifiers on the 
SIM card itself. Or if we're talking about the installed base, 
something in the telco's network could make the Dynamic DNS update on 
behalf of the handset whenever a SIM is introduced to the network.

- DNS has never been intended as a "real time" store for information.
Even if the DNS did get updated there would be propagation delays as is
usual with DNS
The DNS may not have been designed as a real-time store but it can 
certainly function as one. Though things like propagation delays and 
TTL values obviously need attention. These are not insurmountable. It's 
a straightforward matter of engineering the DNS infrastructure for the 
operational requirements. Even with off-the-shelf open source BIND -- 
the reference DNS implementation and not the best choice for 
carrier-class solutions -- some TLD registries are able to offer close 
to real-time propagation of registration changes. It would be even 
easier to do this for small zones with a handful of resource records: 
ie one per E.164 number. And it would be even easier still with DNS 
server software that was designed specifically for those kinds of 
problems.

It would be good if we could capture the requirements and then build a 
DNS infrastructure to match them. That would settle the discussion 
about whether the DNS is or isn't up to the job.

- Many users frequently swap their SIM card between handsets. Again
there is no way of updating the DNS with this information.
Well if the handset makes a DDNS request when it's powered on or the 
SIM changes.... Or if the network does that for them...

---

From: lconroy <[email-masked]>
Date: Sat, 16 Jul 2005 06:25:55 -0400

Hi Folks,
 I have (unsurprisingly) looked through this draft more than once.
I still can't see where it says (or could reasonably be interpreted
as suggesting) that the end device capabilities are specified.
Like *ALL* Enumservices, this is a hint to the end device what they
will get if they use this URL,
i.e. this kind of content using this kind of web service is available.
As one example use-case, this content could be associated with a given
telephone number - it could be a personal web page for the subscriber
whose number has an ENUM registration, provisioned and/or available
via this web service.
It must be me, or the stuff someone is smoking.
all the best,
  Lawrence
On 15 Jul 2005, at 12:29, Jim Reid wrote:
On Jul 15, 2005, at 11:49, Fullbrook Kim ((UK)) wrote:
It appears that the proposal is trying to store handset information in
the DNS. This is a very bad idea for a number of reasons:
- There is no easy way of updating the DNS with the new or updated
handset information other than by a manual process. If you're going to
update it in some automated fashion then you might as well do the job
properly and enhance the EIR (Equipment Identity Register) whose job 
it
is to record equipment details
Wrong. Dynamic Update has been around since 1997. See RFC2136. Clients 
just send updates to the master name server.
This technology is at the core of how Active Directory works (albeit 
in a somewhat bastardised form). There is no reason for manual 
intervention at all. DNS zones don't have to be managed with someone's 
favourite screen editor and/or a bunch of shell scripts.

- DNS has never been intended as a "real time" store for information.
Even if the DNS did get updated there would be propagation delays as 
is
usual with DNS
The DNS may not have been designed as a real-time store but it can 
certainly function as one. Though things like propagation delays and 
TTL values obviously need attention. These are not insurmountable. 
It's a straightforward matter of engineering the DNS infrastructure 
for the operational requirements. Even with off-the-shelf open source 
BIND -- the reference DNS implementation and not the best choice for 
carrier-class solutions -- some TLD registries are able to offer close 
to real-time propagation of registration changes. It would be even 
easier to do this for small zones with a handful of resource records: 
ie one per E.164 number. And it would be even easier still with DNS 
server software that was designed specifically for those kinds of 
problems.

---------------------------------------
lawrence conroy    |tel:+44-1794-833666
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: Peter Koch <[email-masked]>
Date: Sun, 17 Jul 2005 13:20:09 -0400

Lawrence,

> as suggesting) that the end device capabilities are specified.

the paragraph

   If mobile web-serivce is registered as ENUMServices in accordance with 
   RFC4002(IANA Registration for ENUMServices web and ft), it is very hard
   for a mobile service provider, terminal and its user to distinguish
   mobile webpage from general webpage. Moreover, there is no way to discriminat
e
   the protocol(WAP, ME or i-mode) of mobile web-service to be supported by the
   terminal.

*can* be read to suggest that the web server determines the client's
capabilities to serve the best tailored "content" or presentation form.
Part of the confusion might also originate from the term "mobile service
provider", which is not a mobile provider but a provider of "mobile service",
where again "mobile" does not relate to mobility but to the limited display
capabilities of the mobile client device.

Still I'm not sure I get the proposal right; aren't there other or better
ways of capability negotiation?

-Peter

---

From: lconroy <[email-masked]>
Date: Sun, 17 Jul 2005 18:04:57 -0400

Hi Peter,
 sorry - it just hadn't occurred to me that anyone could read it that 
way.
(I should have asked you for a cigarette in the IDN Workshop in 
Luxembourg -
 it might have helped :)

Without this scheme, the Mobile Service Provider has no *easy* way to 
indicate
the kind of mobile protocol stack needed to retrieve it, the terminal 
has no way
to guess what kind of mobile protocol to use, and the user can't guess 
either
(well, they can, but from experience, with the help of said Mobile 
Service
 Provider's "Help" Desk, the user will probably make the wrong guess).

As for capability negotiation - hmm.
W3C are perfectly correct; one could use some more or less extended 
negotiation
technique (even using DNS queries for URNs if it looks like the 
negotiation might
complete before the end of the universe - see that proposal in the end 
of RFC3403
and in RFC3404 and RFC3405). If that doesn't generate enough revenue 
for Mobile
Service Providers, then one could always begin with SIP capability 
negotiation
before starting all that.

However... As you know, mobile phones operate over "long" pipes. Even 
with the
good capacity of 3G, the pipes are still long, and latency is the 
kicker for
extended negotiation. The Enumservices in this draft are designed to 
tell the
end user (and their terminal) exactly what content is available using 
what mobile
protocol stack//program. Negotiation is not needed, as the story is 
already out
as soon as the terminal does the ENUM query.

Hence - in answer to your questions "are there other and better ways of 
capability
negotiation?", I guess my answers are yes and no.

With these Enumservices, the user and terminal already know their 
capability,
and the Service Provider has already said in what forms and using what 
protocols
the content is available. There is no capability negotiation needed, 
which is going
to be quicker than any explicit exchange.

As for a "Mobile Service Provider" being a provider of "Mobile Service" 
- well, yes,
they do and are. So?
I don't think I understand the point you are making.

all the best,
  Lawrence
On 17 Jul 2005, at 18:19, Peter Koch wrote:
Lawrence,
 I have (unsurprisingly) looked through this draft more than once.
I still can't see where it says (or could reasonably be interpreted
as suggesting) that the end device capabilities are specified.
the paragraph
   If mobile web-serivce is registered as ENUMServices in accordance 
with
   RFC4002(IANA Registration for ENUMServices web and ft), it is very 
hard
   for a mobile service provider, terminal and its user to distinguish
   mobile webpage from general webpage. Moreover, there is no way to 
discriminat
e
   the protocol(WAP, ME or i-mode) of mobile web-service to be 
supported by the
   terminal.

*can* be read to suggest that the web server determines the client's
capabilities to serve the best tailored "content" or presentation form.
Part of the confusion might also originate from the term "mobile 
service
provider", which is not a mobile provider but a provider of "mobile 
service",
where again "mobile" does not relate to mobility but to the limited 
display
capabilities of the mobile client device.

Still I'm not sure I get the proposal right; aren't there other or 
better
ways of capability negotiation?

-Peter