Re: draft-arnold-scmp-03.txt
Tom Arnold <[email protected]> Thu, 24 Jun 1999 22:40:06 -0700
| Newsgroups | gmane.ietf.scmp |
|---|---|
| Message-ID | <[email protected]> |
There are numerous good comments here that I will continue to work over and give thought to. I have made a few notes to solicit some more feedback.... At 04:52 PM 6/18/99 +0100, Graham Klyne wrote: >> Simple Commerce Messaging Protocol (SCMP) >> [snip] > >I think that a section or appendix giving a formal syntax for a complete >SCMP request and response would be helpful. (I also suggest citing RFC >2234 rather than RFC 822 for ABNF syntax elements.) Yes. This is a very good point.... > > >>1. Introduction > >(Insert description of status of this SCMP version? See my comment above.) > >>The Simple Commerce Messaging Protocol (SCMP) is a general-purpose > >[...] >>1.1.10 Service Level Guarantee > >I'm not sure that "Service Level Guarantee" is the right heading here: I'd >suggest "Response Time Guarantee". We've been round and round on this one... Originally, this heading was "Quality of Service". I guess the problem I've had with most of these is there is really no "guarentee" except the server will time-out if the service level is exceeded. There is no specification of the server's response such as roll-backs or even whether the server finishes the original task. [snip] >> >>1.1.11 State Independence >> >>State dependency by either a sender's or receiver's application should >>be minimalized as to support multiple transport mechanisms. > >I think this might need to be slightly expanded; as it stands it doesn't >make too much sense to me. I think you are trying to say something like >either or both of: > The issue here was actually a way to further drive home "payload independence". ># The protocol must not depend on state information maintained by the message ># transfer mechanism, to minimize constraints on the mechanisms that can be >used. > ># The need for sender of receiver to maintain state information should be ># kept to a minimum, thus allowing the protocol to scale reasonably well. > >Also, I think the term "transport" as used here is not universally >accepted. I have seen it claimed that HTTP (and SMTP) are more than just >message transports. This is interesting. I've received comments that we should reference this protocol to the service level not transport. In actuallity, this is an implementation of S/MIME and is transport independent as well. This is something we should probably correct. More to follow later [ rest deleted ] Thomas A. Arnold CyberSource Corporation Vice President 550 S. Winchester Bl. #301 Chief Technical Officer San Jose, CA 95128 [email protected] Direct: 1.408.260.6010 http://www.cybersource.com/ Main: 1.408.556.9100 --------------------------------------------------------------------------- This Email and any attached files are confidential and may also be privileged. <bold><italic> </italic></bold>It is intended only for the individual or entity to whom it is addressed. If you are not the recipient or an authorized agent of the recipient, y ou are hereby notified that any use, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this message in error, please contact CyberSource Corporation immediately at (408) 556-9100. Thank you.