gmane.ietf.uri-review

Re: Initial inquiry into URI proposal (nym)

DataPacRat — 2013-06-13T23:16:35

I was hoping to shuffle as much of such extraneous data as possible
into the optional comments fields.


May I ask what you would feel would be safe to remove, and whether
that removal would affect the core goal of stating "Authority X,
confirming with AuthenticationHash ABCD, asserts that Y and Z refer to
the same entity"?



Thank you for your time,
--
DataPacRat
"Then again, I could be wrong."

Re: Initial inquiry into URI proposal (nym)

Larry Masinter — 2013-06-13T23:11:50

" clear utility to the broad Internet community..."

If there is utility, it isn't clear.

You're packing lots of metadata irrelevant for locating into the locator.

Initial inquiry into URI proposal (nym)

DataPacRat — 2013-06-13T18:42:01

For my own purposes, I’ve started roughly defining a pseudo-URI,
loosely based on ‘tag:’. I initially put it together to use as a
framework for authenticating a peer-to-peer reputation system, but it
seems as if it could be general enough for many other uses, as well.

Going through the process of writing up a full Internet Draft proposal
is a bit of an effort for a personal toy URI, but I don't mind doing
so - if it actually is something worth doing. As far as I can tell,
this mailing list seems to be the most appropriate place to ask the
question: Does nym: meet the very basic requirement for a URI, of
providing "clear utility to the broad Internet community, beyond that
available with already registered URI schemes"? If there's a consensus
here that it does, then I'll try to fill out a scheme registration
template, and proceed as RFC 4395 suggests from there. If not, then I
apologize for taking up your time.

I've posted some of my initial notes at
http://blog.datapacrat.com/2013/06/08/early-draft-f

Re: Review Request of new URI Scheme

Eric Johnson — 2013-06-06T17:19:42

Hmmm - as I see it, the primary problem with this request is that it 
seems to confuse a string with the format "xxx:" with something that 
might be called  URI.

The usage given:

Windows.System.Launcher.LaunchUriAsync("ms-settings-power:");

suggests from the name that the author(s) of the method intended to 
launch URIs. However, the *only* place that this alleged URI scheme 
might be useful is apparently in conjunction with this particular API. 
So this method is launching strings, some of which have a special 
format. That doesn't make it a URI.

Picking this apart in the literal sense:

  - Uniform - not really - at least not in the sense that it can be used 
in other places where URIs can be found. I couldn't use this in Java, I 
can't use it from my Mac, and and I cannot even use it from a Windows 
desktop.
  - Resource - the abstract resource indicated here seems to be a 
