I guess we could say "Defense Happens".
Draft posted for comments.
Request for one addition.
Response as if Pandora's box has been open.
Of course, driving to conclusion is a very worthy goal. The extension
framework (below) is excellent - if we need avalanche control. (I prefer
the DTD). However, I don't see an avalanche, here - just an echo. Someone
asked for comments and someone answered from a different mountain. Maybe my
comment inadvertently activated some latent aggravation regarding phonebook
content?
Including a "print-to" URL among attributes like name, address, fax,
"mail-to" etc. seems natural to me. Given the efforts the IETF IPP working
group, the level of IPP adoption in the industry and the interest in using
IPP as a substrate for "fax-like" high fidelity transfer of documents over
the Internet (reference upcoming QUALDOCS bof
http://www.ietf.org/ietf/99nov/qualdocs-agenda-99nov.txt ) it would seem
like adding the IPP URL now (rather than later) would be a positive step
toward interoperability among Internet standards, protocols and products.
If Roamops would rather wait and add it later, or devise a generalized
scheme for future updates, that's your call, but it seems like more effort
in the long run.
It wasn't my intent to throw a monkey wrench.
Harry Lewis
IBM Printing Systems
harryl at us.ibm.com
Maximilian Riegel <maximilian.riegel at icn.siemens.de> on 10/29/99 03:13:46
AM
To: roamops at tdmx.rutgers.edu
cc: Richard Shockey <rshockey at ix.netcom.com>, Harry
Lewis/Boulder/IBM at IBMUS, Glen Zorn <gwz at acm.org>, "Calhoun, Patrice"
<pcalhoun at eng.sun.com>, randy at psg.com
Subject: Re: New internet draft:'draft-ietf-roamops-phonebook-xml-02.txt'
Richard Shockey wrote:
> >In general, my request for a print URL in addition to a FAX number
reflects
> >the continued consolidation of device features where print, scan, copy,
> >local print, remote print, fax, e-mail are more frequently being
> >consolidated into a locale (device, kiosk or otherwise integrated
> >solution). I think it makes sense to accommodate this in the
architecture
> >of your "phonebook".
> >
> >Harry Lewis
> >IBM Printing Systems
> >harryl at us.ibm.com>> Not to complicate matters but .. one other thing that is coming up in the
> IETF is the concept of e164 resolution... where ..in theory you could
> resolve the printer identification (aka fax) and the service associated
> with it ( URL) to a simple telephone number.
If we continue thinking about possible extensions to the phone book
which might become necessary in future we will never conclude.
I would like to keep the phone book specification as simple as
possible and to get it ready very soon to enable the deployment of it.
In my opinion there are several ways we might proceed:
- define a minimal set of feasible information elements fitting the
current requirements; forward any extension to a new version of the
phone book defined by somebody else in future.
- introduce a universal "#PCDATA" element allowing to put any kind of
information to be included into the phone book.
- develop a universal phone book DTD where anything in the
specification can be modified and extended by IANA registration.
- provide a hook in the specification of the 'provider' element to
enable IANA to register the inclusion of further elements without
impairing backward compatibility.
The last item seems to me to provide some kind of reasonable way to
proceed but requires a carefully designed 'IANA considerations"
section to enable IANA to do the right in future.
Max