Re: [http-state] http-state Digest, Vol 1, Issue 1

[John Kemp <[e-mail]>]

On Jan 9, 2009, at 3:15 PM, Micah Tapman wrote:

> Speaking to the "browser" idea, and expanding on the libcurl comment  
> from
> Daniel, I think we should consider changing the terminology to  
> something
> like "client object" instead of "browser".

I think you'd probably want to use 'user-agent', according to the  
definition from the HTTP 1.0 specification [1] , and which is already  
also used by RFC2109 [2] referencing [1].

> "The client which initiates a request. These are often browsers,  
> editors, spiders (web-traversing robots), or other end user tools."

Regards,

- johnk

[1] http://www.w3.org/Protocols/HTTP/1.0/spec.html#Terminology
[2] http://www.ietf.org/rfc/rfc2109.txt
>
>
> Micah
>
> -----Original Message-----
> From: [e-mail] [mailto:http-state- 
> [e-mail]] On
> Behalf Of [e-mail]
> Sent: Friday, January 09, 2009 3:00 PM
> To: [e-mail]
> Subject: http-state Digest, Vol 1, Issue 1
>
> Send http-state mailing list submissions to
> 	[e-mail]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www.ietf.org/mailman/listinfo/http-state
> or, via email, send a message with subject or body 'help' to
> 	[e-mail]
>
> You can reach the person managing the list at
> 	[e-mail]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of http-state digest..."
>
>
> Today's Topics:
>
>   1. Welcome to http-state (Bil Corry)
>   2. Re: Welcome to http-state (Daniel Stenberg)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 09 Jan 2009 12:08:25 -0600
> From: Bil Corry <[e-mail]>
> Subject: [http-state] Welcome to http-state
> To: "[e-mail]" <[e-mail]>
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset=UTF-8
>
> It appears the subscriptions have subsided, so thank you to everyone  
> who has
> joined so far.
>
> == First, some background history ==
>
> Some time ago on OWASP's Intrinsic Security list, I brought up the  
> issue of
> HTTPOnly not being consistently implemented (or lacking implementation
> altogether) across the major browsers, based mostly on OWASP's  
> HTTPOnly
> resource page:
>
> 	http://www.owasp.org/index.php/HTTPOnly#Browsers_Supporting_HTTPOnly
>
> Jim Manico responded that he was actively promoting HTTPOnly  
> implementation
> to various browsers and welcomed help to do more.  In that  
> conversation, we
> agreed that a uniform specification would probably be beneficial for  
> the
> browser vendors and we started a group to do so.  In promoting the  
> group
> across various lists, I consistently received feedback that  
> *cookies* needed
> a specification, and why were we bothering with HTTPOnly.  This  
> group at
> IETF is the result of our decision to take on the entire cookie  
> spec, not
> just HTTPOnly.
>
>
>
> == Goal for this group ==
>
> Ultimately, the purpose of this group is to create an updated HTTP  
> State
> Management Mechanism RFC (aka cookies) that will supersede the  
> Netscape
> spec, RFCs 2109, 2964, 2965 then add in real-world usage (e.g.  
> HTTPOnly),
> and possibly add in additional features and possibly merge in
> draft-broyer-http-cookie-auth-00.txt and draft-pettersen-cookie- 
> v2-03.txt.
>
> I'm assuming an update to bcp44 is probably needed as well, but  
> truthfully I
> haven't looked at it.
>
> Did I miss anything relevant to creating an update cookie RFC?
>
>
>
> == Creating a Working Group ==
>
> In order to create a RFC, we need a Working Group.  In order to  
> create a
> Working Group, we need enough interested people to join a BOF at an  
> IETF
> meeting and to volunteer to help run the Working Group:
>
> 	http://www.ietf.org/tao.html#rfc.section.6
>
> I'll be attending the next IETF meeting and don't mind taking on the  
> role of
> Working Group Chair, but I will need others to also attend, lend  
> support and
> volunteer for the various responsibilities required.
>
> The next IETF meeting is March 22-27, 2009 in San Francisco:
>
> 	http://www.ietf.org/meetings/74/
>
> If you will be attending, please let me know.  I'll approach Lisa  
> Dusseault
> about having a BOF at the next IETF meeting and would like to give  
> her an
> idea of how many people are already interested in it.
>
>
>
> == Initial first steps ==
>
> While we work on forming a Working Group, we can start the actual RFC
> process now by working on creating an Internet Draft:
>
> 	http://www.ietf.org/tao.html#rfc.section.8.1
>
> There are a few ways to get started; I'm thinking that taking an  
> inventory
> of what is wrong or missing from RFC2109 as compared to the "real  
> world" may
> be a good place to start.
>
> Thoughts?
>
>
> - Bil
>
>
>
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 9 Jan 2009 20:02:48 +0100 (CET)
> From: Daniel Stenberg <[e-mail]>
> Subject: Re: [http-state] Welcome to http-state
> To: Discuss HTTP State Management Mechanism <[e-mail]>
> Message-ID: <[e-mail]>
> Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
>
> On Fri, 9 Jan 2009, Bil Corry wrote:
>
>> 	http://www.owasp.org/index.php/HTTPOnly#Browsers_Supporting_HTTPOnly
>
> While not being a browser, libcurl is a HTTP library that supports  
> cookies
> and
> even HTTPOnly ones and it is used in browsers (and browser-like
> applications)
> at times.
>
>> There are a few ways to get started; I'm thinking that taking an  
>> inventory
>
>> of what is wrong or missing from RFC2109 as compared to the "real  
>> world"
> may
>> be a good place to start.
>
> It sounds like a fair way to get started, but RFC2109 is quite far  
> away from
>
> how cookies work in real life so the differences are going to be
> substantial.
>
> -- 
>
>  / daniel.haxx.se
>
>
> ------------------------------
>
> _______________________________________________
> http-state mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/http-state
>
>
> End of http-state Digest, Vol 1, Issue 1
> ****************************************
> _______________________________________________
> http-state mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/http-state

_______________________________________________
http-state mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/http-state