specific application. But it isn't a resource from most places where you 
might find a URI (a web page, an Android phone, an inst

Re: Review Request of new URI Scheme

Kang Su Gatlin — 2013-06-06T17:00:13

Hi Bjoern, answers inline.

-----Original Message-----
From: Bjoern Hoehrmann [mailto:derhoermi< at >gmx.net] 
Sent: Thursday, June 6, 2013 12:12 AM
To: Kang Su Gatlin
Cc: uri-review< at >ietf.org
Subject: Re: [Uri-review] Review Request of new URI Scheme

* Kang Su Gatlin wrote:

It is not really possible to craft a `ms-settings-power` URI based on this information, not other than `ms-settings-power:` at least.

[KSG] There is no additional syntax (consider the trailing colon added).  This will launch the battery saver setting application on Windows Phone via:

Windows.System.Launcher.LaunchUriAsync("ms-settings-power:");

"None" does not make clear whether there genuinely are no issues to consider or if simply no thought has been spent on the matter.

[KSG] In this case none means that we believe there are no issues to consider.

A requirement for provisional registration is "If no permanent, citable specification for the URI scheme definition is included, credible reasons for not providing it should be given." Th

Re: Review Request of new URI Scheme

Daniel R. Tobias — 2013-06-06T13:37:13


Is this something for which there really, truly, is a need for a 
separate URI scheme to accomplish, rather than a more general 
"launch-system-settings" scheme which could have parameters for 
starting up various setup functions for a system?

Re: Review Request of new URI Scheme

Bjoern Hoehrmann — 2013-06-06T07:11:38

It is not really possible to craft a `ms-settings-power` URI based on
this information, not other than `ms-settings-power:` at least.


"None" does not make clear whether there genuinely are no issues to
consider or if simply no thought has been spent on the matter.


A requirement for provisional registration is "If no permanent, citable
specification for the URI scheme definition is included, credible
reasons for not providing it should be given." The document above does
not seem to even mention the scheme.

Review Request of new URI Scheme

Kang Su Gatlin — 2013-06-05T23:10:08

Hello, I am requesting review for the following URI scheme:



   Resource Identifier (RI) Scheme name:
      ms-settings-power
   Status:
      provisional
   Scheme syntax:
      ms-settings-power

   Scheme semantics:
      Launches the battery saver settings application.
   Encoding considerations:
      None

   Applications/protocols that use this scheme name:
      Battery Saver settings application in Windows Phone.

   Interoperability considerations:
      None
   Security considerations:
      None
   Contact:
     urischemeowners< at >microsoft.com
   Author/Change controller:
      urischemeowners< at >microsoft.com

   References:
      http://www.windowsphone.com/en-us/how-to/wp8/basics/battery-making-it-last

_______________________________________________
Uri-review mailing list
Uri-review< at >ietf.org
https://www.ietf.org/mailman/listinfo/uri-review

Re: URI scheme registration request - dchub

Fredrik Ullner — 2013-06-03T19:23:09

Hi,

There is now a new version of the dchub URI scheme proposal at <
http://nmdc.sourceforge.net/Versions/nmdc-uri-scheme-0.3.txt>. There are a
couple of changes:

* It was decided to drop the secure dchub URI (nmdcs) inclusion. While this
is an URI that is used, it was felt that it is better to have that as a
separate URI scheme proposal. (The reason for the naming was simply that
the person who wrote it in the first place, wrote it as such.)
* Scheme syntax is very slightly changed to allow a forward slash after
user (as it is allowed elsewhere, too).
* Semantics is heavily revised, taking into account suggested changes from
you as well as from multiple developers of the Direct Connect network (i.e.
implementators).
* Encoding slightly revised, primarily for normalization. A question came
up: should the 'normalization' be changed to 'canonicalization'?
* Applications/protocol slightly revised, specifying more implementations.
Perhaps it is otherwise better to create a reference on a NMDC project page
and

Biggest Fake Conference in Computer Science

2013-04-27T17:53:33

We are researchers from different parts of the world and conducted a study on  
the world’s biggest bogus computer science conference WORLDCOMP 
( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia 
from University of Georgia, USA.


We submitted a fake paper to WORLDCOMP 2011 and again (the same paper 
with a modified title) to WORLDCOMP 2012. This paper had numerous 
fundamental mistakes. Sample statements from that paper include: 

(1). Binary logic is fuzzy logic and vice versa
(2). Pascal developed fuzzy logic
(3). Object oriented languages do not exhibit any polymorphism or inheritance
(4). TCP and IP are synonyms and are part of OSI model 
(5). Distributed systems deal with only one computer
(6). Laptop is an example for a super computer
(7). Operating system is an example for computer hardware


Also, our paper did not express any conceptual meaning.  However, it 
was accepted both the times without any modifications (and without 
any reviews) and we were invited to submit t

Re: PKCS#11 URI registration request review

Jan Pechanec — 2013-03-21T16:17:46


hi, I filed the draft that was attached in my previous email:

http://www.ietf.org/id/draft-pechanec-pkcs11uri-09.txt

unless there are more comments I think I can move on with the 
registration request. I will wait for another two weeks before doing so.

regards, Jan.

Re: URI scheme registration request - dchub

Eric Johnson — 2013-03-11T18:48:21

On 3/10/13 8:57 AM, Graham Klyne wrote:
Realizing that a number of these items you probably added to respond to 
my comment, I think Graham makes a critical point.

My question was about defining how one maps the URI to the protocol, not 
about repeating the definition of the protocol.

For example, this line:

" The client SHOULD request a TCP connection to the specified user via 
the commands $CTM (ConnectToMe) or $RCM (ReverseConnectToMe) (or an 
equivalent command)."

... I would write differently. The normative statements in this document 
ought to be about the URI and its use, rather than being normative 
statements about the protocol. There are lots of ways to use URIs that 
have nothing to do with the actual protocol (path computations, display 
on web pages, entries in a caching table). So the above statement, if it 
appears anywhere, should be in the protocol document. For the URI 
document, you could write something like this instead:

"With this form of URI, the client wishing to retrieve a file

Re: URI scheme registration request - dchub

Graham Klyne — 2013-03-10T15:57:54

I took a quick scan through the URI registration, and two points occurred to me.


On 09/03/2013 18:20, Fredrik Ullner wrote:

1. (nit):  nmdcs is not immediately recognizable as something like "secure 
dchub".  Is there any reason to use this name rather than, say, 'dchubs'. 
(Deployed systems would be a good reason.)

2. "Userinfo, queries, fragments (and more), as specified by RFC 3986, is 
discouraged and SHOULD NOT be used."

With regard to fragment identifiers, I think it's not for the URI spec to 
require non-use.  When a URI used by a client (e.g. dereferenced), the fragment 
is stripped off and not sent to the server.  The client may then interpret the 
fragment in light of what media type is returned from the server.  SO, if the 
dchub protocol is used to retrieve an HTML document, the fragment identifier may 
be used to control the disposition opf thgat document in the same way that it 
would be used for a HTML document retrieved using HTTP.

Here, I think non-use of userinfo and queries is covere

Re: URI scheme registration request - dchub

Fredrik Ullner — 2013-03-09T18:20:19

Hi,

A new version of the NMDC document is now available at <
http://nmdc.sourceforge.net/Versions/NMDC-1.3.html>. Note that the
versioning is the document's version, not the protocol, of which hasn't
changed in quite some time. There is also a new version of the URI scheme
available at <http://nmdc.sourceforge.net/nmdc-uri-scheme.txt>.

The new URI scheme document;
* All sections are updated to be more explicit and each section should be
more focused compared to before.
* The security concerns are addressed. Note that the NMDC document
addresses some security items that are general for the protocol, hence the
reference.
* The document should use more references to other RFCs (notably 3986) and
use phrasing such as "SHOULD" and "MUST" to follow the 'RFC text standard'.
* The document should address many items that have been noted (see e.g.
Eric's mail).
* References to what some implementations support.
* Added a 'nmdcs' part to the document; I don't know if this is appropriate
for the document, though. (nmd

Re: PKCS#11 URI registration request review

Jan Pechanec — 2013-03-05T06:16:01


thank you, I replied to my original mail with a new draft 
attached. Regards, Jan.

Re: PKCS#11 URI registration request review

Jan Pechanec — 2013-03-05T06:14:39

hi, I've updated the draft based on feedback provided by the 
list and I've attached a new draft version 
draft-pechanec-pkcs11uri-09.txt. I cannot file it now due to the cut-off 
time. There are several minor changes and one major which is a new 
section on the PKCS#11 URI comparison.

there were minor updates to the separate registration template. 
It is attached, too.

best regards, Jan.

Re: PKCS#11 URI registration request review

Larry Masinter — 2013-03-04T10:37:04

I think you've given ample material; if you update the draft and
get re-review that would be great, I think.

Re: URI scheme registration request - dchub

Graham Klyne — 2013-02-22T14:57:39

It's a hard question to answer definitively.

Mainly, I'd be looking for indications that this has been reviewed by some 
people who are aware of the problems that public protocols can run into.

The fact that there are multiple independent implementations is a *big* plus - 
possibly enough to go straight for permanent registration.  Is there any kind of 
interoperability discussion or similar conducted by the dchub developer 
community?  This is not something that should require additional work at this 
stage.  (I agree that it's not the protocol document's place to describe 
interoperable implementations.)

My questions came about because I hadn't heard of dchub protocol before, so I 
was casting about for some indication of how mature and widely used the 
protocol, is in practice.  In part, I was hoping my questions might prompt 
responses from other IETFers who might have greater knowledge of dchub.

In any case, I think there's plenty of material to support a provisional 
registration straight away.  T

Re: URI scheme registration request - dchub

Graham Klyne — 2013-02-22T15:13:20


"Ought to be" maybe too strong, but if dchub is widely used and supported that's 
an option to consider.  But if you go down that route, be aware that in can be a 
lot of work preparing and herding a spec through full IETF review.  As Eric 
says, that would almost certainly justify making the URI scheme registration 
permanent.


I took a quick look.  It appears to be a vibrant developer community there, but 
I got a bit lost looking, e.g., for possible clues about interoperability of 
different implementations.

The adcs: reference wasn't useful to me, as my browser doesn't know what to do 
with it - this is a perennial problem with new URI schemes, and is one reason 
why there is some reluctance to allow new permanent schemes - it's extremely 
difficult and expensive to get new schemes widely deployed.

#g
--

Re: URI scheme registration request - dchub

Fredrik Ullner — 2013-02-21T21:07:55

I have uploaded the document to the SVN, so people can track changes that
are made to the document. See it here; <
http://nmdc.svn.sourceforge.net/viewvc/nmdc/trunk/nmdc-uri-scheme.txt?view=log

The index page of nmdc.sf.net was incorrect, it did not have a news item
for 1.2, which contain more content. Note that the document is descriptive
of the protocol and its implementations and not prescriptive. The protocol
was built in 1999 (i.e., shortly after Napster and before BitTorrent) but
it has been expanded upon many times, but the original version was never
made public, hence reverse engineering efforts.

The protocol is very much still used today as it has been used in the past.
There are still many users using the protocol daily.

Note that the URI was constructed by Jonathan Hess for the original NMDC
client and this is an attempt at a formalization of that scheme. The
phrasing of the scheme is such that some current implementations only
support a partial of the syntax listed. There haven't been any inno

Re: URI scheme registration request - dchub

Eric Johnson — 2013-02-21T18:13:06

Am I missing something here? I'm not one to typically comment on these, 
but I was unaware of the NMDC protocol. So I'm glad to see this attempt 
to register, which will raise awareness of the protocol. However, the 
proposed URI scheme registration document utterly confuses me.

The syntax section:

  * discusses semantics. For example: "The client should download the
    user's file list if path is omitted".
  * doesn't actually reference the syntax components of RFC 3986. It
    doesn't explicitly exclude possible portions of the syntax, such as
    fragment identifiers and queries. Am I to assume that those are
    allowed, but not specified in their use, or disallowed?
  * seems to allow "dchub://" as a valid URI, however, if I follow RFC
    3986 properly, that is not a valid URI, and at least a "host" is
    required.
  * Is RFC 3986 "userinfo" allowed in the URI? If so, how does that
    interact with the protocol?


The semantics section:

  * should steal the portions from the syntax section that a