Subject: RE: On attribute-based queries

From: "Venkatesh Raju" <[email-masked]>
Date: Tue, 30 Jul 2002 22:16:29 -0700

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.

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

-----Original Message-----
From: Stuart Cheshire [mailto:[email-masked]]
Sent: Tuesday, July 30, 2002 10:00 PM
To: [email-masked]
Subject: On attribute-based queries

>Or "who has the network storage with the engineering groups
>files?" Or "who has a link to the internet that will cost less
>than 1c/megabyte?" Note: I'm not looking for _a_ way to do this,
>I'm looking for _the_ way to do this, that will work in general.

>Or is there a way of phrasing a service discovery query "find me
>the file with zcip in the name"?

I hear these contrived examples of attribute-based queries all the time,
and I believe they are so popular because they are so cool-sounding.
The more contrived the example, the cooler it sounds.

I believe the mistake is to assume that a cool-sounding example on a 
PowerPoint slide and a useful deployable protocol are the same thing.
A useful deployable protocol is frequently dull and boring. The hard
thing is having the courage to work on something dull and boring.

In reality, who wants to have to type in some query language to find 
something? In reality, 99% of the time people want to work the way the 
old AppleTalk Chooser worked: You open the Chooser, you click on the file 
sharing icon, and a short list of choices appears. You click on "Brad 
Hards's Linux Laptop", and the remote network file system mounts so you 
can access the files.

The motivation for having a UI where the user can enter some 
attribute-based query language is based on the assumption that when you 
open our future "Chooser", there will be so many thousands of available 
file servers that no human could possibly find the one they want, so they 
will have to interface with the network through this query language to 
narrow the list of choices. This is, to me, the boil-the-ocean solution. 
(How do you make a cup of tea? 1. Put a tea bag in a cup. 2. Boil the 
ocean. 3. Pour one cup of boiling ocean water over the tea bag. This is 
(a) a lot of work, and (b) the resulting tea doesn't taste very good.)

I'm not arguing that there aren't long lists in the world, just that they 
are sufficiently varied that a one-size fits all protocol can't work for 
all of them. A network with a thousand printers is a large network, and 
large networks are managed by administrators, and once you have 
administrators, lots of options are available to you. My recommendation 
to a company with a thousand printers would be to set up a nice Web site 
with a nice user-interface. Perhaps it could have a pop up menu listing 
the company's buildings, and checkboxes for attributes like "Double 
Sided" or "Automatic Stapler", and it could display nice graphical maps 
of the company buildings showing exactly where the selected printer is 
located. A generic SLP client can't know the list of the company's 
buildings in order to present the nice popup menu. Doing this with a Web 
page means that the company can present a nice customized UI that meets 
their company needs (if they have no printers with automatic staplers, 
then they wouldn't need that checkbox) without having to develop and 
distribute client software to implement this UI on every single platform.

The proof-by-example of how this works is on-line shopping Web sites: 
There are millions of books, but Amazon didn't invent some "Book Location 
Protocol" (BLP) to let you choose the book you want. Amazon implemented a 
Web site that lets anyone with a Web browser find the book they want by 
searching for author, title, subject, publisher, etc.

I believe the world already has the necessary big-network solutions for 
the big-network problems. What we are woefully lacking is the 
small-network solution for the user at home, or the school classroom, 
where there are only one or two printers, and no one to set them up.

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org

---

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

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

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: Keith Moore <[email-masked]>
Date: Wed, 31 Jul 2002 12:32:07 -0400

> browse for another one unless they have to.

uh, we're talking about technologies for discovering resources on ad hoc
networks.   set-once-and-forget isn't going to work in this case, because the 
next time the user prints it will be on a *different* network.

---

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

> next time the user prints it will be on a *different* network.

Actually, no it won't in an office situation for desktop machines. The
printer stays on 24x7, but goes into a power save mode. The desktops stay on
24x7, albeit with the screens turned off. (IT people like this for silly
things like backups and updates.)

So for all non-portables, this information isn't going to change much at
all. If you are using a print server, or some other fairly static device,
you can then have it maintain the records for the printers so that when
mobile devices connect, they still show the same printers at the same
addresses.

Finally, you (from what I can tell), can set up conventional DNS servers to
maintain this information outside of the .local zone so that users
connecting from remote locations can keep that information consistent as
well.

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 14:01:27 -0400

> > networks.   set-once-and-forget isn't going to work in this case, because
> > the next time the user prints it will be on a *different* network.
> 
> Actually, no it won't in an office situation for desktop machines. 

I agree - in an office situation for desktop machines, you don't need 
the autodiscovery mechanism nearly as much, because set-and-forget mostly
works there.  but that's not where I expect zeroconf technologies to be used.

the interesting situation is for the portables that want to use
set-and-forget while at home (or work) but not have that selection 
affect their defaults when they're in an environment where they
don't have a nearby default printer.

Keith

---

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

> works there.  but that's not where I expect zeroconf technologies to be used.

Actually, I can see it as being a great place for offices...trust me, if I
never have to set up another DHCP server again, I'll not be complaining. In
my experience, DHCP is such a pain, that I don't even bother with it.
Zeroconf allows me to dump DHCP, and makes things easier for me, and simpler
for my users. What more could I want?

> don't have a nearby default printer.

Then you take advantage of multihoming, and have both environments running
over the same interface.

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 14:58:40 -0400

> for my users. What more could I want?

zeroconf doesn't allow you to dump DHCP unless you're willing to statically 
configure all of your hosts that need to talk outside your local LAN, 
in order to give them global addresses.

so in answer to 'what more could I want?' - perhaps you'd like your
applications to work over the network?  (or if you don't, your users might...)

> Then you take advantage of multihoming, and have both environments running

you must be thinking about a different problem than I am.

Keith

---

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

> in order to give them global addresses.

Um...I use NAT, so they don't need global addresses, nor do I want them to
have global addresses. They sit behind a NAT server/firewall, which handles
all that for me. As far as the Internet is concerned, all my machines have
the same IP address anyway, so internal addressing is immaterial.

> applications to work over the network?  (or if you don't, your users might...)

Um...they do, because NAT deals with that part of it.

john

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