[Enum] RE: COMMENTS on draft-ra-shin-enum-mobileweb-01.txt

["Tim Moss" <Tim at bango.com>]

> From: lconroy [mailto:lconroy at insensate.co.uk] 
> 
> Hi There Tim, Ray,
> 
> Please read the draft and the earlier mails from the 
> ML-archive. I don't know how I can spell it out with more 
> clarity than I already have.
> There still seem to be folk who think that this is a
>      ->client<-
> machine capability specification.
> 
> Such an interpretation is Incorrect.

Lawrence,

Please accept this email as constructive criticism, as that is the
intention.

I did read the updated version of the draft and along with others
understood it as being related to the client phone number.

I joined this list after the main flurry of emails on this particular
topic so only had the updated draft document as a starting point.

I've since found and read the list archive, where you've explained much
much more about the draft.
Surely the fact that so many people misinterpreted it indicates that the
draft itself is easily misunderstood.  It really doesn't describe at all
well how the service is likely to be used.

If you'd included a few examples of its use like the one below then much
confusion could have been avoided.

> The Enumservice proposal in 'draft-ra-shen-enum-mobileweb-01' 
> allows the content provider to specify the forms in which 
> content is provided, and for these specifications to be 
> associated with a telephone number (via ENUM).

>From our experience dealing with many many mobile content providers this
isn't a problem that needs to be solved.
A content provider offering a service in more than one of
WML,cHTML,HTML,xHTML will do so server-side from the same URL.  The
client just accesses the one single URL and is dynamically served up
content appropriate for it.

If the content provider can't do this themselves then Bango offers a
services so that they can.

> Thus, for example, a service provider might provide a "personal web 
> page" for their customer, and the forms in which this content 
> is available could be published in the equivalent ENUM zone.

Other than the personal web page situation (and quite honestly even
then) how much use will this get?

How likely are users to associate a phone number with a content site?
How do they discover these phone numbers in the first place?

What does a content provider do if they have more mobile sites than they
do phone numbers?

If I'm looking for information about Microsoft I go to microsoft.com,
for Vodafone to vodafone.com.  If this approach fails then Google is
pretty good.

Surely entering a web address is easier and more likely to get a result
than typing in a phone number (even if I knew which phone number to
try).

If I want to get to the German version of the Microsoft website, do I
have to find their German phone number first?  Its much quicker to
change .com to .de


If people want a personal web page are they really likely to want to
publish it under their phone number?  Imagine the number of nuisance
calls they would get if anything on their homepage could be considered
offensive, or even if they'd just spelt something wrong.

Most people pick a domain name that relates either to the subject of
their homepage, relates to their own name or is just plain fun.  They
then have the choice of including their phone number for all to see or
not.


> It does not specify the capabilities of a client machine - I 
> would be fascinated with an analysis of the message exchanges 
> needed between different nodes to use such data.

The W3C Device Independence Working Group, Device Description Working
Group and Mobile Web Initiative are currently working on exactly this.

Since this issue is one that affects all websites, the above groups are
in a much better position to deal with the issue, rather than limiting
it to a small number of sites that can be forced rather uncomfortably
into an ENUM scheme.

> In earlier mails I have already mentioned the "bootstrap problem" that
exists in the real world,

This problem doesn't prevail in the real world either, not in our
experience anyway.

A mobile device will try to connect to the mobile operator's WAP,i-mode,
or 'Internet' gateway based on "connection settings" configured on that
device.

The user types in a URL http://www.somesite.com and the browser connects
via the gateway specified in the "connection settings" using the
protocol appropriate for that gateway.

> in that once a client has started to request content using (say) WAP,
> then switching to 
> another available form is an expensive shift - it takes 
> bandwidth and time. If you believe that this can be avoided 
> using non-proprietary means (and that will work with existing 
> devices) then please spell it out.

How much will actually be saved though - with this scheme the client
presumably needs to first send an extra request to lookup in e164.arpa
the information this ENUM service proposes to store.

