[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Protocol Comparison Chart



I like your chart at the end listing how different protocols could solve
our needs..nice set of comments....later...rik


At 1:43 AM 9/28/96, Kent Schwab wrote:
>In listening to the committee discussing the pro's and con's of
>different protocols, it seemed that some framework would be helpful.
>I have tried to put (my perception of the) requirements for EC over the
>Internet down the left side, and check off what each protocol can
>support. Maybe we can use something like this to
>
>        1. determine the requirements we are trying to address
>           (what should be on the chart that isn't, and what
>           should be removed. For example, should broadcast
>           requirements be there?)
>        2. subset out the requirements and see the possible
>           technical solution(s) for addressing the requirements.
>           (e.g. possible solutions for non-conversational, for
>           'push' model sending with no retrieval requests, etc)
>        3. see what's missing, if we agree on the requirements,
>           and what people would be willing to invest to fix
>           the deficiencies. (e.g. true Transaction Processing/
>           Conversational support)
>
>Obviously, I would love to see a protocol specified which can address
>ALL the requirements, built on proven concepts and pieces of the other
>specs. I hope this little chart helps to get the ball rolling.
>
>Best Regards,
>
>Kent
>--------------------------------
>Requirement                                         SMTP  NNTP HTTP FTP
>1. Ordered Delivery of Data Objects                        X
>2. Client Can Send and Receive Data Objects                X    X    X
>3. Server Data Object Enumeration                          X         X
>4. Nexting Support for Data Objects                        X         X
>5. Nexting Support for Enumerations(Partial Lists)
>6. Batch and Conversational Models of Operation
>7. Connection-oriented Service with Strong Security             X
>8. Possible to Record and Audit Individual Activities X*   X*   X*   X*
>9. Possible to Enumerate Services Implemented         X    X    X
>10. Documents/Services based on User ID                    X         X*
>11. Protocol NOT Limited to Specific
>    Application Domain                                X         X    X
>12. Negotiated Possibility to Send
>    to Server at Startup                                   X
>
>* = Implementation-specific Capability
>--------------------------------
>
>Kent Schwab                     Email: kent@actracorp.com
>Actra Business Systems               Tel#: 1.408.542.3277
>610 Caribbean Drive                  Fax#: 1.408.542.3210
>Sunnyvale, CA  94089