I support Scott's view. Let's keep moving down the path we are on -- get the
protocol right,
then do whatever mappings we think are appropriate as a second step. I don;t
think that we
could standardize on the Microsoft approach because they are passing Microsoft
internal
data structures around.
---------------------- Forwarded by Roger K Debry/Boulder/IBM on 02/10/97 12:12
PM ---------------------------
ipp-owner @ pwg.org
02/10/97 10:11 AM
To: ipp @ pwg.org@internet
cc:
Subject: IPP> New HTTP Methods vs POST -Reply
Don,
************************************************************
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
************************************************************
>>> Don Wright <don@lexmark.com> 02/07/97 10:40am >>>
> So.... what if we were to take the Microsoft approach and map
> that to HTTP POST, standardize what they are doing and
> call it SIPP (Simple Internet Printing Protocol). Meanwhile,
> we can continue working on the DPA-light oriented approach,
> create new HTTP methods, and call that IPP.
I think that we should keep with the name IPP and keep it as simple as
possible. The print protocol (semantics and operations) should basically
be the same across all mappings on transports. In other words there
could be a mapping of IPP on:
1. HTTP 1.0 POST
2. HTTP 1.1 POST (taking advantage of new 1.1 underlying features)
3. HTTP 1.x extended methods
4. Raw TCP
5. Internet RPCs
6. IIOP
7. etc, etc.
In other words, lets not create two things, but one thing. Call it IPP. Then
as Randy and you have pointed out in later (than this) emails, propose
multiple "mapping documents".
I am still in favor of #1 above (HTTP 1.0 POST) or protoptyping and
reasonable first step deployment. Maybe we will learn more as we go
through the first step which will make additional choices more clear.
Scott