Re: Draft State Finding

David,

Some feedback on the State Finding;

1.	 Overall: 

*	Good document!
*	 I'd like to see you include some work on transitional states
vs. session states as well.  
*	Security is 'sort of' addressed at the end of the document.. But
I'd really like to see it throughout.
*	I would choose a different example other than banking.  Banking
has lots of new regulation (in the states) which makes most of the
options 'not' an option.  Also, the two factor authentication which is
now being required isn't really addressed in your document. (This is
fine because its not an authentication styles document, but it makes the
example look odd).

2.     more editorial comments;

*	Section 2 

	*	'State is the data that pertains to an entity - I think
you should define Entity
	*	'most interesting' could probably be changed to 'most
personalized'
	*	Kinds of state section 2 - you should probably split out
'sub state' as a separate type or else remote it.  I'm not sure I agree
that things like bank-account numbers should be stored in a URI as that
would be a huge privacy concern since the URI's are not encrypted.  I
could look on your web-proxy and find out your bank account numbers.
	*	section after bullet 3 - non state is not interested..
maybe you should just say not addressed.  I can think of several
'interesting' URI references that likely have no state.
	*	typo : "stateless are actually incorrect characterized"
should be "incorrectly characterized"

*	Section 3

	*	'The state in an application may exist across a large
variety of applications' is bad grammar and not likely what you intended
to say.  Should it be more along the lines of "A users 'state' may exist
across a large variety of applications'?
	*	you use the word 'prototypical' in the document, should
it be stereotypical instead?
	*	The last sentence "despite many years of best efforts"
is a good point, however these states are normally pooled or
transitional only.
	*	3.1

		*	this is a nit.. "it is important for our
analysis to state" seems funny to state things about a state document.
Could you change the word to 'point out'.. might translate better.
		*	I would drop the reference to firefox.  I think
in the TAG we should be careful not to appear to endorse or condemn a
particular product but stick with practices.
		*	and the last sentence 'This is a fairly
extensive" contradicts with your earlier statement that browser states
are a minor state.
		*	The discussion on Cookies is good (last
paragraph) but you should point out types of cookies, cookie size
limitations as well as privacy concerns with cookies in general vs.
types of information stored in cookies.

	*	3.2

		*	"an example of a stateless server is a
World-Wide web server." - this short sentence appears to imply no state
in a web server?  I don't think you intended to portray this.
		*	on the server side, I'd really like to see more
on considerations such as Performance, uptime, scalability, fail-over.
You do some of this later, but it appears out of place...

	*	4.0 Decisions.

		*	I don't really like your decision boxes.  I'd
rather see this as a decision tree.  Fact is most high-end applications
have more than one type of session state which doesn't appear to be
addressed at all.
		*	nit : I would word smith the 'we almost never
choose'
		*	'we exclude the possibility of expressing state
in the protocol operation or method'.. I don't disagree, but you should
explain why.

	*	5.1

		*	Again, need to change example.  Banking isn't a
good choice.
		*	I would at least mention the need for SSL.  I
know its not a security discussion but I could see people using this doc
to design state and not take into account the security issues (aka
privacy issues).

	*	5.2

		*	I would change the 'It is not clear" to "there
is some debate over"

	*	5.3

		*	This section didn't work for me at all.  Many
URI's contain session state.. if you bookmark the URI and the session
has expired the systems redirect you to a sign-on page and then back to
the referrer URI.  I think there are good reasons not to use URL, but
your mostly they are around security and privacy. (also transparency,
fail-over, etc..)

	*	5.4

		*	There are two types of cookies, session and
disk.  You appear to assume disk only.  Session cookies are stored in
memory and are transient.

	*	5.6

		*	I don't think you can have this discussion
without talking about security of cookies and why you wouldn't want to
write things like a users account number + name + address in a cookie.
		*	in the 'Second Design".. a URL example would be
helpful, I had to read a few times to understand what you were saying.
		*	the paragraph 'It does suffer from..." doesn't
really ring true for me.  Most deep linking applications intercept the
call and generate the page from the contents of the URI and don't
reference a real physical http document.  Also, I would point out that
things like storing your account number in a URI is a bad practice (do I
seem a little security concerned ;)

	*	6.1

		*	I would change the title to 'Non-SOAP XML
examples'
		*	In example 9 there seems to be nothing from
someone generating a program which scrolls through 'session ID' numbers
to get account information.  Session state has to be more than a
reference in the xml.

	*	6.2

		*	Alternatively, the CustomerKey could be
encoded..  I agree, but you should state the advantages to this or did
you just want to point it out as an alternative?

	*	6.4

		*	I would point out the use of HTTPS with secure
web services.  A lot of people don't seem to know this is an option.

	*	7

		*	I'd make this a decision tree.
		*	I agree with Roy Fielding by the way.

	*	7.3 - I'd drop this section, combine it with 7.4
	*	7.4 - rename to Performance & Scalability

		*	Who is Jim Grey?  
		*	This would be a good place to talk about tiered
architectures for web services.
		*	I'd assert that the curve really isn't flat for
long, its more of a logarithmic line.  Starts out relatively flat,
slowly increases until wow, its slow :)
		*	Can you define 'Write-Through' cache?

	*	7.5

		*	My architectures also assume the software can
fail.  That makes three aspects; hardware, software and network.

Great work, if you'd like any help making these changes I'd be more than
happy to chip in.
-Ed