So how does it make this first request if it doesn't in general know how
to connect to the internet?

Even if it can make the lookup, this extra connection/request is likely
to be just as expensive as the one you are trying to avoid, so there's
no net gain.


> In the interim, the 'mobileweb' Enumservice allows the client to know
what is available 

It only lets the client know what was available at the time of the last
update to ENUM, and only what is available on that one specific URL, and
it is only as accurate as the person who maintains the ENUM record wants
it to be.  

Assuming the destination document at the specified URL works ok on a
mobile, it may link to many other sites that may not be mobile sites, or
other pages on that same site may not display on mobile devices.

Worse still, how do I know that the site will work on *my* particular
phone, which may have one of a whole range of screen sizes and
resolutions, it may or may not support the image formats used in the
site, it may or may not accept a page with more than 4K of data in it
etc. etc.
The range of device compatibility problems go way beyond the simple
WAP,ME,i-mode choice that this services tries to boil them down to.


> - as you mention, without negotiation only the client can know what is
its capability, and so is in a position to select between the different 
> available options using whatever browsers it has to hand. 
> This Enumservice means that the client doesn't need to guess.

Again, in our experience the client doesn't actually need to guess.
Based on the MIME types of the response received from the content
server, which will be based on the types the browser indicates it can
handle (HTTP_ACCEPT request header) the client knows whether the
document is HTML,WML,cHTML,XHTML and can parse and render the content
accordingly.  Most mobile devices these days will cope admirably with
content in any of these markup languages,  whether they get displayed as
the content author intended is a whole different kettle of fish.

I can see that this service fits alongside the "web" and "ft" services
that allow ENUM to store the fact that an http://xyz URL is a web site
and that an ftp://xyz URL is an FTP site (you can kind of tell that from
the URI scheme though), but its premise seems flawed as it appears to be
trying to solve problems that don't exist, and doesn't address ones that
do.

Just because ENUM can store this information doesn't mean it should.

If you're looking for the "killer app" for ENUM, then like ".mobi" in
the DNS world, I really don't believe "mobileweb" isn't going to be it.



