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?
>>>