Subject: RE: On attribute-based queries

From: "Venkatesh Raju" <[email-masked]>
Date: Wed, 31 Jul 2002 09:38:30 -0700

John,
	You're again bringing this back to the human aspect of "choosing"
things.  For software agents to search and select services attribute-based
searching is a necessity.

Venky Raju
System Architect, Wireless Core Technology
Nortel Networks, Santa Clara, CA

-----Original Message-----
From: John C. Welch [mailto:[email-masked]]
Sent: Wednesday, July 31, 2002 8:12 AM
To: [email-masked]
Subject: Re: On attribute-based queries

On 07/31/2002 01:16, "Venkatesh Raju" <[email-masked]> wrote:

> I'll go along with your arguments when it comes to human interaction.
However,
> as we enter a world with increased automation, where software-based
services
> are finding other services, searching by attributes (meta-data) is needed
to
> make unambiguous choices, even if the set only contains 2 elements.
> 
> It's the same reason why we're now defining the semantic web - the
original
> web was designed for human consumption.

There is a lot of temptation to add all these nice features to make searches
more precise, because engineers love precise, and precision is a good thing.
There's just one problem: Humans who aren't engineers aren't terribly
precise.

They want a list of printers. From the list of printers, they pick the
printer they want, set it as a default, (hopefully, this is done
automatically), and if they never ever have to change that, then they're
fine. If they are presented with a really long list of printers in this
area, they have one thought, (What idiot set up this list), and one action,
(Hello help desk? This is bob in accounting. Which printer out of this list
of 300 should I print to?) Ask anyone who's done user support, you hit the
average user with a print selection that has too many options, they're NOT
going to like it at all. They just want to find a printer, not perform a
search. (Yes, I realize the paradox in that last sentence)

I spent a few years doing IVR programming, and realized that if you hit
someone with a really long list, they'll punt and ask for help, and you need
to rethink your design anyway. Using DNS should allow you to create properly
populated subdomains that present a sane amount of choices to the user. If
you give them proper names, "Color HP Laser with stapler", then people will
pick the one they need. But they browse for printers, servers, etc. Not
"color lasers with 8 output trays, secure printing and a stapler."

I also see one real flaw with the "We must put in lots of fields so that you
can be more precise" approach.

 People don't, by and large, change a setting that works. Once people have
the printers they need set up in Print Center, they aren't going to ever
browse for another one unless they have to.

I've seen users ignore the Chooser for months, even years, as long as the
stuff they needed was available without it. If they can automount a server
once they've selected it, why go looking for more?

john

-- 
John C. Welch
IT Manager
MIT Police
(617) 253 - 3093 work
(508) 579 - 7380 cell
(617) 253 - 8822 fax

---

From: Rod <[email-masked]>
Date: Wed, 31 Jul 2002 12:47:08 -0500

>John,
>         You're again bringing this back to the human aspect of 
>"choosing" things.  For software agents to search and select 
>services attribute-based searching is a necessity.

I think the issue here is not if attribute-based searching is a 
necessity or not. Of course it is, since to look someting up you need 
to do it based on an attribute of that particular thing. In the case 
of DNS-SD, these attributes are type and name. This is simple, and it 
works. Take the yellow pages as a real world analogy. You look up a 
'type' of 'service', and then you look up the name (if you have one 
in mind) or choose from the available options.

Sure, it would probably be very useful to some to have a nice complex 
meta-data managing and querying engine where I could look up 
auto-shops with mechanics specializing in air intake efficienty 
techniques, yet after all these years we still have the basic and 
simple solution of looking up a service by type and name.

Why? Because it works, it's elegant, and it's simple.

I think this was John's point. And I think this is the point (and big 
advantage) of DNS-SD.

>Using DNS should allow you to create properly

-Rod Lopez

>John,
>         You're again bringing this back to the human aspect of 
>"choosing" things.  For software agents to search and select 
>services attribute-based searching is a necessity.
>
>Venky Raju
>From: John C. Welch [<mailto:[email-masked]>mailto:[email-masked]]
>  > I'll go along with your arguments when it comes to human 
>interaction. However,
>>  as we enter a world with increased automation, where software-based services
>>  are finding other services, searching by attributes (meta-data) is needed to
>>  It's the same reason why we're now defining the semantic web - the original

---

From: "John C. Welch" <[email-masked]>
Date: Wed, 31 Jul 2002 13:45:56 -0400

> searching is a necessity.

Because in the end, it's the only aspect that counts. (Computers don't buy
computers, humans do) As well, humans are far better at figuring out what
they want then software agents are, especially for things like printers.

We aren't talking about complex things like stock analysis agents here.
We're talking about simple things:

Things that create dead trees (printers)
Things that store bits (file servers)
Things that let me connect to things to do non-bit-storing things (ssh)
Things that show me movies (video servers)

