Subject: Re: IPP>PRO revised agenda [some additional ideas]

From: Tom Hastings <[email-masked]>
Date: Fri, 7 Mar 1997 08:23:18 PST

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.

2. Select a transport protocol or specify a new one.

3. The protocol should be straightforward for the following environments
to support:

   ...

4. The deployment of clients and servers supporting new versions of the
protocol need not be done in lock step.

5. etc.

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.

Tom

At 20:32 03/06/97 PST, Robert Herriot wrote:
>
>The agenda is still rather loose. Here are the ideas that I put forth along
>with other suggestions further down in this email:
>
>
>
>At the moment, I would say that the agenda should be driven by the
>main outstanding issues.  The ones that we have inherited from the
>main group do not seem to be high level issues that we need to
>solve immediately.  I have written down some high level issues that
>I think we need to resolve.
>
>I would suggest that our agenda be to resolve these issues.
>
>If anyone has other ideas about the agenda or additional issues, please send
>them by 5pm PST Thursday 3/6.
>
>Issues:
>
>   Do we first define a generic mapping (e.g. MIME) which in turn is mapped 
>   to one or more protocols? If not MIME, then what?
>
>   What are the specifics of this mapping? 
>
>      Mapping of operations and parameters to protocol
>
>      Mapping of attributes and values to protocol.
>
>   Is HTML supported as a separate generic mapping?
>
>   Is one protocol HTTP?
>
>   Is there another, such as over a socket.
>
>>From Randy:
>
>Another philosophical discussion we need to think about is whether
>or not we allow the IPP model to dictate the type of transport
>we would like to use, or do we constrain the IPP model document
>to preferred transport mechanisms.
>
>>From Carl-Uno:
>
>a  couple of issues which I consider to be high level and which I would like
>to get tackled are:
>
>1) How difficult or easy is it to take abstract operations from the model
>and break them up into several operations in the protocol, vs. how easy is
>it to combine several abstract operations from the model and aggregate them
>into one operation in the protocol? (The question of granularity of
>operations in the model vs. in the protocol).
>
>2) How do you bootstrap into using security protocols such as RFC 2069 and
>SSL? This might have some impact on both model and protocol.  Also, is
>anybody planning to actually implement RFC 2069?
>
>
>

---

From: Patrick Powell <[email-masked]>
Date: Fri, 7 Mar 1997 19:58:18 -0800 (PST)

# To: [email-masked] (Robert Herriot)
# From: Tom Hastings <[email-masked]>
# Subject: Re: IPP>PRO revised agenda [some additional ideas]
# Cc: [email-masked]
# Sender: [email-masked]
# Status: R

# 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