[Enum] Comments on ID on new ENUM service "mobileweb"

["Russell, Nick, VF UK - Technology \(TS\)" <Nick.Russell at vodafone.com>]

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