Subject: [apps-discuss] proposing draft-farrell-ni as an appsarea wg item

From: Stephen Farrell <[email-masked]>
Date: Wed, 27 Jul 2011 16:49:26 +0100

Hi,

Yesterday, I presented a draft [1] on a URI scheme for naming
stuff to the decade WG. There's interest in that there but
the idea behind this is really broader than just decade so
if there's interest here, doing this work in the appsarea WG
would I think be much better.

The scheme is basically like HTTP URIs with one additional
thing, which is that it specifies a way to include a hash
function output in the name (and the related input, in case
you want to verify something later) which seems to me to be
a generally useful thing that various protocols could use
in various ways. Hence the idea of bringing it here.

So, comments appreciated,

Thanks,
Stephen.

[1] http://tools.ietf.org/html/draft-farrell-ni

---

From: Linyi Tian 01 <[email-masked]>
Date: Wed, 27 Jul 2011 21:25:30 -0400

>in various ways. Hence the idea of bringing it here.

I am wondering how this would be used. Will it be used together with HTTP
URIs? Is there any real life use case how I can use this URI.

>_______________________________________________
>apps-discuss mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 28 Jul 2011 08:14:16 +0300

> URIs? Is there any real life use case how I can use this URI.
+1. I think APPSAWG shouldn't accept this as WG item; I wouldn't also
recommend it for publication of it as AD-sponsored Individual submission
or in any other way as RFC.

There is no clear explanation of operations for new URI scheme. What
should the application do when resolving the 'ni' URI? What protocol
should be used? Also, <authority> includes <userinfo> and <port>, which
I don't how to be applied to 'ni' URI operations. I think that 'tag'
URIs, which only identify the resource (RFC 4151), are suitable for the
purposes of proposed 'ni' URI scheme.

Mykyta Yevstifeyev

---

From: Larry Masinter <[email-masked]>
Date: Thu, 28 Jul 2011 05:55:57 -0700

perhaps IETF should consider adopting (or adapting) as IETF BCP some or all of

http://www.w3.org/TR/webarch/ "Architecture of the World Wide Web" (W3C recommendation)

http://www.w3.org/2001/tag/doc/SchemeProtocols.html URI Schemes and Web Protocols  (editor draft W3C TAG finding)

http://www.w3.org/2001/tag/doc/whenToUseGet.html URIs, Addressability, and the use of HTTP GET and POST  (approved W3C TAG finding)

as they read on the advisability of inventing new URI schemes.  

While 4395bis is a work item of the IRI working group, the issues seem out of scope for the current working group, which IMHO should focus on the internationalization issues of 3987bis.

Larry
--
http://larry.masinter.net

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Mykyta Yevstifeyev [[email-masked]]
Sent: Wednesday, July 27, 2011 10:14 PM
To: [email-masked]
Subject: Re: [apps-discuss] proposing draft-farrell-ni as an appsarea wg item

Mykyta Yevstifeyev

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 28 Jul 2011 14:41:06 +0100

> URIs? Is there any real life use case how I can use this URI.

There are two ways in which this could be used I think, one is
where a protocol carries a URI and then the new scheme could be
used. For HTTP URLs one could use the hash-string construct
within the pathname I guess and that might be useful to document
as an option.

As I said the decade wg are thinking about this for their protocol
work. There are also many HTTP URLs that contain hashes, the extent
to which it'd be useful for someone to be able to know what was input
to the hash is hard to tell. I suspect it'd be useful sometimes
though.

S.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 28 Jul 2011 16:51:31 -0400

> to the hash is hard to tell. I suspect it'd be useful sometimes

I've heard about other folks who are interested in a very simple method
for either a URN or a URI for identifying the output of a hash function.

Possible examples of URNs and URIs:

urn:hash:sha256:NDc0NzgyMGVmOGQ3OGU0...

sha256:NDc0NzgyMGVmOGQ3OGU0...

I don't think this should be a URN, because a URN namespace is managed.
(In this sense RFC 4122 is misguided and deserves to be deprecated.)

I don't see the need for an authority component, but maybe I'm missing
something in the use cases.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 29 Jul 2011 00:05:53 +0100

> (In this sense RFC 4122 is misguided and deserves to be deprecated.)

I think that's useful input - thanks.

> something in the use cases.

Within the information centric kind of stuff we do (as research, not
ready for IETF prime time by any means) we have a need for a DNS or
DNS-like authority. We also have use-cases for no authority part at
all in that same space.

I basically just allowed the hash-string for authority since it seemed
like fun:-) That is, I have no concrete use case for that now.

S.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 28 Jul 2011 20:34:08 -0400

> like fun:-) That is, I have no concrete use case for that now.

It would be good to get an idea of the use cases people have. I've heard
about various folks who might want a hash URI scheme, but I haven't
heard about specific use cases they've got.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 29 Jul 2011 12:45:12 +0100

> heard about specific use cases they've got.

Good plan. It'd be great to hear what similar requirements/use-cases
exist,

S.

---

From: Linyi Tian 01 <[email-masked]>
Date: Fri, 29 Jul 2011 18:48:46 +0200

>Good plan. It'd be great to hear what similar requirements/use-cases

Use cases are really important in this case. It is simply because we need
to understand in which environment it will be used in the correct way. If
no use cases why bother to do the technical work?

So I am looking forward to seeing use case and requirements too.

For urn based design, the URN may be too long since SHA256 will have 256
bytes hash value. Right?
urn:hash:sha256:NDc0NzgyMGVmOGQ3OGU0...

---

From: Barry Leiba <[email-masked]>
Date: Fri, 29 Jul 2011 12:54:10 -0400

> urn:hash:sha256:NDc0NzgyMGVmOGQ3OGU0...

256 *bits*, so only 32 bytes.  Slightly longer when you base64-encode
it, but it's not too bad.

Barry

---

From: Linyi Tian 01 <[email-masked]>
Date: Fri, 29 Jul 2011 19:10:02 +0200

>it, but it's not too bad.

Yes, I meant for 256 bits:) Thanks for the correction.