W3C home > Mailing lists > Public > public-webid@w3.org > May 2013

Re: Archaic HTTP "From:" Header

From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Mon, 27 May 2013 14:29:16 +0200
Message-ID: <CAKaEYhJSccAjn9cqGHcmkKV40ERvn5j3cdgoMBCCat_qSGOHkQ@mail.gmail.com>
To: mike amundsen <mamund@yahoo.com>
Cc: Kingsley Idehen <kidehen@openlinksw.com>, "public-rww@w3.org" <public-rww@w3.org>, "public-webid@w3.org" <public-webid@w3.org>
On 27 May 2013 14:17, mike amundsen <mamund@yahoo.com> wrote:

> Register "webid" as a Link Relation Value and ese the LINK header as in
> Link: <http://...." rel="webid">
>
> This will make sure you don't step on someone else's header, no-one will
> step our yours. This will also allow you to include it in the header and
> (when appropriate) include it within a message body.
>

That could work so how about

[[
WebID<https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p2-semantics.html#header.from>

The "WebID" header field contains a URI for a user who controls the
requesting user agent.

  WebID    = user

  user = [[ Text linking to URI spec]]

An example is:

  WebID: http://example.org/alice#me <webmaster@example.org>

A user agent *SHOULD NOT* send a WebID header field without explicit
configuration by the user, since that might conflict with the user's
privacy interests or their site's security policy.
Servers *SHOULD NOT* use the WebID header field for access control or
authentication, without extra out of band entropy, such as a shared secret
contained in the URL query string or a cookie.

]]


>
>
> mamund
> +1.859.757.1449
> skype: mca.amundsen
> http://amundsen.com/blog/
> http://twitter.com/mamund
> https://github.com/mamund
> http://www.linkedin.com/in/mikeamundsen
>
>
> On Mon, May 27, 2013 at 7:18 AM, Melvin Carvalho <melvincarvalho@gmail.com
> > wrote:
>
>>
>>
>>
>> On 3 April 2013 19:18, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>>
>>> All,
>>>
>>> I think the HTTP "From:" header [1] is now truly archaic circa. 2013. If
>>> the range of this particular predicate was a URI it would really aid our
>>> quest for a RWW.
>>>
>>> Suggestion:
>>>
>>> As part of our RWW bootstrap effort, we could consider an "X-From:"
>>> header that basically takes a URI or Literal value.
>>>
>>> I think we can flesh this out across WebID and RWW via implementations
>>> before moving up to TAG and IETF.
>>>
>>> Mark: what do you think, anyway ? :-)
>>>
>>
>> After some investigation on this:
>>
>> Here is the current text, which is slightly different from the RFC
>>
>> [[
>> 5.5.1<https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p2-semantics.html#rfc.section.5.5.1>
>>  From<https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p2-semantics.html#header.from>
>>
>> The "From" header field contains an Internet email address for a human
>> user who controls the requesting user agent. The address ought to be
>> machine-usable, as defined by "mailbox" in Section 3.4<http://tools.ietf.org/html/rfc5322#section-3.4>of
>> [RFC5322]<https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p2-semantics.html#RFC5322>:
>>
>>
>>   From <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p2-semantics.html#header.from>    = mailbox <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p2-semantics.html#header.from>
>>
>>   mailbox <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p2-semantics.html#header.from> = <mailbox, defined in [RFC5322] <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p2-semantics.html#RFC5322>, Section 3.4 <http://tools.ietf.org/html/rfc5322#section-3.4>>
>>
>> An example is:
>>
>>   From: webmaster@example.org
>>
>> The From header field is rarely sent by non-robotic user agents. A user
>> agent *SHOULD NOT* send a From header field without explicit
>> configuration by the user, since that might conflict with the user's
>> privacy interests or their site's security policy.
>>
>> Robotic user agents *SHOULD* send a valid From header field so that the
>> person responsible for running the robot can be contacted if problems occur
>> on servers, such as if the robot is sending excessive, unwanted, or invalid
>> requests.
>>
>> Servers *SHOULD NOT* use the From header field for access control or
>> authentication, since most recipients will assume that the field value is
>> public information.
>>
>> ]]
>>
>> 1. "From" seems to be largely unused according to various sources
>>
>> 2. Some people are already using "From" for http URIs
>>
>> 3. From my informal straw poll more people are in favour of using HTTP
>> URIs in From than against (roughly 2 to 1), though those against seem to be
>> strongly against
>>
>> 4. It may be possible to use another header, but that is less intuitive,
>> and we will need suggestions
>>
>> 5. It was pointed out that, what later became known as "WebID" stuffed an
>> HTTP URI in the header field.
>>
>> 6. The User-Agent field is used by spiders such as baidu and google to
>> give an HTTP URI
>>
>> IMHO, this is a valuable use case for identifying on the web, without a
>> dependency on X.509 certs which are (at least perceived as) very hard to
>> deploy.  If you want strong security use TLS but it need not be mandatory
>> for more casual usage.  A use case might be to get a casual social web
>> going eg via the tabulator extenstion
>> So the question is which header to use for identity on the web ...
>>
>>
>>>
>>> --
>>>
>>> Regards,
>>>
>>> Kingsley Idehen
>>> Founder & CEO
>>> OpenLink Software
>>> Company Web: http://www.openlinksw.com
>>> Personal Weblog: http://www.openlinksw.com/**blog/~kidehen<http://www.openlinksw.com/blog/~kidehen>
>>> Twitter/Identi.ca handle: @kidehen
>>> Google+ Profile: https://plus.google.com/**112399767740508618350/about<https://plus.google.com/112399767740508618350/about>
>>> LinkedIn Profile: http://www.linkedin.com/in/**kidehen<http://www.linkedin.com/in/kidehen>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
Received on Monday, 27 May 2013 12:29:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:54:43 UTC