# - We will introduce a new attribute called "associated-devices". This
# will be a multi-valued attribute that can take on the "names" of associated
# devices that may or may not speak IPP or associated server components
# which may or may not speak IPP.
Make them the URLs of the associated devices. Invent a "lpd:" URL
scheme while you're at it, if you like.
# For other names, the values in this attribute are basically just string that
# can be used (hopefully) using some other access protocol or service to
# query that device directly. We will not get into the rat hole of trying to
# define the access protocol for the name along with that name.
This isn't a rat hole, is it? Leaving the name space unspecified seems
worse than just saying "it's a URL, but if you want to talk about
anything other than ipp or lpd, define your own URL scheme".
# It is expected that this new attribute ("associated-devices") will almost
# never be used by the end-user, but is there for the few times that it may
# be used and for an operator/manager trying to bridge between IPP and
# other managment protocols.
This is just a kind of link relationship that we're seeing all the
time in the web. One resource is linked to another resource.
# - We will add a new attribute called "printer-current-capacity" whose
# syntax is "integer percentage". If all is well, even if the printer is busy
# processing, then it could be set to 100 (100%). If all is not well could be
# set to 0 (0%). If there are 5 devices behind the Printer, and 3 are down
# and only two are left, then it could be set to 40 (40%). It will be up to the
# implementation to determine how to set these. It is only a hint. Probably
# most implmenations will either be constantly set to 100 or move between
# 100 and 0.
Where does this fit in any of the scenarios? And why should it be a
percentage? (In general, fractions work better than percentages here,
e.g., "2 of 5" is much more useful than "40%".)