>B. The need for cover pages. Should the burden of cover page creation be
>solely on the IPP client or should mechanisms be created for IPP clients to
>signal IPP servers to create such cover pages?
I think the issue of "cover pages" should be generalized to document
metadata: cover pages are just one aspect of this, but other aspects might
include provision of information that is used for document filing. Also,
anticipating a world in which some messages are handled automatically, I
would suggest allowing the "cover" information to possibly include both
machine- parseable as well as human-readable information. (I am working on
a modest proposal that builds upon Mike Ruhl's cover-page draft for this
purpose: it's not "heavy lifting".)
>C. The need for identity exchange between IPP clients and servers. If a
>[VCARD] is adopted as a means of identity exchange, would this require
>support of TLS during Job Submission for all IPP/DSM transactions?
I'm not familiar with vCard details, but in dealing with identity I think
it is important to have a "formal identity" as well as address values;
e.g. a distinguished name used as a primary key in a directory. I.e. don't
rely on an e-mail address or URL as an identifier.
>D. Are mechanisms or protocols available to prevent the "spoofing" of the
>identity of a sender?
Are you contemplating something at the level of certificates and
signatures, or are you thinking alomng different lines here. I note that
this can never be just a technical problem: we may need technical enabling
measures, but some procedural elements are also needed. I think we will
need to be clear about this, and scope our work accordingly.
>
>E. Since support for RFC2301 TIFF file formats will probably be a
>requirement, what level of granularity in attributes needs to be exchanged
>between IPP client and Server? Are TIFF Profiles sufficient or are
>[FAX-SCHEMA] elements required.
FAX-SCHEMA elements go pretty detailed as far as raster images are
concerned. More detailed than most people would want, I suspect (but
that's OK because unneeded detail can simply be omitted).
I would not want to think that QUALDUCS was limited to raster imaging,
other than as a baseline. For example, given the right framework for
quality document transfer I can imagine many people wanting to send PDF
files. So I don't think TIFF profiles are enough.
>F. Facsimile service reports and logs are traditionally kept locally by the
>sender and recipient. Should IPP clients be able to query IPP server logs
>and what information should be made available?
Hmmm... an interesting thought. My gut feling is that this is primarily a
ocal issue, and as such is out of scope for a wpork whose primary goal is
global interoperability. At least, I think that any such considerations
should be separated from the main body of work.
>G. IPP offers a rich and robust set of job attributes for finishing
>options. Since FAX is traditionally the distribution of 1 copy to a
>recipient, is there a need to restrict the available IPP finishing options
>in an IPP/DSM Base Profile?
Where is the line between "presentation" and "finishing"? To the extent
that "presentation" concerns rendering of the information actually
transferred, I think that is in scope for QD. To the extent that
"finishing" does not deal with transferred information, I think that is out
of scope. (E.g. the idea that I should decline to send you a document
because your machine won't staple it is, I think, rather far fetched.)
In case it's not clear: I think we should NOT attempt to address finishing
options.
#g
------------
Graham Klyne
(GK@ACM.ORG)