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

From: lconroy <[email-masked]>
Date: Mon, 1 Aug 2005 11:48:40 +0100

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.

If someone wants to do such a thing, then they can, of course, work  
on their own Enumservice spec, but this is not it.

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

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. Device capability/content form  
negotiation is indeed an option that (no doubt) the W3C and the Mobi  
JV members will develop/complete in the future. However, ->this<-  
Enumservice specification is NOT intended to do that.

In earlier mails I have already mentioned the "bootstrap problem"  
that exists in the real world, 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.

In the interim, the 'mobileweb' Enumservice allows the client to know  
what is available - 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.

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: [email-masked]
> 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:[email-masked]]
>> Sent: 25 July 2005 11:42
>> To: lconroy; Richard Shockey
>> Cc: [email-masked]' 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Tim Moss" <[email-masked]>
Date: Wed, 3 Aug 2005 17:32:47 +0100

Otmar, you are quite right - I didn't phrase that very well.
I wasn't really talking literally about the process of entering the site
address, more about how a user discovers and remembers what it is they
have to type in.  

However Bango believe your point is a very important one.
In general the shorter the address a user has to type in, the fewer
unusual symbols, and the more memorable it can be the better.

Bango offer a service where a user can enter the "phone spelling" of a
number as you use in your example, usually chosen to have some brand
significance or some relation to the service being offered, or the
number itself it that is more 'memorable' which it may be for some
fairly short numbers.

This easy access method works on the web as well as on mobile, but is
far more useful on mobile devices for the reasons you state below.

Tim Moss
CTO
Bango
 
e: [email-masked]
m: +44 78 8779 4032
t: +44 12 2347 2823
w: http://www.bango.com

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Otmar Lendl
> Sent: 03 August 2005 15:57
> To: [email-masked]
> Subject: Re: [Enum] RE: COMMENTS on 
> draft-ra-shin-enum-mobileweb-01.txt
> 
> 
> (Just a minor point, I don't address the bulk of your argument.)
> 
> On 2005/08/03 16:08, Tim Moss <[email-masked]> wrote:
> > 
> > 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).
> 
> On a simple phone with a 3x4 numerical keypad a number 
> (especially your typical 1800-CALLNOW type vanity number) is 
> be a lot simpler to input than a web address.
> 
> That does not hold on a full blown user interface with an 
> alphanumeric keyboard. On such a platform, URLs win.
> 
> /ol
> --
> < Otmar Lendl ([email-masked]) | nic.at Systems Engineer >
>