W3C home > Mailing lists > Public > public-webpayments@w3.org > July 2014

Re: HTTP Signatures draft published at IETF

From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Tue, 29 Jul 2014 06:56:09 +0200
Message-ID: <CAKaEYhJdj7O1bvh1TsB8qSwaS0YOC0qtkpnjeAk98LCX02CsmQ@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: Kingsley Idehen <kidehen@openlinksw.com>, public-webpayments <public-webpayments@w3.org>, Blaine Cook <romeda@gmail.com>, Manu Sporny <msporny@digitalbazaar.com>
On 28 July 2014 02:12, Mark Nottingham <mnot@mnot.net> wrote:

> They're not invalid, but establishing the context of the link is a bit
> tricky (since the payload of a request is usually anonymous; i.e., it
> doesn't have a URI).
>

Could the payload be anonymous and also have a "dns" URI as per:

http://tools.ietf.org/html/rfc4501


>
>
> Whether that matters or not depends on what you're doing.
>
> Cheers,
>
>
> On 27 Jul 2014, at 6:27 am, Kingsley Idehen <kidehen@openlinksw.com>
> wrote:
>
> > On 5/9/13 8:05 PM, Mark Nottingham wrote:
> >> Hi,
> >>
> >> From's semantics and syntax are well-defined, and they are in use. If
> you want to do this, I'd suggest defining a new header, or a new link
> relation (to use in Link); From isn't going to fly.
> >>
> >> Regards,
> >
> > All,
> >
> > Coming back to the issue above, is the use of "Link:" in HTTP requests
> valid? I ask because, It could resolve this issue in a way that prevents
> custom header bloat.
> >
> > Regards,
> >
> > Kingsley
> >>
> >>
> >> On 09/05/2013, at 7:18 PM, ☮ elf Pavlik ☮ <
> perpetual-tripper@wwelves.org> wrote:
> >>
> >>> Excerpts from Kingsley Idehen's message of 2013-05-08 20:29:19 +0000:
> >>>> On 5/7/13 2:12 PM, Melvin Carvalho wrote:
> >>>>> On 7 May 2013 19:01, Manu Sporny <msporny@digitalbazaar.com
> >>>>> <mailto:msporny@digitalbazaar.com>> wrote:
> >>>>>
> >>>>>    On 05/07/2013 04:04 AM, Melvin Carvalho wrote:
> >>>>>> Yeah, I'll ping Julian Reschke or Mark Nottingham about it to see if
> >>>>>> we can update the HTTP header field easily.
> >>>>>>
> >>>>>> +1
> >>>>>>
> >>>>>> There have been proponents of this for many years e.g. Toby, Nathan,
> >>>>>> Kingsley, myself ... just need to get the spec tweaked to
> >>>>>> distinguish between strings and URIs.
> >>>>>    Do one of you want to take the lead on this? :)
> >>>>>
> >>>>>
> >>>>> Sure, I would be happy to.  Kingsley already asked Mark Nottingham
> >>>>> about this last month.  Im unsure what the most productive next steps
> >>>>> should be.
> >>>> Mark,
> >>>>
> >>>> Another dimension to the same issue.
> >>>>
> >>>> We can loosen the HTTP spec requirements for "From:" without
> disrupting
> >>>> existing products that assume the header value is an Email address.
> >>>>
> >>>> All:
> >>>>
> >>>> Do we have any data about how broad current use of "From:" actually
> is?
> >>> +1 on allowing URI in "From:" request header :)
> >>>
> >>> I set it myself to email for about 2 years now using firefox
> extension: http://www.garethhunt.com/modifyheaders
> >>>
> >>> I also mentioned it in this email with link to work of Blaine Cook on
> *Privacy-over-Webfinger*
> >>>
> https://groups.google.com/group/webfinger/browse_thread/thread/52599662c273a043
> >>>
> >>> warning: mentioned thread got mixed with another thread so few
> messages went off topic first!
> >> --
> >> Mark Nottingham   http://www.mnot.net/
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> > --
> > Regards,
> >
> > Kingsley Idehen
> > Founder & CEO
> > OpenLink Software
> > Company Web: http://www.openlinksw.com
> > Personal Weblog 1: http://kidehen.blogspot.com
> > Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
> > Twitter Profile: https://twitter.com/kidehen
> > Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
> > LinkedIn Profile: http://www.linkedin.com/in/kidehen
> > Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this
> >
> >
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
>
>
>
Received on Tuesday, 29 July 2014 04:56:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:32 UTC