Subject: [Enum] thinking about an "location" Enumservice

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 06 Sep 2006 17:12:30 +0200

Hi,

i'm thinking about whether to start working on a "location" Enumservice
(which would allow to refer from a phone number to the location of the
associated device). I'm well aware of the work in GEOPRIV and ECRIT -
however, some users (like hotels, tourist information, businesses eg.) might
want to openly publish their location associated with a phone number,
because their location can already be derived from eg. an web page etc.

Actually, there would be at least two "indirect" ways of doing that:

- using a "E2U+pres" Enumservice, which refers to a pres: URI, which in turn
resolves to a PIDF document. That PIDF could be enhanced with PIDF-LO data.

- using a "E2U+vcard:..." Enumservice, which points to a vCard instance with
a GEO property

- using a "LOC" resource record (RFC1876) [this would not be "full" ENUM]

I'd appreciate comments whether we should a) explicitely recommend one of
those solutions above, or b) draft a new "location" (or "geo") Enumservice?

cheers

Alex

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Lee Dryburgh" <[email-masked]>
Date: Wed, 6 Sep 2006 17:38:20 +0100

Hi Alex,

I've already been drafting out an Enumservice which refers to a URI
which resolves to a PIDF document for the purposes of both presence
and location information.

I would be more than happy to share what I have done so far.

I had not been aware of RFC1876 before, so I had not considered LOC
RR, besides they don't quite work as well for the applications that I
have in mind.

Regards

Lee

---------- Forwarded message ----------
From: Alexander Mayrhofer <[email-masked]>
Date: 06-Sep-2006 16:12
Subject: [Enum] thinking about an "location" Enumservice
To: "[email-masked]" <[email-masked]>

Hi,

cheers

Alex

---

From: "Lee Dryburgh" <[email-masked]>
Date: Wed, 6 Sep 2006 17:57:26 +0100

Additionally the other Enumservice that I have been drafting is one
for XMPP's GEOLOC (http://www.jabber.org/jeps/jep-0080.html).

The only concern I have is that we could run into many Enumservices.
One for each means of providing location information. But I see no way
around it and decided that the most important one's to cover first are
PIDF+JEP-0080 (GEOLOC). For what I am working on, I don't think I am
interested in anything beyond PIDF+JEP-0080.

As regards ENUM E.164 owners who are physically static (hotels Etc. as
you mention) then I would favour that the group follows your option b
and drafts a new "location"  Enumservice (which could even be
automatically populated, so on reverse number lookup).

Regards

Lee

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 6 Sep 2006 14:04:05 -0400

I think vcard or pidf will serve all the uses I can think of.  I think you
should recommend pidf unless the other properties of vcard are useful.  I
think defining a new form is a bad idea.

Brian

> -----Original Message-----
> From: Alexander Mayrhofer [mailto:[email-masked]]
> Sent: Wednesday, September 06, 2006 11:13 AM
> To: [email-masked]'

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 6 Sep 2006 22:11:22 +0200

Considering the intended usage of a location information
(giving the location of hotels and other public places)
I would prefer to have an enumservice "loc" dedicated
for giving a location, so you can look and filter for it
 
This may pont to a vcard or pidf-lo, whatever
 
Richard

________________________________

Von: Brian Rosen [mailto:[email-masked]]
Gesendet: Mi 06.09.2006 20:04
An: 'Alexander Mayrhofer'; [email-masked]
Betreff: RE: [Enum] thinking about an "location" Enumservice

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 6 Sep 2006 16:16:46 -0400

Seems to me like what you often want is a vcard, which contains a lot of
info besides location.  If all you need is location, a PIDF-LO can give you
that without much overhead.  Inventing a NEW format seems unwise.

Brian

> From: Stastny Richard [mailto:[email-masked]]
> Sent: Wednesday, September 06, 2006 4:11 PM
> To: Brian Rosen; Alexander Mayrhofer; [email-masked]
> Subject: Re: [Enum] thinking about an "location" Enumservice
>

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 6 Sep 2006 22:27:21 +0200

Brian,
 
you did not seem to have read what I wrote
 
I did not say to invent a new format
 
I only wanted to make sure that if you look for a location
you get a location, so I want an ENUMSERIVICE pointing
definitely to a location e.g.
 
"E2U+loc:vcard" and/or
"E2U+loc:pidf"
 
Enumservice vcard may point to a vcard not having a location
 
Richard

Von: Brian Rosen [mailto:[email-masked]]
Gesendet: Mi 06.09.2006 22:16
An: Stastny Richard; 'Alexander Mayrhofer'; [email-masked]
Betreff: RE: [Enum] thinking about an "location" Enumservice

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 6 Sep 2006 16:54:14 -0400

Can you or Alex come up with a use case where the ONLY thing the enum client
wants is location and getting other information besides location is not
wanted?  The server can always deliver a vcard or a pidf that only contained
location if it insists on it, but an enumservice wouldn't be needed for
that.  I'm having a hard time understanding why the client would ask for
location exclusive of anything else it might find in a vcard or a pidf.

Brian

