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

From: "Russell, Nick, VF UK - Technology \(TS\)" <[email-masked]>
Date: Mon, 18 Jul 2005 04:18:06 -0400

Hi Ray,

I agree with you that IMEI can stay the same while the browser changes.
Especially if the phone is just being used as a modem for a laptop, for
instance. My argument was more that the IMEI would perhaps give a
*better* indication than the MSISDN e.g. default browser for the phone
*currently* being used by the subscriber.

Cheers,
Nick

P.S.
Another reason why WAP push is used instead of MMS, is that it's more
likely to get past any MMSC "spam" filters and/or adult content filters!
;-)

> -----Original Message-----
> From: Ray Anderson [mailto:ray at bango.com] 
> Sent: 16 July 2005 17:32
> To: Russell, Nick, VF UK - Technology (TS); enum at ietf.org
> Cc: tim at bango.com
> Subject: Re: [Enum] Comments on ID on new ENUM service "mobileweb"
> 
> Nick,
> 
> Using IMEI to determine browser capabilities is not a very 
> common practice.
> 
> Very few content providers know the MSISDN let alone the IMEI.
> 
> Moreover, the browser can easily change while the IMEI stays 
> static (e.g.
> switching from the factory shipped browser to another, or by 
> using a browser proxy.
> 
> I do know that a few operators have to take a guess at the 
> browser / phone type, because they want to send MMS messages, 
> which are best optimized to target device type.
> 
> That's also one of the main reasons why Content Providers 
> have given MMS a wide berth and prefer to use WAP push or 
> equivalents to deliver multimedia services.
> 
> Ray
> 
> At 10:45 15/07/2005, Russell, Nick, VF UK - Technology \(TS\) wrote:
> >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.
> 
> 

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

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 18 Jul 2005 15:21:32 -0400

Nick,

I'm not sure I really understand the underlying need.  Even if the user
has the capability, it doesn't mean he is willing to use it.  SIP/SDP
and SIMPLE (presence) already have mechanisms to negotiate what
capabilities of a handset a user is willing to use at this instant or
Notify other users of such.

Just wondering if we are looking at the right tool to solve the problem.

Mike

> From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On 
> Behalf Of Russell, Nick, VF UK - Technology (TS)
> Sent: Friday, July 15, 2005 5:46 AM
> 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).
> 
> 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 
> 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
>

---

From: Ray Anderson <[email-masked]>
Date: Mon, 18 Jul 2005 16:35:28 -0400

Just re-reading the "mobileweb" submission, and it could be read differently.
Lets say you promote your phone number 44 1234 567890 to people as an
access point to your business, you might also want to make the same number
a short - cut to one or more web pages.   (Just like Bango Numbers point to 
URLs)

You could store the page URLs - different URLs for different browser types -
in the DNS using ENUM.
The idea of having a differnt URL (ENUM record) for each browser type is 
probably
as flawed as the .MOBI idea - since HTTP_ACCEPT should be used.

The idea of using ENUM / DNS to map numbers to content URLs is very reasonable.
At 17:51 18/07/2005, Peter Koch wrote:
Kim,
> The point is that unless the web site receives the CLI of the phone it
> can't use ENUM to look up the desired details. If the web site can't use
> ENUM then I'm can't see the applicability of the "mobileweb" enumservice
> being proposed.
are you suggesting that the web server uses ENUM as kind of "reverse mapping"
to lookup the properties of the requesting client which happens to be a
phone? Lawrence (thanks by the way) has already clarified that that's not the
case.
-Peter
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

Ray Anderson   T:+44 7768 454545    F:+44 20 7692 5558
ray at bango.com