Bugs in the remote storage protocol

[Melvin Carvalho]

I was pointed today to:

https://silverbucket.net/.well-known/webfinger?resource=acct:ni...@silverbucket.net

[[

{
  "subject": "acct:ni...@silverbucket.net",
  "links": [
    {
      "href": "https://storage.5apps.com/silverbucket",
      "rel": "remotestorage",
      "type": "https://www.w3.org/community/rww/wiki/read-write-web-00#simple",
      "properties": {
        "auth-method": "http://tools.ietf.org/html/rfc6749#section-4.2",
        "auth-endpoint": "https://5apps.com/rs/oauth/silverbucket"
      }
    }
  ]
}

]]

I believe there are a number of bugs:

1. type should be a media type, not a URL.  Note: that this URL doesnt even exist anymore.

2. properties should an array, rather than, an object

3. my reading of the spec means that nested properties are forbidden in webfinger JRD serialization

[Michiel B. de Jong]

Hi Melvin,

On 2013-07-28 23:27, Melvin Carvalho wrote:
> I was pointed today to:
>
>
> https://silverbucket.net/.well-known/webfinger?resource=acct:ni...@silverbucket.net

> [1]
>
> [[
>
> {

> "subject": "acct:ni...@silverbucket.net",
> "links": [
> {
> "href": "https://storage.5apps.com/silverbucket",
> "rel": "remotestorage",
> "type":
> "https://www.w3.org/community/rww/wiki/read-write-web-00#simple",
> "properties": {
> "auth-method": "http://tools.ietf.org/html/rfc6749#section-4.2",
> "auth-endpoint": "https://5apps.com/rs/oauth/silverbucket"
> }
> }
> ]
> }
>
> ]]
>
> I believe there are a number of bugs:
>
> 1. type should be a media type, not a URL. Note: that this URL doesnt
> even exist anymore.
>
> 2. properties should an array, rather than, an object
>
> 3. my reading of the spec means that nested properties are forbidden
> in webfinger JRD serialization

The format you quote is not the current one, since this change:


that's an old format, that was changed several times since then,
notably here:

https://github.com/steventebrinke/remotestorage-spec/commit/1977e8b0e7151bee46d38b6bbea0ba8d14fd984a

The current format is here:

https://github.com/remotestorage/spec/blob/master/draft-dejong-remotestorage-01.txt#L345

I think the current format is good enough and we're not winning
anything functionally by changing it around all the time.

But thanks for the heads-up!

BTW I'm at the IETF meeting now, we're having a Bar BoF in two hours:

https://www.ietf.org/mail-archive/web/apps-discuss/current/msg10098.html

I'll let you know what people bring up.


Cheers,
Michiel

[Nick Jennings]

On Mon, Jul 29, 2013 at 5:22 PM, Michiel B. de Jong <anyt...@michielbdejong.com> wrote:

Hi Melvin,

On 2013-07-28 23:27, Melvin Carvalho wrote:

I was pointed today to:


https://silverbucket.net/.well-known/webfinger?resource=acct:ni...@silverbucket.net

[1]

[[

{
 "subject": "acct:ni...@silverbucket.net",
 "links": [
 {
 "href": "https://storage.5apps.com/silverbucket",
 "rel": "remotestorage",
 "type":
"https://www.w3.org/community/rww/wiki/read-write-web-00#simple",
 "properties": {
 "auth-method": "http://tools.ietf.org/html/rfc6749#section-4.2",
 "auth-endpoint": "https://5apps.com/rs/oauth/silverbucket"
 }
 }
 ]
}

]]

I believe there are a number of bugs:

1. type should be a media type, not a URL. Note: that this URL doesnt
even exist anymore.

2. properties should an array, rather than, an object

3. my reading of the spec means that nested properties are forbidden
in webfinger JRD serialization

The format you quote is not the current one, since this change:


that's an old format, that was changed several times since then, notably here:

https://github.com/steventebrinke/remotestorage-spec/commit/1977e8b0e7151bee46d38b6bbea0ba8d14fd984a

Good to know. I copied the format from heahdk.net about 6months ago I think, so I was just using whatever it showed me when I looked up my account
.
When / how do those hosting their own WebFinger records know when something changes in the remoteStorage WebFinger JSON section?

 

The current format is here:

https://github.com/remotestorage/spec/blob/master/draft-dejong-remotestorage-01.txt#L345

I think the current format is good enough and we're not winning anything functionally by changing it around all the time.

I updated the auth-endpoint bit, but that portion was actually not even one of the 3 points Melvin listed. Though, I agree it doesn't make sense to pro-actively go about changing things until we know for certain that it will at least not need changing again anytime soon.

[Nick Jennings]

Oh also, forgot to ask:

The spec says 'type' is <storage_api> and directs to "Session description" which defines storage_api just as: 'draft-dejong-remotestorage-01'  .. is that correct or should it be a URI?

[Michiel B. de Jong]

On 2013-07-29 21:18, Nick Jennings wrote:
> Good to know. I copied the format from heahdk.net [10] about 6months

> ago I think, so I was just using whatever it showed me when I looked
> up my account
> .
> When / how do those hosting their own WebFinger records know when
> something changes in the remoteStorage WebFinger JSON section?

it's still the "correct" format for announcing a 2012.04-compatible
storage. that didn't change. what changes is that since then, two new
formats (remotestorage-00 and remotestorage-01) came out and the first
one changed the identifier, but the second one also changed the
properties syntax, so that it lines up with what at the time was the
latest webfinger spec.

you will never have to change your webfinger record, unless that
remoteStorage endpoint you're announcing stops being valid.

btw, we just had the Bar BoF here at the IETF meeting, and the
conclusions were:

- we talked about what
http://www.ietf.org/id/draft-dejong-remotestorage-01.txt proposes, and
how it compares to rsync.
- Mark Nottingham will send us some comments about how to make the text
of http://www.ietf.org/id/draft-dejong-remotestorage-01.txt better
- we'll probably need to temporarily give in to extensibility if we
want to drive adoption. a certain set of extensions can then thereafter
become the (de facto or hard-coded) standard
- we need more implementers. i'll contact some medium-size players,
like for instance maybe not Dropbox, but maybe mobile operators for
instance.
- we talked about whether this should become an rfc, and though that
would be good for marketing, it's probably better to get more
parties/implementers involved in it first.

at least that's my personal summary of what was said. :)


cheers!
Michiel

[Sebastian Kippe]

On Jul 29, 2013, at 9:41 PM, Michiel B. de Jong <anyt...@michielbdejong.com> wrote:

> btw, we just had the Bar BoF here at the IETF meeting, and the conclusions were:
>
> - we talked about what http://www.ietf.org/id/draft-dejong-remotestorage-01.txt proposes, and how it compares to rsync.
> - Mark Nottingham will send us some comments about how to make the text of http://www.ietf.org/id/draft-dejong-remotestorage-01.txt better
> - we'll probably need to temporarily give in to extensibility if we want to drive adoption. a certain set of extensions can then thereafter become the (de facto or hard-coded) standard
> - we need more implementers. i'll contact some medium-size players, like for instance maybe not Dropbox, but maybe mobile operators for instance.
> - we talked about whether this should become an rfc, and though that would be good for marketing, it's probably better to get more parties/implementers involved in it first.
>
> at least that's my personal summary of what was said. :)

Thanks, Michiel! Sounds all reasonable to me.

It would be good to publish that summary on the forums as well, instead of only having it as a response to a bug report email on this list. ;)

Cheers
Basti