In the case of printers...all it has to do is show a list of printers. If
the DNS is set up right, there is no reason to show me every printer in the
company. AppleTalk didn't do that unless you set it up wrong. Set up
correctly, all that should pop up is a list of local printers. SLP will do
this, but it's complex to set up, and an additional protocol that we have to
route, and filter, and look for hacks on. We already use DNS, it already has
the basic ability to do this, let's keep this simple.

john

-- 
John C. Welch
IT Manager
MIT Police
(617) 253 - 3093 work
(508) 579 - 7380 cell
(617) 253 - 8822 fax

---

From: "John C. Welch" <[email-masked]>
Date: Wed, 31 Jul 2002 14:12:57 -0400

> I think this was John's point. And I think this is the point (and big

That is precisely my point.

john

-- 
John C. Welch
IT Manager
MIT Police
(617) 253 - 3093 work
(508) 579 - 7380 cell
(617) 253 - 8822 fax

---

From: Keith Moore <[email-masked]>
Date: Wed, 31 Jul 2002 15:02:04 -0400

> in mind) or choose from the available options.

in the yellow pages you can (and occasionally do) have multiple 
resources with the same name.    this is fundamentally incompatible
with a DNS interface.

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Wed, 31 Jul 2002 15:41:22 -0400

> resources with the same name.    this is fundamentally incompatible

Okay, so you can't directly map the phone book to a DNS server. But then,
you aren't going to have multiple devices with the exact same hostname in an
single AppleTalk zone, or a single SLP zone either. For one, the humans
don't like it.

But, since DNS allows for hierarchy, you *could* have different zones with
resources with the same name, and not conflict, in the same way you can have
different AppleTalk zones with identically named devices. Foo.mit.edu is not
the same as foo.sloan.mit.edu, even though the hostname of each device is
still foo. One is foo over there, and the other is foo over here.

It's still a valid analogy for how the humans search.

john

-- 
John C. Welch
IT Manager
MIT Police
(617) 253 - 3093 work
(508) 579 - 7380 cell
(617) 253 - 8822 fax

---

From: Keith Moore <[email-masked]>
Date: Wed, 31 Jul 2002 16:29:00 -0400

> single AppleTalk zone, or a single SLP zone either. For one, the humans

collisions will happen.  perhaps those conflicts will get resolved 
over time, but trying to look up such names via a protocol that doesn't
recognize that collisions are likely doesn't seem like a good idea.

in a properly designed system humans can use other clues to 
disambiguate multiple services with the same name - e.g. for printers
they could look at device type, characteristics, location, etc.
OTOH expecting humans to know which name goes with which printer,
in an ad hoc network, is a bit much.
 
> still foo. One is foo over there, and the other is foo over here.

DNS has no built-in assumption that the leftmost component of a domain 
name is meaningful in its own right.  

> It's still a valid analogy for how the humans search.

well we were talking about this analogy in the specific context of 
using DNS for service discovery.  yes, humans can do fuzzy searches,
but DNS wasn't designed to facilitate this.

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Wed, 31 Jul 2002 20:03:11 -0400

> recognize that collisions are likely doesn't seem like a good idea.

Um, from what I've read on stuart's ideas about mDNS, it seems to have the
collision issue handled nicely.

> in an ad hoc network, is a bit much.

Real world experience since 1986 or so shows that it is not only *not* a bit
much, but that people prefer it. Why? When you want to find a restaurant,
you first go to Restaurants in the phone book, *then* you look for
restaurants, Chinese, etc. you do not, in normal life, start your search
looking for a Chinese restaurant that as Szechwan death as the Tuesday
dinner special, oh, and by the way, it needs to be on the corner of fifth
and main. You get the basic information for the restaurant, and the call it
to find out details.

This is *exactly* how service browsing should work. You select a main
category, "printers", then, if there are enough, you pick the zone. You then
get a list of printers in that zone. If they are named correctly, you have a
better idea of what the capabilities are, or you call for information. If
you only have one printer on your floor, then you don't care.

Overloading the humans with information in the initial search is a
guarannteed way to fail. You think the chooser has lasted so long because
it's the technical best way to do things? It really isn't, BUT, it works the
way that humans want things to work. NBP is not the best way to do things,
but the success of the implementation can't be denied.

> name is meaningful in its own right.

No, but the servers do, and if the entire name resolution maps them to
different IP addresses, then it's all good. Even if it maps them to
different services on the same host, with the same IP address, it's all
good. If you couldn't do this, then setting up multiple print queues via LPR
would really suck.
 
> but DNS wasn't designed to facilitate this.

Right. SO don't make the search protocol smarter than it needs to be. All it
needs to do is present a list of printers in the user's zone. That's all.
Anything else is over-engineering the protocol.

john

-- 
John C. Welch
IT Manager
MIT Police
(617) 253 - 3093 work
(508) 579 - 7380 cell
(617) 253 - 8822 fax

---

From: Keith Moore <[email-masked]>
Date: Wed, 31 Jul 2002 22:22:34 -0400

