Subject: service discovery characteristics

From: "Hattig, Myron" <[email-masked]>
Date: Fri, 28 Apr 2000 10:37:05 -0700

One of the debates at Adelaide related to characteristics. Basically the
comment from my notes is that we would discuss it on the list. Here is the
question:

MUST/SHOULD/MUST NOT/SHOUD NOT attributes/characteristics be supported by a
service discovery protocol?

I think characteristics SHOULD be supported. Characteristics allow for
refined queries so that things like color printers can be discovered instead
of just printers. The alternative is to discover all printers then negotiate
with each to determine whether it supports color printing or not. In my
simple view of the world this seems pretty obvious that characteristics
SHOULD be supported by a service discovery protocol. Can someone enlighten
as to why this is such a debatable topic?

-myron

---

From: Richard Johnson <[email-masked]>
Date: Fri, 28 Apr 2000 12:51:19 -0700 (PDT)

> as to why this is such a debatable topic?

Ok, I'll try:

Discovering that a printer *exists* and finding out the
*characteristics* of the printer could be separated.  Once you start
down the road of "characteristics", there no end to what could be
done.  (Does the printer have 2 or more paper trays?  How much paper
is in the paper trays?  What type of paper does it print on?  How fast
does it print?)  Afterall, what if I'm printing a large job (want
something which prints fast), on a special type of paper (want to know
what type of paper is in the trays), and I want it printed *now* (want
a printer which doesn't have any jobs running currently)?  Maybe
characteristics should be done using SNMP?

Anyway, that's an argument against including characteristics in
service discovery.  (Flame retardant suit in place.)

Of course, it's also a matter of how you define the device types.
Your list could consist of "CPU", "printer", "video recorder", etc.,
or it could consist of "CPU", "color printer", "b&w printer", "hard
disk video recorder", "VCR".

/raj

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 28 Apr 2000 13:16:25 -0700

Hello Richard,

> done.

Yes, there is an end.  You can establish the collection of
characteristics as part of a "service template".  The definition
of the service template could be agreed on by the vendors who
intend on providing such services.

> Maybe characteristics should be done using SNMP?

But user clients don't care about _managing_ the device.
They want to _use_ the device, and they would like to be
able to find a device to use without a lot of iteration and
hassle.

Besides, as I have been told, SNMP isn't exactly minimalistic.

Further, I am a big fan of (finally) enabling non-interactive
discovery of appropriate services.  Here, the iterative
user-interaction centered approach does not make very much
sense to me.

> disk video recorder", "VCR".

So, in order to write sensible applications, one has to pick.
It would be nice if application writers could write services and
clients to a specified API and specified template definitions
that would take the guesswork and prayer out of matching together
a user and a service.

Regards,
Charlie P.