Scott, I don't think we disagree. I do feel strongly that we should
work hard towards a common mapping, otherwise interoperation
will REQUIRE support of multiple mappings in every implementation
that wants to interoperate.
---------------------- Forwarded by Roger K Debry/Boulder/IBM on 12/19/96 06:20
AM ---------------------------
Scott_Isaacson @ novell.com
12/18/96 11:20 AM
To: Roger K Debry/Boulder/IBM, ipp @ pwg.org@internet
cc:
Subject: Re: IPP> Re: IPP over TCP -Reply
Roger,
I do like the idea of multiple documents. You seem concerned that having
multiple mappings might make it worse than better. I share the concern,
but feel that multiple mappings will only help us separate out application
protocol issues from encoding issues and then a suite of RFCs will
emerge as the ONE solution:
the appllication protocol RFC,
the LDAP mapping RFC,
the MIME encdoding RFC,
on the HTTP RFC
The suite for ONE solution might turn out to be:
the appllication protocol RFC,
the LDAP mapping RFC,
the MIME encdoding RFC,
on the IIOP RFC
The ONE solution will come down to what is implemented, not what is
written in a standard.
Scott
************************************************************
Scott A. Isaacson
Print Services Consulting Engineer
Novell Inc., 122 E 1700 S, Provo, UT 84606
V: (801) 861-7366, (800) 453-1267 x17366
F: (801) 861-4025, E: scott_isaacson@novell.com
W: http://www.novell.com
************************************************************
>>> <rdebry@us.ibm.com> 12/17/96 09:57am >>>
Classification:
Prologue:
Epilogue:
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