10:34 a.m.
This is a multi-part message in MIME format.
--------------040008030508030100010909
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
On 04/16/2012 03:31 PM, Geert Jansen wrote:
On 04/16/2012 01:03 PM, Yaniv Kaul wrote:
>> So (unless someone objects) let's go for option #2 (using the Prefer
>> header on each and every request, and release the session once it is
>> not there).
>
> My only objection is that you implement a draft spec and implement a
> header without even bothering to register it - or asking if there is
> such an identical-purposed header with a different name which may get
> registered / is already in use somewhere.
This is somewhat of a red herring though.
HTTP Prefer was created exactly for the purpose of indicating a
preference for a certain behavior of response. Have a look at section
9.1.1 of the draft RFC for the initial preferences and you'll see the
preferences that are already registered.
HTTP Prefer also defines a registration process for the possible
values of this header. The process requires an email to
preferences(a)ietf.org with a 14 day response time.
The alternative to HTTP Prefer would be creating a new header (as i am
not aware of any other /approved/ header that fits the bill). This
requires writing an RFC and get it approved, which would take much
longer, and which would likely get the comment of "Why aren't you
using Prefer".
I'm more worried about "persistent-auth" than 'prefer'. We could
always
contact the draft author (jasnell(a)gmail.com) and ask for his opinion.
Y.
Even if HTTP Prefer, for whatever reason, unexpectedly does not become
a standard, i think in practice this does not impact us in any way.
Regards
Geert
--------------040008030508030100010909
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 04/16/2012 03:31 PM, Geert Jansen wrote:
<blockquote cite="mid:4F8C112F.1060703@redhat.com"
type="cite">
<br>
On 04/16/2012 01:03 PM, Yaniv Kaul wrote:
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">So (unless someone objects) let's go
for
option #2 (using the Prefer
<br>
header on each and every request, and release the session once
it is
<br>
not there).
<br>
</blockquote>
<br>
My only objection is that you implement a draft spec and
implement a
<br>
header without even bothering to register it - or asking if
there is
<br>
such an identical-purposed header with a different name which
may get
<br>
registered / is already in use somewhere.
<br>
</blockquote>
<br>
This is somewhat of a red herring though.
<br>
<br>
HTTP Prefer was created exactly for the purpose of indicating a
preference for a certain behavior of response. Have a look at
section 9.1.1 of the draft RFC for the initial preferences and
you'll see the preferences that are already registered.
<br>
<br>
HTTP Prefer also defines a registration process for the possible
values of this header. The process requires an email to
<a class="moz-txt-link-abbreviated"
href="mailto:preferences@ietf.org">preferences@ietf.org</a> with a 14
day response time.
<br>
<br>
The alternative to HTTP Prefer would be creating a new header (as
i am not aware of any other /approved/ header that fits the bill).
This requires writing an RFC and get it approved, which would take
much longer, and which would likely get the comment of "Why aren't
you using Prefer".
<br>
</blockquote>
<br>
I'm more worried about "persistent-auth" than
'prefer'. We could
always contact the draft author (<a class="moz-txt-link-abbreviated"
href="mailto:jasnell@gmail.com">jasnell@gmail.com</a>) and ask for his
opinion.<br>
Y.<br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<blockquote cite="mid:4F8C112F.1060703@redhat.com"
type="cite">
<br>
Even if HTTP Prefer, for whatever reason, unexpectedly does not
become a standard, i think in practice this does not impact us in
any way.
<br>
<br>
Regards
<br>
Geert
<br>
</blockquote>
<br>
</body>
</html>
--------------040008030508030100010909--