# I suggest that we start off by trying to agree on what the requirements
# are for the Protocol document.
# For example:
# 1. Map the tokens and semantics from the Model and Semantics document
# to a protocol.
I twitch every time I see the term 'protocol' used in this manner.
Most of the IETF world looks at protocols as things to be used for
data/network information transfer.
# 2. Select a transport protocol or specify a new one.
# 3. The protocol should be straightforward for the following environments
# to support:
Yes. This is VERY important.
# 4. The deployment of clients and servers supporting new versions of the
# protocol need not be done in lock step.
I do not understand this comment.
# 5. etc.
I would like to discuss unifying some of the efforts of the Protocol
and Model efforts, so that the limitations of existing/current transfer
protocols can be more explicitly examined. I have just been through a
'what if this is done? then we cannot use THAT protocol'
effort, and largely ended up with little progress in my own understanding
of the problems.
# A second agenda item would be to list the RFCs that are reference and/or
# background to the IPP protocol effort, especially for those of us who are
# not familiar with very many RFCs. I suggest that the protocol sub-group
# keep an every-green list of such RFCs. Such a growing list should contain:
# a. The complete title of the RFC
# b. The RFC number
# c. A sentence or two about what is in the RFC (maybe its Abstract?)
# d. Why this RFC is in this list: possible transport protocol, source for
# syntax, a good RFC to copy in form and presentation, etc.
# The best place for this list would be on the PWG IPP web page itself with
# hot links to the RFC FTP server for each listed RFC.
I agree. In addition I recommend that you also add the ietf proposals.
I would like to add an item - protocol implementation
and trial implementations of example (baseline) server which would gateway
IPP to LPR and SMB, a (Win32?) client and a UNIX client.
Patrick Powell