RE: ftp scheme

I like ftp mostly because its inoffensive. Give it to most URI resolvers in
a server lib , it will work as a transport for files. It not ftp I like, its
that for little effort it proves multi-protocol'ness readiness - and an
attitude of ensuring that brand new webid will work for 5+ years of legacy
web (too). It helps show the limits of current conceptions. If the limits
are drawn too tight (for almost any reason, including time resources), you
know where a movement is on the adoption curve. Its still pitching the
revolution, often - which only appeals to folks interested in the leading
tail of the adoption curve.

-----Original Message-----
From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org]
On Behalf Of Jeff Sayre
Sent: Tuesday, April 19, 2011 9:23 AM
To: nathan@webr3.org
Cc: jeff@sayremedia.com; Mo McRoberts; Henry Story; WebID XG
Subject: Re: ftp scheme

Okay, with just two others besides myself chiming in, I can see that we are
already wasting time debating this issue. So, unlike with political
elections, I can change my vote.

I rescind my +1 and will go back to a neutral state.

Focus is what is key. Adding more to our plate has become a distraction.
Frankly, I'm beginning to get overwhelmed with email overload again.

The most pressing WebID IG issue, as far as I'm concerned, is finishing the
Position Paper for the upcoming W3C's Identity in the Browser workshop (
http://www.w3.org/2011/identity-ws/ ). The submittal deadline is this
Friday.

How many of you have taken the time to read over our position paper?

https://docs.google.com/document/d/1L-PhczWNSciUIRCfsK92wRbxJEU1kKSwUcxFSz3D
Au0/edit?hl=en&authkey=CJv5nPIJ#


Jeff





> Jeff Sayre wrote:
>>> On 19 Apr 2011, at 16:08, Henry Story wrote:
>>>
>>>> If people are for that please +1 and I'll add it as an issue.  When 
>>>> done we can have a vote to open it too, the idea being to look at 
>>>> the spec and see how it needs to be rewritten for ftp (and hence 
>>>> made generic enough for other existing or yet to be URI schemes)
>>>
>>> While it's not a terrible proof-of-concept, and this isn't quite 
>>> what you asked, it'd get a -1 from me as anything beyond a *pure
>>> proof-of-concept*
>>> places a hugely disproportionate burden on server implementors 
>>> further on down the line.
>>>
>>> M.
>>>
>>
>> That may be an issue, but Henry was asking a simpler question (which 
>> it seems you acknowledged as well). I agreed that it should be added 
>> as an issue, that it should be brought up for a vote. That is all.
>>
>> Of course we need to stay narrowly focused at this time, working on 
>> our simple proof of concepts and test implementations. We cannot 
>> focus on every issue at the same time. Focus requires paying 
>> attention to just a few details.
>>
>> So, if this issue is going to distract us from our focus, then we 
>> should pass. But, if it is something that people feel should be added 
>> as an issue for a vote and later consideration, then I'm for it as it 
>> is one of the simpler non-HTTP schemes to address with WebID.
>
> huge -1 from me, http(s):// is fine, mailto: would be nice and perhaps 
> if we really wanna scrape the barrel with something people actually 
> still use, ldaps. Speaking of schemes for webids here.
>
> saying that, I'll happily give a huge +1 to showing webid working with 
> other transfer protocols like ftp and websockets, pop3 over ssl, scp, 
> *+ssh - but that's a very different issue.
>
> and finally, if we really really want to look to support any uri at 
> all with any scheme, then spend some time thinking about directory / 
> profile lookup services instead, one solution to cover them all.
>
> cheers,
>
> nathan
>

Received on Tuesday, 19 April 2011 16:49:47 UTC