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

From: Ray Anderson <[email-masked]>
Date: Mon, 25 Jul 2005 07:55:20 -0400

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

---

From: "Tim Moss" <[email-masked]>
Date: Sun, 31 Jul 2005 18:17:03 -0400

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
> 
> 
> 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 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
> 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.
> 
> 
> 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.
> 
> 
> 
>