Subject: Re: service discovery characteristics

From: James Kempf <[email-masked]>
Date: Fri, 28 Apr 2000 13:14:43 -0700 (PDT)

Myron,

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

I think the debate was between MUST and SHOULD. I don't think
anybody would recommend SHOULD NOT or MUST NOT. The only downside
of characteristics is that the protocol implementation becomes
somewhat more complex.

My feeling is that SHOULD is fine.

		jak

---

From: James Kempf <[email-masked]>
Date: Fri, 28 Apr 2000 13:23:11 -0700 (PDT)

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

Sure, the art is in getting a succient service definition that
describes those characteristics of interest to a potential client.
Whether the printer body is beige or white is not of interest,
for example. 

Many protocols (and I think IPP is among them) contain support
for negotiating configuration after the device has been discovered.
But most don't explicitly contain support for specifying the 
characteristics of interest to potential clients when discovering.
Rather than building that support into every protocol, it seems
to make sense to put it into service discovery. 

SNMP is pretty heavyweight for service discovery in embedded devices.

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

That's why it's important to have a standardization procedure to
define what constitutes a printer, for discovery purposes. 

		jak

---

From: [email-masked]
Date: Fri, 28 Apr 2000 15:27:14 -0500

> -----Original Message-----
> From: EXT Richard Johnson [mailto:[email-masked]]
> Sent: Friday, April 28, 2000 3:51 PM
> To: Hattig, Myron
> Cc: [email-masked]'
> Subject: Re: service discovery characteristics
> 
> 
> Hattig, Myron writes:
> Ok, I'll try:
> /raj

I guess I still don't understand. Assuming a device is free to 
to advertise only its name, what difference does it make whether 
other devices choose to advertise a large number of characteristics?

One argument related to yours is that the query language for 
characteristic-enabled queries is too complex for simple devices.
These days this is only true for the most simple of devices and the
most complex of query languages. It seems likely to me that any device
that can handle an IP stack has the computational power to handle
resonable query processing.

Perhaps I am getting old, but I think I have heard this debate many times 
before. It seems like everytime someone invents a successful, scalable 
(more than a couple hundred nodes) namespace, they discover that a flat name

space is too hard to navigate. "Characteristics" aren't the only approach,
but 
they are a good one.

Franklin Reynolds