> collision issue handled nicely.

it cannot possibly handle the collision issue properly if using the same
interface as DNS because collisions cannot exist in DNS.
 
> and main. You get the basic information for the restaurant, and the call it

sure, but you still use claimed attributes of those restaurants in making
the decision - and different people use different attributes.

> you only have one printer on your floor, then you don't care.

that only works if the attributes you are interested in are exposed in the
name, and if the hierarchy is arranged in the order that *you* need in
order to select a printer, etc.

> guarannteed way to fail. 

agreed, but who said anything about overloading humans?   we're talking
about overloading the DNS interface.  

> needs to do is present a list of printers in the user's zone. That's all.

no, that's not sufficient.  and while you might argue that the user's computer
can poll every computer in the "user's zone" to see what its capabilities are
so that it can actually make an intelligent selection when there are more
than a few printers in the "user's zone" - it doesn't scale very well to zones
of the size contemplated by zeroconf - much less for use on non-ad hoc networks.

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Wed, 31 Jul 2002 23:38:09 -0400

> interface as DNS because collisions cannot exist in DNS.

Um...host name conflicts happen all the time if you aren't careful. Wonks
things up right nicely

> the decision - and different people use different attributes.

No, you use the simplest qualifications to start, then to more complex. You
refine the search. You don't start out with the desired seating chart and
cooking times of the food.

> order to select a printer, etc.

No, it works when they are not exposed in the name as well. And I didn't
invent NBP or the Chooser, but I haven't seen anything else that user grock
as well. People want simple, but that doesn't mean they are stupid. Again,
in a network situation, printers are static devices. They don't move. Once
you pick one, you can rely on it being there. Even if it changes IP
addresses, it *doesn't matter* because you are using the name, not the
address. So the printer has to be turned off long enough for something else
to claim that name in that zone. It just doesn't happen enough to rig a
complex search mechanism to avoid something that just isn't a problem.

> about overloading the DNS interface.

The humans have to like it and use it, or it's a failure. I doubt mDNS and
DNS-SD is overloading DNS anytime soon...it's quite robust.
 
> of the size contemplated by zeroconf - much less for use on non-ad hoc

Um, it scales really well actually. You don't poll for individual
capabilities. Sheesh, if you want that, then why bother with browsing, let's
all just use LPR, it's about as usable as SLP is at the moment, and name
every printer 
"HP_Laser_5SI_MX_mopier_600DPI_envelope_feeder_1500_sheet_hi_cap_tray_256MB_
RAM_9GB_hard_disk_duplexing_with_stapler_and_five_bin_output_tray"

*NO ONE* is going to look at that garbage twice...I know this because once
upon a time, I had the bright idea to put technically precise names on
printers as much as possible. I had to disconnect my phone so I could get on
with the work of renaming them imprecise things like "4th Floor Marketing
Printer"

Simple browsing is what the humans want.

john

-- 
John C. Welch
IT Manager
MIT Police
(617) 253 - 3093 work
(508) 579 - 7380 cell
(617) 253 - 8822 fax

---

From: Keith Moore <[email-masked]>
Date: Thu, 01 Aug 2002 00:00:11 -0400

> Um...host name conflicts happen all the time if you aren't careful. Wonks

DNS and hosts idea of their names can be out of sync, and DNS servers can be 
out of sync with one another if they are misconfigured, and these are
indeed problems sometimes.  but DNS cannot supply conflicting information if 
it is properly configured.  on the other hand, it's perfectly reasonable to
have two servers on the same LAN with the same properties down to the serial
number.

> refine the search. 

what is simplest to you may not be simplest to someone else.  one person
wants to find Chinese food, and another wants to find quick food nearby.
a single hierarchy will not satisfy both.

> No, it works when they are not exposed in the name as well. 

NO IT DOES NOT.  If I need a color printer the name of the printer isn't 
going to help me find one unless "color" is somehow exposed in its name.
Similarly if I need a duplexing printer.  And these are very common requirements.

> And I didn't
> in a network situation, printers are static devices. 

NOT IN AN AD HOC NETWORK they are not.

> They don't move. Once
> to claim that name in that zone. 

you mean, like when there's a power failure for several hours, like there 
was yesterday where I live?

> DNS-SD is overloading DNS anytime soon...it's quite robust.

They are trying to shove a lookup operation with differnet semantics
and failure conditions than DNS into the DNS API.  That's overloading.

> Um, it scales really well actually. 

to networks with 1000 hosts?

> You don't poll for individual
> capabilities. 

well, either you get a list of printers and poll for capabilities, or you expose
the capabilities in the names of the printers, or you use a service discovery 
protocol.  which is it?   

> Sheesh, if you want that, then why bother with browsing, let's
> *NO ONE* is going to look at that garbage twice...

I agree with that but I never said that they would.  I'm just saying that
the DNS query API is a poor interface for discovering services on an ad hoc 
network.

Keith