Re: ftp scheme

> I am happy with ftp and ftps schemes because they are easy to implement with what we have now. 
> (Ie: It does not mean implementing new parsers, redirect schemes, transforms, as webfinger would for example) 
> 
> As you say ftp urls lack content negotiation, which means of course a small but interesting problem. The receiver will have to do content inspection just for that to guess what the format is. 
> 
> It is pretty easy to see here how by solving those issues and testing them ftp urls would become a well documented part of webid. (I would nearly suggest it is so easy to see I am surprised anyone would doubt that we are not schema agnostic) Now it might be a good stimulus to help us change the specificiation somewhat so that we can spot those parts that are too URI specific.
> 
> I don't really see the use case for this, since anyone who has an ftp server can get an http server. FTP was really important when the web came to be because then the difficulty of acquiring http was a lot greater comparatively. On the other hand the amount of work to do ftp should be pretty minimal.
> 
> 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)
> 

-1 from me too. I think there are more urgent matters at hand, and there
is no point assigning resources (time) to another scheme. Fix the
current issues, and only then increase the scope of WebID.

Andrei

> 
> Henry
> 
> 
> > 
> > 
> > 
> > -----Original Message-----
> > From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org]
> > On Behalf Of Henry Story
> > Sent: Tuesday, April 19, 2011 7:26 AM
> > To: peter williams
> > Cc: 'Mo McRoberts'; 'Kingsley Idehen'; public-xg-webid@w3.org
> > Subject: Re: self-signed
> > 
> > 
> > On 19 Apr 2011, at 15:54, peter williams wrote:
> > 
> >> Im just seeing filibuster, delay and a degree of specious argument, on 
> >> this issue
> > 
> > The people who are trying to implement tests, get things working, keep
> > things simple are filibustering? And the ones with mile long e-mails that
> > bring issues always outside the space are the ones doing the serious work?
> > 
> > Fillibuster:
> > a. the use of irregular or obstructive tactics by a memberof a legislative
> > assembly to prevent the adoption of ameasure generally favored or to force a
> > decision againstthe will of the majority.
> > b. an exceptionally long speech, as one lasting for a day or days, or a
> > series of such speeches to accomplish thispurpose.
> > c. a member of a legislature who makes such a speech.
> > 
> > That is why I suggest we stop this chatter, and start with real tests. We
> > have 50 issues on the table that you brought up. Now we are working bottom
> > up.
> > 
> >> 
> >> We discussed this topic in setting up the group - that we were about 
> >> more than http URIs.
> > 
> > Yes, I even wrote up how that works on
> > http://www.w3.org/wiki/Foaf%2Bssl/FAQ#How_does_Secure_Authentication_Work_wi
> > th_FOAF.2BSSL.3F
> > 
> > And you can get the philosophical details in the talk "Philosophy of the
> > Social Web"
> > which is available on my home page http://bblfish.net/
> > 
> >> We wanted to ensure we were not a linked data group (without denying 
> >> the legitimacy of that movement).
> > 
> > We are setting foundations for Linked Data, but we restricted ourselves on
> > purpose to start off with to identity, the part that does not require more
> > of linked data than dereferencing the WebID. Well with webfinger we get a
> > bit more linked data, as you have to do 2 dereferencings, one following the
> > other. But linked data and linked pages is the whole point of WebId of
> > course. If you think that is silly then you are in the wrong group.
> > 
> >> We wanted to ensure we did not
> >> fall into the political space that RDF typically falls into, whose 
> >> feedback properties ensure the failure of adoption. We did want to be 
> >> puritans, that is - "induced" to leave England (and even Holland), 
> >> because their literalness in positions of power caused 50 years of 
> >> constant war (to use a historical reference).
> > 
> > We are just trying to be Web friendly. For some that is being puritain
> > though, but not at the W3C.
> > I myself have no trouble with the semantic web, xml and other formats. The
> > current spec even is open to working with many other formats. It's just
> > worth us getting what we have going before we move on. 
> > 
> >> 
> >> 
> >> What I want to see is any non http URI adoption, to ensure that 
> >> multi-scheme'ness (per se) is being built into implementations.
> > 
> > We can do FTP immediately. ftp and ftps. perhaps scp would also work? Would
> > that help?
> > 
> >> 
> >> If I had a magic wand, Id have people agree to one that requires use 
> >> of the "start SSL" technique, wherein such as an http tunnel is 
> >> upgraded once it exists to an https tunnel. This forces the us to have 
> >> considered the edge cases of SSL, material to this protocol.
> > 
> > Not so long ago a few people on the list asked us to get back to basics, as
> > we were getting lost in complex TLS magic. This is why I am trying to get us
> > to focus now on the simple implementation of the protocol we have now and
> > that we understand well.
> > 
> > I suggest that you write up a paper for the meeting in Berlin on one of your
> > favorite schemes. Try to make it short. Show the UML description, security
> > problems, and so on. An implementation that works would be even better. Then
> > we can review that, and see how to fit these ideas all together here.
> > 
> > But I would also suggest you try harder first to get WebID working as it is
> > now, with a test suite for an enpoint you can put up, and open source code
> > to go with it. Then we can better understand the issues you may have.
> > 
> > Henry
> > 
> > 
> >> 
> >> -----Original Message-----
> >> From: public-xg-webid-request@w3.org 
> >> [mailto:public-xg-webid-request@w3.org]
> >> On Behalf Of Mo McRoberts
> >> Sent: Tuesday, April 19, 2011 5:12 AM
> >> To: Kingsley Idehen
> >> Cc: public-xg-webid@w3.org
> >> Subject: Re: self-signed
> >> 
> >> 
> >> On 19 Apr 2011, at 13:05, Kingsley Idehen wrote:
> >> 
> >>> On 4/19/11 3:36 AM, Mo McRoberts wrote:
> >>>> On 19 Apr 2011, at 01:43, Kingsley Idehen wrote:
> >>>> 
> >>>>>> You're saying "WebID should support more than just http URIs"
> >>>>>> 
> >>>>> It shouldn't be scheme specific in any shape or form.
> >>>> Okay, I have a practical problem with this as written: how do I 
> >>>> implement
> >> a WebID relying party which doesn't restrict itself to certain schemes?
> >>> 
> >>> Relying party needs to treat WebID as a protocol comprised of:
> >>> 
> >>> 1. URIs for Agent Identity (Names)
> >>> 2. Protocol for validating Agent Identity.
> >>> 
> >>> A URI is scheme agnostic. The fact that HTTP can be used as 
> >>> Name/Access
> >> mechanism doesn't imply this capability is unique to HTTP. You can 
> >> make other URIs resolve.
> >> 
> >> Yes, but you still need to have that code which knows *how*.
> >> 
> >> There is no double-standard in saying "I wish to implement a WebID 
> >> server which won't confuse people by only supporting half of the 
> >> schemes they expect. What do I need to support?", nor in providing the 
> >> answers to that question.
> >> 
> >> 
> >> --
> >> Mo McRoberts - Data Analyst - Digital Public Space, Zone 1.08, BBC 
> >> Scotland,
> >> 40 Pacific Quay, Glasgow G51 1DA, Room 7066, BBC Television Centre, 
> >> London
> >> W12 7RJ,
> >> 0141 422 6036 (Internal: 01-26036) - PGP key 0x663E2B4A
> >> 
> >> 
> >> http://www.bbc.co.uk/
> >> This e-mail (and any attachments) is confidential and may contain 
> >> personal views which are not the views of the BBC unless specifically
> > stated.
> >> If you have received it in error, please delete it from your system.
> >> Do not use, copy or disclose the information in any way nor act in 
> >> reliance on it and notify the sender immediately.
> >> Please note that the BBC monitors e-mails sent or received.
> >> Further communication will signify your consent to this.
> >>      
> >> 
> >> 
> >> 
> > 
> > Social Web Architect
> > http://bblfish.net/
> > 
> > 
> > 
> 
> Social Web Architect
> http://bblfish.net/
> 
>

Received on Tuesday, 19 April 2011 16:14:35 UTC