Jay,
Sounds like you have spent some time looking at the details of LDPA.
To quickly answer your question:
- No, most real servers would use another transfer method - not content
included
- And no, there is no continuation mechanism specified in the LDPA
protocol as set out in draft 0.8. This is a weakness, but it a least
functional fall back for clients and servers that have NO OTHER transfer
method(s) available (FTP, proprietary, HTTP, FTAM, etc).
Now for a much more informed look at the some context and changes:
At the meeting in New Orleans, the PWG formed a new sub-team called
the Internet Printing Project (IPP). We have already made some
significant progress in the last week. There is a new mailing list set up
for just the IPP issues separate from the PWG. You can subscribe by:
To subscribe to the ipp at pwg.org list, send mail to:
majordomo at pwg.org
with the following as the body of the message (the subject line
is ignored by majordomo):
subscribe ipp
end
The first significant piece we addressed was to define this protocol on
top of HTTP rather than an RFC 1831 RPC mechanism. The feeling was
that we need to hammer out the semantics of the print protocol rather
than worry about middle-ware issues. This means that there is no
longer an immediate need for a "continuation mechanism" in the protocol
since we are just using HTTP. By the way, anyone reading, are there
limits on the size of a file transferable via HTTP? Therefor, the LDPA
protocol document is moving from RPC/XDR into HTTP/ASCII text strings.
Also, there is no immediate need for "check pointing." A Lightweight
protocol can not and will not support ALL of the features of some of the
more robust, end-to-end full blown solutions (Novell's NDPS and other
DPA based implmentations). For session oriented operations, check
pointing, continuation, etc., these are not in IPP at the moment. As HTTP
grows and matures into HTTPng hopefully those things will come along.
Some of our goals in IPP are:
- Define something that is doable (specification and prototype and
implmentation) in a very short amount of time
- Define something that has a growth path to more sophisticated
functionality and operations
- Work on User operations first, then move to operator and administrative
operations later
We have set up a BOF at the 12/96 IETF in San Jose to cover "internet
printing" issues. We plan to propose an HTTP solution. Please comment
on the IPP mailing list or come to the BOF or come the the working
meetings - the next will be in January in Albuquerque NM. See IPP mailing
list for more details.
Scott Isaacson
>>> JAY <jay at netgate.net> 11/15/96 11:41am >>>
What's the intent for "CONTENT_INCLUDED" data transfer in LDPA?
Is it that?...
+ These protocols are intended to run over stream protocols (TCP, SPX,
...).
+ The "OctetString includedDocument" is the actual job data?
+ There's a continuation mechanism so one document can be sent in
several Print requests? (If so, what is it?)
If there's no continuation mechanism, the recipient has to buffer the
entire document before accepting a request, which can be a problem.
Do you expect real-life servers to rely on "CONTENT_INCLUDED" or use
a
different transfer method for really serious work? Any performance
experience to report using particular transports?
Thanks for the info,
Jay.
aka: Jay E. Israel
jay at netgate.net
Background from the LDPA draft:
struct DocumentDescription {
ObjectIdentifier transferMethod;
DocumentContent *documentContentOptionPtr;
ObjectIdentifier documentType;
AttributeSet documentAttributes;
};
union DocumentContent switch(DocumentContentEnum designator) {
case DOC_CONTENT_INCLUDED:
OctetString includedDocument; /* External */
case DOC_CONTENT_REFERENCED:
DistinguishedNameString referencedDocument;
};