W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

Re: draft-ietf-http-pep-02

From: Mark H Linehan/Watson/IBM Research <linehan@watson.ibm.com>
Date: 22 Aug 96 12:45:22
Message-Id: <9608221647.AA8190@watngi02.watson.ibm.com>
To: Rohit Khare <khare@pest.w3.org>
Cc: Jepi-Core <Jepi-Core@commerce.net>, http-wg <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
A few comments:

1. You might comment upon ordering issues when there are multiple 
Protocol-Info, Protocol-Request, Protocol-Query, and Protocol headers contained 
in the same message header.  For example, a JEPI server will likely do UPP 
operations 2 and 3 in the same message:

   Protocol-Info:  {globeid ... {for \pay}}  {CyberCash ... {for \pay}}
   Protocol-Request: {upp {str req} {for \pay}

For UPP to work properly, the Protocol-Request has to be acted-upon after the 
Protocol-Info is stored.  This seems very natural given the semantics of 
Protocol-Info versus Protocol-Request.  I think the Internet Draft should make 
this more explicit.

2. Would it be useful to have Protocol explicitly express whether a Protocol 
was done by a sender in response to a Request?  To put it another way, might 
there be a "{str resp}" indicating that this Protocol line was inserted (and 
the corresponding protocol run) in response to a request?  This would 
differentiate a Protocol line done ad-hoc by a sender.  I think this might make 
the protocol more robust and help with problem diagnosis and error recovery.

3. I (still) wish there were a matrix discussing the meaning of each parameter 
(str, scope, via, for, params) for each type of header (Protocol, 
Protocol-Request, Protocol-Info, and Protocol-Query).  I think some of the 
cells may be meaningless, and others may have ambiguous meanings.  I think the 
exercise of filling in such a matrix may bring clarity to this proposal.

4. There used to be an "implementation model" in an appendix.  I hope you put 
it back in and expand upon it.

5. In verbal discussions, you've made it clear that "for" is basically just a 
hint which implementations are (mostly) free to ignore.  You should explain 
this concept somewhere.

6. A comment about exposition: I suggest that the section on PEP Syntax in part 
3.5 be moved before the rest of part 3.  I think many readers don't appreciate 
forward references when reviewing this kind of document.  The discussion of PEP 
Usage at the start of part 3 is basically meaningless until you've read part 
3.5.  Also, I think you should greatly discuss the explanations of the reserved 
top-level bags to make the semantics of each clearer.
Received on Thursday, 22 August 1996 09:50:59 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:08 EDT