1. For the benefit of Jay Martin, I am uninterested in nationalism.
Just the best technical solution by as many clued up, open minded people as
possible. Please refrain from your ridiculous and unfounded personal
asides. Your attempts to marginalize and trivialize people, as opposed to
issues, simply shows bias. Shut up and keep your personal stuff out of
this forum and stick to the issues.
Thank you and good night. Now to resume a relevant thread:
2. If IPP is to be a serious IETF standard, then accept the rules.
Expedience and arbitrary deadlines are not a licence for crap, and after
checking IETF rules I can't see anything that says "if you have to get
something out, just make up anything for the sake of the deadline". Jay
may laugh about this and trivialize IETF rules with his comments about the
UN, but I am sure he is a lone voice and that we (mostly) all do take IETF
procedures seriously , and that I am perfectly correct in drawing attention
to compliance with a proven system for getting the best solutions.
If you want a industry standard, that is to say, a compromise for the sake
of a quick and dirty patch, then just say so and I will shut up. But if
this group wants IETF respect and status, then the rules are well known.
But you can't have it both ways - make the choice.
The Possible Solution For Lateral Thinkers
****************************
3. Apart from this general principle of strategy being driven by quality
and truly lasting - as opposed to band-aid patches - solutions, the issue
of a practical and lean bandwidth protocol is far from clear. I am putting
forward the alternative of something modelled *along* the lines of IMAP IV
or IMSP (RFC 1730, 1733 etc) - tailor made for distributed computing and
associated problems - synch, minimalist bandwidth, mobile users - the guts
and glory of the 'net !!
---> see www.cac.washington.edu/imap
IMAP is already in or will be soon be put into many applications, including
Netscape and IE; Eudora I think has it as well. The point is that it
exists and this can be leveraged off so as to satisfy a good scheme and at
the same time enable a fastrack rollout. Application wise, it is a
happening thing, and can be rapidly and cheaply be adapted to IPP needs.
Modifications - some radical - may, of course, be needed, but the
groudwork and concepts are done ! Code is available, and it is
*extensible* and scalable. Printing has many similarities to mail clients
and servers, and in the internet context must assume that the user may not
use the same workstation more than once and that job status and the users
presence to receive the status may be out of synch. Therefore submission,
status, capabilitiy, storage and re-synch are all important. IMAP has
thought of and does all of this.
It includes:-
Offline submission and subsequent re-synch
Extensions - is compatible with known standards and also supports cute
"proprietory features" where available, as per optional SNMP - just what is
needed so people can print properly and still allow market differentiation
whilst making these opposites compatible.
MIME support
Ability to get basic file info/status without the whole file (very useful
for say checking out a forms db and capabilities == lower bandwidth); this
also means that new info can be added or changed when the job is submitted
to an unknown server for unknown conventions or conversions as needed
**********
Can people please look through this and see how it can be shamlessly
plaguerized for good ideas. I see a lot of potential here to steal a march
!!
geoff