Subject: RE: On attribute-based queries

From: "Venkatesh Raju" <[email-masked]>
Date: Thu, 1 Aug 2002 08:10:20 -0700

It appears that for some people the universe is "Appletalk-replacement" and
"Printers".  In this confined universe it will be difficult to argue the
merits of anything over DNS.  You have to expand your horizon and
keep-it-simple is not an excuse.

---

From: "John C. Welch" <[email-masked]>
Date: Thu, 01 Aug 2002 11:24:01 -0400

> keep-it-simple is not an excuse.

I've yet to see any protocol implement AppleTalk's services as elegantly.
AppleTalk 'just worked'. None of the so-called replacements 'just work'.
They 'eventually work with a lot of support'. Zeroconf is the first thing
that I've seen that looks to 'just work'. "Just working" is one of, if not
*the* major requirements for what we are talking about. If you have to do
more than activate a wireless link, or plug in an ethernet cable to get
basic services, It's too complex for what it needs to do.

Secondly, "Keep It Simple, Silly" is a very good rule to follow in anything.
I have yet to hear anyone explain SLP and the like completely and coherently
in under 30 minutes. I've seen zeroconf done in 10-15...simple is FAR harder
to do well than complex.

john 

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

---

From: Robert Elz <[email-masked]>
Date: Wed, 07 Aug 2002 00:11:40 +0700

Date:        Thu, 01 Aug 2002 11:24:01 -0400
    From:        "John C. Welch" <[email-masked]>
    Message-ID:  <[email-masked]>

  | I've yet to see any protocol implement AppleTalk's services as elegantly.
  | AppleTalk 'just worked'. None of the so-called replacements 'just work'.

What this means is that no-one has done a good implementation of anything
else yet.

Once upon a time vinyl LP's "just worked" and there was nothing better
that anyone had demonstrated (though there were lots of attempts).
Now, vinyl LP's ???

Everything eventually gets replaced by something better.   Refusing to
countenance that anything could be better is just foolish.
 
  | Secondly, "Keep It Simple, Silly" is a very good rule to follow in anything.
  | I have yet to hear anyone explain SLP and the like completely and coherently
  | in under 30 minutes. I've seen zeroconf done in 10-15...simple is FAR harder
  | to do well than complex.

"completely" for SLP (as for NBP in appletalk) is hard to do quickly.

But for enough to understand how it works, "you ask on the net for
any devices that can service your request, which can be simple, or
can include extra requirements - anything out there which can handle
your request replies, and tells you what it can do, if there's more than
one, you pick (however you like, including popping up a "chooser" box
if you are actually going to have a human user to select), if there's
exactly one, well ... if there's less than one, then you either
try for lesser requirements, if possible, or give up."

That's it.   The rest is all boring detail that you don't need to know
to actually understand how it works.

Sound rather line NBP?   Aside from NBP being only able to locate names
of a given type (which actually is a truly lousy human interface to finding
things, as soon as there are more than just a couple), there really is no
difference.

kre

---

From: "John C. Welch" <[email-masked]>
Date: Tue, 06 Aug 2002 14:36:00 -0400

> What this means is that no-one has done a good implementation of anything

From the user standpoint, no they haven't.

> that anyone had demonstrated (though there were lots of attempts).

It took until the convenience of CDs to get people to move off of vinyl,
even though CD sound reproduction is just horrid compared to vinyl.

> countenance that anything could be better is just foolish.

I'm not at all. But, it has to be easy to use, easy to implement, easy to
maintain, and easy to integrate. So far, I haven't seen anything that
matches all three. AppleTalk is not perfect on the last test, but only if
you hate non-IP protocols.

> try for lesser requirements, if possible, or give up."

You aren't going to get anyone to implement a standard with that much
variation in the browser protocols. The average person will ignore most of
the options, and complain that it makes it too hard to use. Implementing the
more complex ones is a PITA from the other side, and jacks up network
traffic.

> things, as soon as there are more than just a couple), there really is no

You know what? In my experience, people like names. We use names rather
well. "Stuart Cheshire" is hardly descriptive at all, and for someone who
doesn't know Stuart, absolutely meaningless. But for the people who deal
with Stuart, or have talked with him, then "Stuart Cheshire" is all you
need. You don't use the name to perfectly describe what you are looking for.
In our printer example, you find out which printer is the duplexing color
laser, "Oh, it's the one named 'HP third floor color' Great, you add it to
your list of printers. Now, when you need to print color, the name gives you
the start point, and your brain says, "Ah, that's the one that also does
duplexing". 

Seriously, names are what humans use. You don't go out to the movies with a
(for example) human female, 5'11", 140lbs, black hair 18" in length with a
light wave, green eyes, non-smoker, has a porsche, likes Wesley Snipes
movies, lives at x address with y phone number, and is allergic to sushi.