> all the best,
>    Lawrence
> 
> 
> On 31 Jul 2005, at 23:16, Tim Moss wrote:
> > I very much agree with Ray here.
> >
> > It would definitely be a good idea to discuss this proposal 
> with the 
> > World Wide Web Consortium (W3C) Mobile Web Initiative (MWI) as they 
> > are putting significant resource into this area, in 
> particular there 
> > are three W3C working groups that should be contacted.
> >
> > These are the Device Independence Working Group (DIWG), the 
> MWI Best 
> > Practices Working Group (BPWG) and the Device Description Working 
> > Group (DDWG).
> >
> > I don't believe that ENUM is necessarily the right place 
> for storing 
> > general device capabilities.  A single phone number could 
> be used by 
> > multiple devices (e.g. if the internet connection is initiated over 
> > Bluetooth to a mobile device) with varying capabilities, or 
> the same 
> > device may have multiple 'browser' clients installed on it e.g. WML 
> > browser, IMODE browser, video player etc.
> >
> > However, ENUM could be a good place for a user to describe their 
> > particular preferences with respect to how they would like 
> content to 
> > be presented to them, and potentially override any 
> automatic content 
> > adaptation that may otherwise occur.
> >
> > This should definitely be worked out in detail with the MWI though 
> > rather than splintering off into two (or more) different 
> solutions for 
> > achieving the same result.
> >
> >
> > Tim Moss
> > CTO
> > Bango
> >
> > e: tim at bango.com
> > m: +44 78 8779 4032
> > t: +44 12 2347 2823
> > w: http://www.bango.com
> >
> >
> > Mobile Content World 2005
> > ******************************************************************
> > "Come and see us on stand 14 at MCW 2005 Olympia Conference Centre, 
> > London, UK 13th - 15th September 2005"
> > www.mobilecontentworld.biz
> >
> >
> >
> >> -----Original Message-----
> >> From: Ray Anderson [mailto:ray at bango.net]
> >> Sent: 25 July 2005 11:42
> >> To: lconroy; Richard Shockey
> >> Cc: 'enum at ietf.org' ENUM; Tim Moss
> >> Subject: COMMENTS on draft-ra-shin-enum-mobileweb-01.txt
> >>
> >>
> >> Here are my top level comments:
> >>
> >> The idea here seems to be to provide "clues" about the services 
> >> available at an ENUM addressible site so that a device or 
> user that 
> >> could make use of those clues could provide a better 
> service to the 
> >> end user.
> >>
> >> The aims are good, but acfetr careful consideration I believe that 
> >> this proposal is wrong in its approach, and also wrong as an 
> >> ENUMservice.  I recommend the authors get involved in the 
> Mobile Web 
> >> Initiative.
> >> http://www.w3.org/2005/MWI/
> >>
> >> (1) Wrong Approach
> >>
> >> The W3C is currently engaged on a Mobile Web Initiative which is 
> >> working hard to ensure that web sites can give an improved 
> experience 
> >> to mobile users.  Currently most web sites are optimized to big 
> >> screen users with a "PC environment (keyboard, distraction level 
> >> etc.).
> >> There are many
> >> parts to this, not least of which
> >> is that the web site can use information presented by the end user 
> >> device (HTTP_ACCEPT among others) to determine how best to 
> deliver a 
> >> good experience to users. In addition, the site can redirect to 
> >> alternative services that might help, if teh device has certain 
> >> characteristics.
> >>
> >> Therefore, the idea of tagging a site with different URL's 
> that are 
> >> selected between by the client device or the user should not be 
> >> necessary, and in fact is more limited because the hosting site 
> >> should be able to evolve and adapt its capabilities much 
> faster than 
> >> the client device.
> >>
> >> There are many reasons why one URL for content promotion / 
> >> bookmarking / passing on is a good thing.  Thats probably why the 
> >> .MOBI TLD met with so much derision, and was rejected by 
> W3C, 3GPP, 
> >> and content providers.
> >>
> >>
> >> (2) Wrong as an ENUM service
> >>
> >> If the ENUM service approach (not withstanding the above) 
> was to be 
> >> useful, then surely it should be available across all domains, not 
> >> just those in e164.arpa, for example in www.neustar.biz so that 
> >> devices accessing those domains can also provide more appropriate 
> >> URL's depending on the support for WAP, ME, iMode, xHTML, 
> VoiceXML, 
> >> Flash, etc.  In that case, the extra "clues" should become 
> a general 
> >> DNS facility, otherwise only sites accessed by enum URL's could 
> >> provide the ease of use.
> >>
> >> In that case I assume there is some other working group 
> that should 
> >> look at the proposal.
> >>
> >>
> >>
> >>
> >> At 13:09 23/07/2005, lconroy wrote:
> >>
> >>> Hi Folks,
> >>>   In case no-one noticed, the mobileweb draft has been updated to 
> >>> "draft-ra-shin-enum-mobileweb-01.txt".
> >>>
> >>> This draft is covered in section 3.3 of the Agenda.
> >>> I would suggest that folk look at the new version BEFORE the ENUM 
> >>> meeting - the changes are editorial rather than technical,
> >>>
> >> but given how some
> >>
> >>> people seem to have interpreted the -00 version so far,
> >>>
> >> perhaps this one
> >>
> >>> will clarify things and avoid unnecessary flights of fancy.
> >>>
> >>> I would also advise folk to look at the "modest proposal" 
> draft, but 
> >>> as it seems vanishingly unlikely that there will be time to
> >>>
> >> cover that in
> >>
> >>> the meeting, questions/comments to the list would be appreciated.
> >>>
> >>> all the best,
> >>>   Lawrence
> >>>
> >>
> >>
> >
> 
> 

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