Actually, the more I think about it, the more I am against using HTTP
in the way you propose.
- You define a special port
- You define a special content-type
- You define use of a command subset
To me that means you have a different protocol. Why not write a two
page draft that defines the access type ipp:// and just run straight
IPP over a TCP session? Much easier (I think)
>> Thanks for the comments. I have made some of the suggested changes
> and have put a new version out called ipp-info2.(ppt, ps).
>> For everyone else that is afraid they didn't have time to comment, feel
> free to make additional comments. For Roger's sake, I mostly wanted to
> add some pictures and some scenarios and get feedback on those as
> soon as possible. I agree that these are needed. What do you think of
> the approach I took?
>> Also, Roger, one of the comments came from Alex:
> What's the REAL benefit of using HTTP? I mean, while you use a Web
> browser you still need a helper app to give the user a nice
> frontend. What's the difference between this and simply using some
> generic TCP stream like SMTP has been doing for fifteen years now?
>> The reason I bring this up is because a lot of network admins have
> been very criticial of the very poor design of the original HTTP and
> the uncontrollable resource requirements of Web browser. Someone is
> bound to ask this question.
>> P.S.: While buzzword-compliance does not count as an answer, it
> certainly is accepted as a design criterium to ensure success of
> the project ;-)
> Alex Bochannek Phone & Fax : +1 408 526 51 91
> Senior Network Analyst Pager : +1 408 485 90 92
> Engineering Services Alpha Pager : (800) 225-0256 PIN 104536
> Cisco Systems, Inc. Email : abochannek at cisco.com> 170 West Tasman Drive, Bldg. E Pager Email :
>abochannek at beeper.cisco.com> San Jose, CA 95134-1706, USA
>> Do we have a write up on this specific issue? Could you (Roger) try to
> craft an answer for this? I can't remember if the rational for HTTP is in
> the I-D anywhere.