You go out with Janet. There's what, 175 million women in the united states,
but someone men keep straight the ones they are dating/living with/friends
with/married to, etc., just fine, and they do it pretty much by name alone.
They remember the physical/emotional/mental characteristics, but when it
comes down to it, we use names, and well.

So there's nothing wrong with a list of printer names. They work. There's
also no requirement that you list all the printers in your organization in a
flat hierarchy. 

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: Tue, 06 Aug 2002 15:23:47 -0400

> You don't go out to the movies with a
> You go out with Janet. 

*You* might not care which Janet you go out with, but personally I prefer
the Janet who is 5'4", 110 lbs, blond hair, blue eyes, and drives a Honda.

AND YOU ARE TO STAY AWAY FROM HER!!!  :)

> There's what, 175 million women in the united states,

There are some awfully confused men out there then, if the cannot tell
(or do not care about) the difference between one Janet and another.

> comes down to it, we use names, and well.

I know dozens of dance partners whom I recognize (and ask to dance)
based on what they look like and how they dance.  If I remember their
names, so much the better.

("why didn't you ask her to dance?"  "I didn't know her name!")

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Tue, 06 Aug 2002 16:18:19 -0400

> the Janet who is 5'4", 110 lbs, blond hair, blue eyes, and drives a Honda.

But when you look her up, I'll be it's by name, and I'll bet you call her
Janet not "human woman, 5'4"..."

The important thing is that because humans deal with the fuzzy logic behind
the name, the name doesn't *have* to be so detailed. And it works. Even if
you know multiple Janets, I doubt you get them confused. (you better not ;-)

> AND YOU ARE TO STAY AWAY FROM HER!!!  :)

Heh...she's a bit on the short side for my tastes, no worries mate ;-)

> (or do not care about) the difference between one Janet and another.

Exactly.

> names, so much the better.

Even then, you still (most likely) do it based on a very few conscious
parameters. 

> ("why didn't you ask her to dance?"  "I didn't know her name!")

Hee...I know that routine ;-)

john

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

---

From: Robert Elz <[email-masked]>
Date: Wed, 07 Aug 2002 02:22:43 +0700

Date:        Tue, 06 Aug 2002 14:36:00 -0400
    From:        "John C. Welch" <[email-masked]>
    Message-ID:  <[email-masked]>

  | I'm not at all. But, it has to be easy to use, easy to implement, easy to
  | maintain, and easy to integrate. So far, I haven't seen anything that
  | matches all three. AppleTalk is not perfect on the last test, but only if
  | you hate non-IP protocols.

I have done a lot of work with appletalk (including implementing all the
bits that are relevant here).   It isn't too hard to implement (localtalk
aside, but that's not relevant) it is horrible to maintain (ever tried to
change a zone name?).

But none of that really matters, what's easy to implement or maintain
has little effect on what becomes popular (believe that web browsers are
easy ??)

  | You aren't going to get anyone to implement a standard with that much
  | variation in the browser protocols. The average person will ignore most of
  | the options, and complain that it makes it too hard to use. Implementing the
  | more complex ones is a PITA from the other side, and jacks up network
  | traffic.

I think that you're putting too many assumptions on the user interface and
the protocol being closely linked.   They need not be.   Take a trivial
example - if you just looked at SMTP, and told people that's how e-mail
was to be sent, most of them wouldn't want to know.   And they needn't,
their mailer takes care of all of the detail, all the user needs to know
is how to stick in a To address, type the message, and send it.

The same is true here.   If you believe that a browser that simply lists
the names of available printers is the user interface that people want,
then I can trivially see how to make that work using SLP, I can't even
begin to imagine how to do it using (conventional) DNS.   (On the other
hand, if I already know the name of the printer I want, then DNS is
clearly the superior way to find out its address to talk to it).

On the other hand, if you want the browser to be smarter - when you're in
your graphics application, and select "print" (or "page setup" or something)
you get to see only the list of printers that can actually be used by
that application, as when it did its query, it was more selective than
just any printer - then it sounds much more like SLP to me.

Just because appletalk doesn't allow applications to assist like that,
and windows has no rational interface at all, so users aren't used to
this kind of help, doesn't mean that they're not going to like it when
it can be implemented.

  | You know what? In my experience, people like names. We use names rather
  | well. "Stuart Cheshire" is hardly descriptive at all, and for someone who
  | doesn't know Stuart, absolutely meaningless. But for the people who deal
  | with Stuart, or have talked with him, then "Stuart Cheshire" is all you
  | need.

Sure, once you know who/what you want to talk to, names (labels) as a
reference work just fine.   But then we're beyond service location, the
service has already been located sometime in the past.   No objections at
all to remembering the name that resulted from a previous activation of
service location, and then using the DNS to find its address, over and
over again.

But somehow, we have to find Stuart initially, and when I start, all I
know is that I'm looking for a WG chair, who happens to be involved
with the zeroconf WG ...

  | You don't use the name to perfectly describe what you are looking for.
  | In our printer example, you find out which printer is the duplexing color
  | laser,

