dchub URI scheme

Post Reply
Pretorian
Site Admin
Posts: 213
Joined: 21 Jul 2009, 10:21

dchub URI scheme

Post by Pretorian » 31 Jan 2013, 21:06

The following is a URI scheme that I intend to submit to IETF for the inclusion as a standardized URI.
(last updated 2013-01-31)

Resource Identifier (RI) Scheme name: dchub
Status: REQUEST

Scheme syntax:

dchub://<host>[:<port>]/[<user>/<path>]

A client should connect to a server (hub) "host" with an optional port, which defaults to 411.

A client should queue a directory or file (according to the path) and attempt to download the directory or file from the specified user.

A user should always be followed by a path to a directory or file.

Examples:
dchub://example.com
dchub://example.com:666
dchub://example.com/John/uploads/applications/linux.iso
dchub://example.com:411/John/uploads/applications/linux.iso

Scheme semantics:
Connect to a server and optionally download a file from a user.

Encoding considerations:
The executing system's encoding is used.

Applications/protocols that use this scheme name:
Used by various Direct Connect clients.

Interoperability considerations:
The path is a path in the user's shared files. The path does not reflect a system's underlying file system.

Security considerations:
The user that is in the hub may not be the same user as when the URI was constructed. Likewise with the path.
Contact:
Registering party: Fredrik Ullner <[email protected]>
Scheme creator: Jonathan Hess
Author/Change controller:
The registering party or a member of the NMDC project
References:
http://nmdc.sourceforge.net/, http://en.wikipedia.org/wiki/Direct_Con ... e_sharing)

(file created 2013-01-31)

poy
Member
Posts: 78
Joined: 26 Nov 2008, 17:04

Re: dchub URI scheme

Post by poy » 02 Feb 2013, 16:56

this is great; i have minor comments...
Pretorian wrote:
dchub://<host>[:<port>]/[<user>/<path>]
shouldn't the slash between port & user be optional (ie inside the following brackets)?
Pretorian wrote:
A user should always be followed by a path to a directory or file.
the path being optional, "should" is too strong here. how about "may only be followed by"?
Pretorian wrote:
Encoding considerations:
The executing system's encoding is used.
i know that NMDC uses system-dependant encodings; but this is somewhat separate. couldn't we specify UTF-8 here, and let the client convert to the encoding it prefers (which the user may have configured to be different than the system encoding)?
Pretorian wrote:
Applications/protocols that use this scheme name:
Used by various Direct Connect clients.
might want to clarify that while clients do understand the address and (for some) a user param, there isn't any that we know of that fully parses the path param.
Pretorian wrote:
Interoperability considerations:
The path is a path in the user's shared files. The path does not reflect a system's underlying file system.
the path format has to be detailed:
- what is the separator? -> /
- how does one refer to a directory? -> by ending the path with a separator.
- what happens when a directory is passed as the path param, does the client download it, show it to the user, or leave it to the client's discretion)?

Pretorian
Site Admin
Posts: 213
Joined: 21 Jul 2009, 10:21

Re: dchub URI scheme

Post by Pretorian » 03 Feb 2013, 13:14

poy wrote:
dchub://<host>[:<port>]/[<user>/<path>]
shouldn't the slash between port & user be optional (ie inside the following brackets)?
Yes, it's wrong. It should be;
dchub://<host>[:<port>][/[<user>/<path>]]
poy wrote:
A user should always be followed by a path to a directory or file.
the path being optional, "should" is too strong here. how about "may only be followed by"?
I don't think the implementations did anything with just a user, you had to have a path afterwards. I am not entirely sure what should happen otherwise, download the file list only?
poy wrote:
Encoding considerations: The executing system's encoding is used.
i know that NMDC uses system-dependant encodings; but this is somewhat separate. couldn't we specify UTF-8 here, and let the client convert to the encoding it prefers (which the user may have configured to be different than the system encoding)?
Sounds fine, should one just write "UTF-8" or should one be eloborate?
poy wrote:
Applications/protocols that use this scheme name:
Used by various Direct Connect clients.
might want to clarify that while clients do understand the address and (for some) a user param, there isn't any that we know of that fully parses the path param.
The old NMDC client did in fact support the user and path. Potentially writing something like;
Used by various Direct Connect clients. Not all implementations support the user and path syntax.
poy wrote:
Interoperability considerations:
The path is a path in the user's shared files. The path does not reflect a system's underlying file system.
the path format has to be detailed:
- what is the separator? -> /
- how does one refer to a directory? -> by ending the path with a separator.
- what happens when a directory is passed as the path param, does the client download it, show it to the user, or leave it to the client's discretion)?
Good comments. I generally want to say "download it" to your third item...

Following is an updated version with changes in bold.
(last updated 2013-01-31)

Resource Identifier (RI) Scheme name: dchub
Status: REQUEST

Scheme syntax:

dchub://<host>[:<port>][/[<user>/<path>]]

A client should connect to a server (hub) "host" with an optional port, which defaults to 411.

A client should queue a directory or file (according to the path) and attempt to download the directory or file from the specified user.

A user should always be followed by a path to a directory or file.

Path separator is a slash ('/'). Directories are referenced by ending the path with a separator. Clients should download the entire directory with its content.

Examples:
dchub://example.com
dchub://example.com:666
dchub://example.com/John/uploads/applications/linux.iso
dchub://example.com:411/John/uploads/applications/linux.iso

Scheme semantics:
Connect to a server and optionally download a file from a user.

Encoding considerations:
UTF-8, see RFC 3986.

Applications/protocols that use this scheme name:
Used by various Direct Connect clients. Not all implementations support the user and path syntax.

Interoperability considerations:
The path is a path in the user's shared files. The path does not reflect a system's underlying file system.

Security considerations:
The user that is in the hub may not be the same user as when the URI was constructed. Likewise with the path.

Contact:
Registering party: Fredrik Ullner <[email protected]>
Scheme creator: Jonathan Hess

Author/Change controller:
The registering party or a member of the NMDC project

References:
http://nmdc.sourceforge.net/, http://en.wikipedia.org/wiki/Direct_Con ... e_sharing)

(file created 2013-01-31)

poy
Member
Posts: 78
Joined: 26 Nov 2008, 17:04

Re: dchub URI scheme

Post by poy » 03 Feb 2013, 17:07

Pretorian wrote:I don't think the implementations did anything with just a user, you had to have a path afterwards. I am not entirely sure what should happen otherwise, download the file list only?
this is what DC++ currently does; it understands a "user" param (downloads the file list) but doesn't parse the "path" param. would be good to allow the path to be optional.
Pretorian wrote:Sounds fine, should one just write "UTF-8" or should one be eloborate?
are you referring to variants like UTF-16 being BE or LE? i don't think UTF-8 has any such branching.

Pretorian
Site Admin
Posts: 213
Joined: 21 Jul 2009, 10:21

Re: dchub URI scheme

Post by Pretorian » 08 Feb 2013, 16:13

New syntax to accomodate for lack of path support;
dchub://<host>[:<port>][/[<user>[/<path>]]]
poy, I think you said that DC++ does not handle a slash after a user, so above require the slash to be present IFF path is present.

To accomodate for it in the text;
A user should may be followed by a path to a directory or file. The client should download the user's file list if path is omitted.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest