W3C home > Mailing lists > Public > www-tag@w3.org > June 2006

Notes from my review of the 'state in web application design'..

From: Rice, Ed (ProCurve) <ed.rice@hp.com>
Date: Sun, 11 Jun 2006 19:28:37 -0700
Message-ID: <7D6953BFA3975C44BD80BA89292FD60E04E656A5@cacexc08.americas.cpqcorp.net>
To: <www-tag@w3.org>

A few notes.. Many are editorial :)

1)  Abstract; extra period at the end 
2)  You should put a link from FOLDOC, you do reference a hyperlink
would be more appropriate as your citing it as a reference.
3)  Not sure how 'hardware things' in section 2 is relevant.  You do
talk about hardware for balancing and architectural implications, but
hardware/state is still not clear.
4)  Section 2, you never explain how a network message could have state
in itself.
5)  Section 2, 'Most interesting,...' reads funny.
6)  section 3.1 "the web browser is 'one half'".. Maybe a 'Major
Component' would be a better reference than 1/2.
7)  Section 3.1.  I'm not sure that the application that stores state is
therefore statefull.. (your reference to the browsers).
8) I'd remove the firefox reference, it will date the document.
9) Section 3.2 you define refer to WWW Servers as stateless, if a
browser is stateful because it stores stated, wouldn't www servers also
be stateful because they manage state?
10 Section 3.2 typo: "Manages states is a server" should be "managers
state resides on a server"?
11) Section 3.2 typo: ". With no opening quote.
12) Section 3.2 you seem to loose the point at the end.. May be over
edited ?
13) I still think Roy's point is valid, but your extending it.  I don't
see Roy's point and your paper in conflict per say.  You may want to
re-word this to explain "while Roy's point is valid, this paper
suggests..."
14) In 4.1: What is JAX-RPC? (reference would be helpful).
15) In 4.1: "there are no standards' could be 'there are currently no
standards' :)
16) in 4.2 you may want to point out that session ID's should not be
sequential.
17) In 4.2 you refer to account numbers or personal information.  I like
to define this as any user identifiable information (includes, name,
phone, ssn, company etc..)
18) In 4.2 you may want to mention the session cookies vs sticky
cookies.
19) In 4.3 "middleware of some kind" could be 'a middleware layer or an
n-tiered architecture"
20) In 4.3 you may want to define 'cheaper' the first time as less
resource intensive.
21) 4.3 still has two TBD's which should be completed.
21) 4.3 you call out 'linear decay' I believe its more important that
it's a 'predictable decay'.
22) 4.4: I disagree that networks are inherently unreliable.  They are
no more unreliable than a computer system or than software.  We design
for redundancy in software, hardware and networks.  In fact, the
networks play a major role in reliability.
23) 4.4; 'Related to reliability' is an odd design paragraph.  You must
design for active fail-over to achieve reliable systems and consistent
user experiences.  Having to 'drain' a system implies that you don't
have fail-over.
24) 4.4 I'd remove the 'on the other hand'.. Seems to substantially
weaken the paragraph.
25) 4.5 TBD
26) section 5, the flowcharts look good, but the start and ends need to
be defined.  Also, they don't print well because they're too wide, you
could split this into two diagrams and table them side by side so they
would view the same but print better.
27) Section 5, why the browser stores 'username/password'?  This is only
in HTTP authentication and not in the broader sense unless forms
complete is turned on.
28) section 8.1:  When any banking URI is requested, the
username/password features of http are used, usually implemented as a
pop-up window.. I've never seen a bank do this, it wouldn't pass federal
regulators since the user/password are transmitted in the clear (I know,
I'm working on it :).  Its probably worth pointing out that HTTP
authentication in this manor is not secure.
29) Section 8.4.. I don't like.  The sending the account number in the
URI makes two factor authentication now a s single factor.  The
repeatable URI can be derived for a session state as well.  For example;
http://mybank.com/checks/12345 could be a uri to a given check but the
bank account number could be taken from the session instead of the URI.
This may violate the one uri for one resource (since another user with
this same URI would see a different check) but it allows for bookmarking
resources.
30) Section 9.3 - need to point out the importance of https with web
services as well.  Imbedding information in a soap document and then
transferring it over the wire with normal http would expose all content
to the network.
31) Section 10;  I'm still looking for the 'preferred method' or at
least some sort of statement that some are bad, leaving these as ok and
when they should be used.

Sorry for the long list.  It's a long document and its really very good.

-Ed
Received on Monday, 12 June 2006 02:28:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:40 GMT