Ithink we did agree at the BOF to write up at least three or four RFCs
1) The overall print model and IPP print operations (the bulk of the current
document)
2) The MIME encoding for IPP
3) Mapping to at least HTTP
4) The use of LDAP
I believe that it is important that we proceed in parallel with most of this
work -- it is important to keep the entire context in mind and ensure ourselves
that the pieces in fact do fit together. However, I am opposed to the thinking
that we should allow IPP to be mapped to "n" different transports. We ought to
pick ONE and push it as THE standard. Otherwise we'll have RFC 1169 or DPA all
over again -- a common model but no common implementations. I'm not opposed to
writing up and perhaps prototyping several possibilities, but we ought to use
our prototype experience and look to some of our key partners, such as
Microsoft and/or Netscape to guide us on a single best approach.
---------------------- Forwarded by Roger K Debry/Boulder/IBM on 12/17/96 09:47
AM ---------------------------
ipp-owner @ pwg.org
12/11/96 05:15 PM
Please respond to rturner@sharplabs.com@internet
To: babakj @ MICROSOFT.com@internet
cc: ipp @ pwg.org@internet
Subject: Re: IPP> Re: IPP over TCP
Then there is the compromise solution: Do the spec and make it
transport independent (1 document), and then publish multiple
documents, each outlining a mapping to a specific transport so
the method is "standardized" for interoperability purposes
(documents 2 through n ), where 'n' is the number of transport
mappings we want to "standardize".
Another set of documents could also include a specification for
locating IPP services via one or more directory service
implementations.
I think separating the work of the working group into multiple
documents gives us a change to produce quality output with
realistic scope in a consistent timely fashion. Something like
every 4 to 6 months we have a draft document (somewhat final)
that includes a specification outlining functionality in
one of the functional classes I outlined above.
Randy
-- Randy Turner Network Architect Sharp Laboratories of America rturner@sharplabs.com