How?

In the answer, don't assume there are necessarily any humans involved.
In much of this, there will be zero of those arcane animals.   Just nice
clean silicon life forms...

  | Seriously, names are what humans use.

The protocols designed here have to work for humans, they also have to
work without humans.   They have to work for small networks, but they
have to also keep working (or somehow know how to transition) when they're
on large networks (my laptop sometimes connects to my home net, which is
pretty small, and sometimes to the internet, which is pretty large, and
sometimes even to both at once...   the software in it doesn't change
when that happens, the same set has to cope with all possibilities).

  | So there's nothing wrong with a list of printer names. They work.

Not very well.   That's the environment I am used to, and I can never
figure out just which printer is which - yet they have names that people
believe will help - a few of them are obvious, most might mean something
to some people, I suppose, but they mean nothing to me.  I know which
printer I normally use, that's fine - but when that's not working, I have
to pick another one, and at that point it really starts getting hard.
Our list of names supposedly tells me where to go to find the printer,
that helps, assuming I know the geography and number scheme of the building
(which I don't, despite having occupied it since it was built, nearly a
decade ago).  It doesn't tell me which are inside rooms that have been
locked, and I can't get to (nor would SLP of course...).  It tells me
nothing about which printer will do what.   It all boils down to guesswork.

I suppose I could call the support staff - but then I'd end up talking to
myself.  I might find someone who actually knows what some of the printers
can do, but I doubt I can find anyone who knows about all of them.  If only
I could just ask the printers...

  | There's also no requirement that you list all the printers in your
  | organization in a flat hierarchy. 

No, of course not, and we don't, and printers in other departments are
all nicely hidden in general.  But hierarchy for no better reason than
making the list smaller is hopeless, it makes things harder, not easier.

kre

---

From: "John C. Welch" <[email-masked]>
Date: Wed, 07 Aug 2002 00:28:42 -0400

> aside, but that's not relevant) it is horrible to maintain (ever tried to

Far easier than changing a windows domain name, and I have yet to feel
confident that I have read any sort of SLP manual correctly...it seems to
work anyway, but I don't want that type of result. Knowing it worked because
I did the right things, that is what I want

> has little effect on what becomes popular (believe that web browsers are

Compared to other things, yes, from the human view.

> is how to stick in a To address, type the message, and send it.

Right...but email does a lot more than what we are talking about. I'm
talking about getting a list of a specific type of thing.

> clearly the superior way to find out its address to talk to it).

Maybe you can, but since there are no good SLP tools out there, from the IT
viewpoint, SLP is just a big PITA. DNS has good tools, and is well
understood.

> just any printer - then it sounds much more like SLP to me.

But that can be accomplished via the printer information on the local
machine. That's what PPDs, and intelligent print protocols are for. That
way, all the 'intelligent settings' are done locally. I don't want a network
full of packets fully describing the complete capabilities of a Xerox
1235DX. Just tell me the name of the printer, give my Mac the data it needs
to auto select the right ppd, or tell me I need the right ppd, and be done
with it. There is no need to query the printer for that information.

> this kind of help, doesn't mean that they're not going to like it when

In my experience, people using computers are inundated with information.
They want less information to deal with. If I have to wade through a list of
options just to pick a printer, then why bother with SLP, or IPP? Just go
back to LPR, and manually set everything.

> know is that I'm looking for a WG chair, who happens to be involved

Right. So then you just want a list of WG chairs in the zeroconf zone.

> | In our printer example, you find out which printer is the duplexing color

The best way that people know how...you ask the people who set up the
printers.

> clean silicon life forms...

See...that's your prime error. Let's design a protocol without considering
the humans. Well, you *can't* assume there are no humans. In fact, it's one
of the few things you can count on, that there will be humans. Because if
the humans can't use and implement your protocol easily, they won't use it.

> when that happens, the same set has to cope with all possibilities).

Right...but the simpler you keep things, the better they will work. That's
the closest thing to a universal truth I know.

> nothing about which printer will do what.   It all boils down to guesswork.

But in your example, there is no amount of complex device queries that would
help you either. Sometimes, the humans need to use better names, but that
can get out of hand as well. In any case, the traffic generated by what is
not an outrageous possible device feature browser query would get really
large, really quick. That's a bad thing.

> I could just ask the printers...

But then you just admitted you really don't know where they all are...so
what good will knowing the features do you if you don't know where the paper
is coming out at? So your really large amount of network traffic to receive
every feature from every printer in the building still won't do you much
good. You'd be better off knowing that the printers on your list are all
near you, and them looking at the ppd options for that printer to see if
it's the one you want. You don't need a complex protocol for that.

> making the list smaller is hopeless, it makes things harder, not easier.

In my experience, it's a driving reason to use a proper hierarchy. To reduce
useless input.

john

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