> Sent: Wednesday, September 06, 2006 4:27 PM
> > > - using a "E2U+pres" Enumservice, which refers to a pres: URI, which
> in
> > > turn
> > > - using a "E2U+vcard:..." Enumservice, which points to a vCard
> instance
> > > with
> > > a GEO property
> > >

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 6 Sep 2006 22:56:29 +0200

E.g:
You rent a car with a navigation device at the airport
(connected via WiFi or GPRS to the Internet)
and just have to enter the phone number of the hotel
to get the GPS coordinates
 
Richard

Von: Brian Rosen [mailto:[email-masked]]
Gesendet: Mi 06.09.2006 22:54
An: Stastny Richard; 'Alexander Mayrhofer'; [email-masked]
Betreff: RE: [Enum] thinking about an "location" Enumservice

Brian

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 6 Sep 2006 23:57:12 +0200

>Sure, but wouldn't a full vcard be an excellent response for anything like
>this?  
yes
 
>You might want the address too, for example.  The fact that you also
>got the name of the manager wouldn't bother you a bit.
 
yes, that is why I may use a vcard, but I look for a locations

>I just don't see a reason to invent a new enumservice to just get location
>from a phone number.
 
Does it hurt? What is the problem of having another enumservice?
 
Richard

Von: Brian Rosen [mailto:[email-masked]]
Gesendet: Mi 06.09.2006 23:35
An: Stastny Richard; 'Alexander Mayrhofer'; [email-masked]
Betreff: RE: [Enum] thinking about an "location" Enumservice

Sure, but wouldn't a full vcard be an excellent response for anything like
this?  You might want the address too, for example.  The fact that you also
got the name of the manager wouldn't bother you a bit.

I just don't see a reason to invent a new enumservice to just get location
from a phone number.

Brian

> Sent: Wednesday, September 06, 2006 4:56 PM
> > > > however, some users (like hotels, tourist information, businesses
> eg.)
> > > > might
> > > > resolves to a PIDF document. That PIDF could be enhanced with PIDF-
> LO
> > > > data.
> > > >
> > > > I'd appreciate comments whether we should a) explicitely recommend
> one
> > > of

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 6 Sep 2006 19:38:54 -0400

> Does it hurt? What is the problem of having another enumservice?
Interoperability: client implements loc+pidf, server only implements pidf.
They COULD have interworked, but they can't.

You can't require all servers to implement all enumservices for all numbers.
Having too many services that overlap is a very bad idea I think.

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 6 Sep 2006 17:35:39 -0400

Brian

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 7 Sep 2006 09:11:15 +0200

> You can't require all servers to implement all enumservices for all

? I do not get this
In ENUM there are only clients - the "server" is the DNS

A client needs only to implement the enumservices he is looking for.

Richard

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Thursday, September 07, 2006 1:39 AM
> To: Stastny Richard; 'Alexander Mayrhofer'; [email-masked]
> Subject: RE: [Enum] thinking about an "location" Enumservice
>

---

From: Alexander Mayrhofer <[email-masked]>
Date: Thu, 07 Sep 2006 09:34:23 +0200

> A client needs only to implement the enumservices he is looking for.

I think i understand Brian's issue, and actually i have to agree:

Say you have 5 options to do it on the "client" side, and the same 5 options
when publishing the information. A typical client implements 2 of those
services, and a typical ENUM domains contains 2 of those services as well.

That means that the client understands 40% of the possible services, and the
server publishes 40% as well. However (according to my understanding of
statistics, at least), the chance that client and ENUM domain overlap are
therefore 0.4 * 0.4 = 0.16 -> 16% (given that everything is uniformly
distributed).

That means that in only 16% of the cases the information could be used
(think of the old video rental stores who had to carry every movie in VHS,
Video2000 and Beta).

Hence, adding another option is probably not only reducing the chance that
the new service is successful, it also reduces the chance of the other
services to be widely deployed.

comments?

alex

---

From: Kewin Stoeckigt <[email-masked]>
Date: Thu, 07 Sep 2006 17:39:05 +1000

> I just don't see a reason to invent a new enumservice to just get location

But if you only have limited bandwidth (or not always "on" devices), it 
may makes sense to transmit only the required information, eg. the 
address. Why would I then care about the Hotel Managers name, etc.?

---

From: lconroy <[email-masked]>
Date: Thu, 7 Sep 2006 12:49:01 +0100

Hi Brian, folks,
  I'm confused. Server? Client? loc+pidf? I thought this was  ENUM.
AFAICT -
An ENUM client that handles an enumservice needs to know only that
the NAPTR with an (I guess) enumservice of loc:pidf holds a URI
indicates how it can get it pidf-loc data.

The loc service type tells it that this points at location information
and the sub-type pidf tells it the way it gets to that data. Conversely,
loc:ldap might tell its that the NAPTR pointed at the same kind of info
but that the way to get at it was via ldap:
This has been the case since before RFC 3761 was coined.

Either there's a server that can provide that data at the end of the
URI, or there isn't. That server need know NOTHING of ENUM, or how
the client of that protocol found out how to get there.

What's wrong with that picture?

all the best,
   Lawrence