RE: Draft State Finding

Ed,

 

I've gone through your comments and done a bunch of updates which I'll
post separately.  There are so many updates that I've chosen to not call
out every place that I did something to the doc based on your comments.
Where I did have questions/or disagreed, I've said something inline
below so I think I've addressed all of them.  It's probably worth
another read by you.

 

Cheers,

Dave

 

________________________________

From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf
Of Rice, Ed (ProCurve)
Sent: Friday, March 03, 2006 2:38 AM
To: www-tag@w3.org
Subject: 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.  

<<DBO>> Not sure what you mean.  Do you mean transitory/transient?  If
so, I'm not sure I want to go into the transient vs durable states.  It
threatens to add another complexity, thought it may be unavoidable.

*	Security is 'sort of' addressed at the end of the document.. But
I'd really like to see it throughout.

<<DBO>> the problem is that each property can be talked about
throughout, which would end up suggesting that the definitions of the
properties should be towards the front of the document, which would
conflict with my goal of making the document less "definitional" at the
front.  I'm open to suggestions.

*	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).

<<DBO>> As we talked about, I've done some updates but retained the
banking app.  

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"

<<DBO>> rewrote to talk about components and pulled in the foldoc
definition.

*	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.

<<DBO>> you are the 2nd person to mention this.  I thought it was very
clever word play..

		*	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.

<<DBO>> OK, but how do I say there is a firefox extension that does this
when there isn't the same thing for IE?  

		*	and the last sentence 'This is a fairly
extensive" contradicts with your earlier statement that browser states
are a minor state.

<<DBO>> I don't think I say "minor", I think I say related to the amount
of information the client has typed in or configured, which I think is
not contradictory.  

		*	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.

<<DBO>> That's just what FOLDOC says

		*	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...

<<DBO>> Added a couple sentences on stateful server benefits and banking
systems...

	*	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.

<<DBO>>I agree, I wanted to do that in the first place but I was lazy...

		*	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).

<<DBO>> OK

	*	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..)

<<DBO>>OK, done some additions

	*	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.

<<DBO>>, I've been trying to keep away from *ALL* of the details but I
think that's worthy.

	*	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 ;)

<<DBO>>Noted and added.

	*	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

<<DBO>> OK.  I had combined it before, then split it but the split just
never worked.

	*	7.4 - rename to Performance & Scalability

		*	Who is Jim Grey?  

<<DBO>> Mr. Transactions.  I've added a reference to his "five minute
rule" in the references.

		*	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.

<<DBO>> I've made that distinction.  

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

-Ed