(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)
dchub URI scheme
-
- Site Admin
- Posts: 214
- Joined: 21 Jul 2009, 10:21
dchub URI scheme
The following is a URI scheme that I intend to submit to IETF for the inclusion as a standardized URI.
-
- Member
- Posts: 78
- Joined: 26 Nov 2008, 17:04
Re: dchub URI scheme
this is great; i have minor comments...
- 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)?
shouldn't the slash between port & user be optional (ie inside the following brackets)?Pretorian wrote:dchub://<host>[:<port>]/[<user>/<path>]
the path being optional, "should" is too strong here. how about "may only be followed by"?Pretorian wrote:A user should always be followed by a path to a directory or file.
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:Encoding considerations:
The executing system's encoding is used.
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:Applications/protocols that use this scheme name:
Used by various Direct Connect clients.
the path format has to be detailed: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.
- 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)?
-
- Site Admin
- Posts: 214
- Joined: 21 Jul 2009, 10:21
Re: dchub URI scheme
Yes, it's wrong. It should be;poy wrote:shouldn't the slash between port & user be optional (ie inside the following brackets)?dchub://<host>[:<port>]/[<user>/<path>]
dchub://<host>[:<port>][/[<user>/<path>]]
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:the path being optional, "should" is too strong here. how about "may only be followed by"?A user should always be followed by a path to a directory or file.
Sounds fine, should one just write "UTF-8" or should one be eloborate?poy wrote: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)?Encoding considerations: The executing system's encoding is used.
The old NMDC client did in fact support the user and path. Potentially writing something like;poy wrote: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.Applications/protocols that use this scheme name:
Used by various Direct Connect clients.
Used by various Direct Connect clients. Not all implementations support the user and path syntax.
Good comments. I generally want to say "download it" to your third item...poy wrote:the path format has to be detailed:Interoperability considerations:
The path is a path in the user's shared files. The path does not reflect a system's underlying file system.
- 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)?
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)
-
- Member
- Posts: 78
- Joined: 26 Nov 2008, 17:04
Re: dchub URI scheme
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: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?
are you referring to variants like UTF-16 being BE or LE? i don't think UTF-8 has any such branching.Pretorian wrote:Sounds fine, should one just write "UTF-8" or should one be eloborate?
-
- Site Admin
- Posts: 214
- Joined: 21 Jul 2009, 10:21
Re: dchub URI scheme
New syntax to accomodate for lack of path support;
To accomodate for it in the text;
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.dchub://<host>[:<port>][/[<user>[/<path>]]]
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.