Subject: [Uri-review] http://www.ietf.org/internet-drafts/draft-josefsson-dns-url-06.txt

From: Ted Hardie <[email-masked]>
Date: Tue, 8 Apr 2003 15:36:24 -0700

Howdy folks,
	If you can, please review the draft listed above.  It is another that 
has been stuck
in limbo for some time, and I'd like to get review comments on how it 
fits into the
current scheme of things.
					thanks,
							Ted Hardie

_______________________________________________
Uri-review mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/uri-review

---

From: "Larry Masinter" <[email-masked]>
Date: Wed, 9 Apr 2003 11:08:43 -0700

I'm having trouble imagining the applicability of
this scheme, even in "DNS related software".

Perhaps some examples of where/when you'd use a
"dns" URL among many other kinds of URLs?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ted Hardie
Sent: Tuesday, April 08, 2003 3:36 PM
To: [email-masked]
Subject: [Uri-review]
http://www.ietf.org/internet-drafts/draft-josefsson-dns-url-06.txt

Howdy folks,
	If you can, please review the draft listed above.  It is another
that 
has been stuck
in limbo for some time, and I'd like to get review comments on how it 
fits into the
current scheme of things.
					thanks,
							Ted Hardie

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 21 Apr 2003 20:24:30 +0200

Thanks for looking at the document.

> "dns" URL among many other kinds of URLs?

The document contains an example

,----
|    The following illustrate a DNS query for "simon.example.org" for the
|    CERT type in the Internet (IN) class:
|
|    dns:simon.example.org?type=CERT
`----

which in combination with, e.g., draft-ietf-tls-extensions-06.txt
illustrate how TLS servers may retrieve certificates for clients via
DNS.  The TLS extension solve how this is made secure even when the
protocol (like DNS) that retrieves the certificate is not secure.

Isn't the example sufficient?  I'm somewhat reluctant to add too much
detail on how the URI scheme is used by other protocols, because
people may then start to debate whether the example is secure or not.
I'd like to push that discussion to the security specifications that
uses the URI instead, where it belongs, is appropriate and productive.
In this regard, DNS URIs aren't different from any other URI scheme
that refer to data retrieved via insecure protocols.

Of course, if you like to contribute a specific thorough discussion
that you feel is appropriate, it could be incorporated.

---

From: "Larry Masinter" <[email-masked]>
Date: Mon, 21 Apr 2003 12:12:46 -0700

I'm trying to imagine a context for use, not
an example. Would anyone write:

<html>
 <body>
   <a href="dns:simon.example.org?type=CERT">a link</a>
 </body>
</html>

If not, when is the use of this syntax actually
interoperable with any other kind of URI scheme?

If there are other documents that talk about how
this thing is used, then you could point to them;
a reference is fine, you don't have to include
a discussion. But right now there are no references
either.

> From: Simon Josefsson [mailto:[email-masked]] 
> Sent: Monday, April 21, 2003 11:25 AM
> To: Larry Masinter
> Cc: 'Ted Hardie'; [email-masked]
> Subject: Re: [Uri-review]

---

From: "Daniel R. Tobias" <[email-masked]>
Date: Mon, 21 Apr 2003 20:56:47 -0400

>    <a href="dns:simon.example.org?type=CERT">a link</a>

I guess I can imagine a future browser adding support for this 
protocol... the logical thing for it to do would be to make the 
appropriate DNS query and display the results.

-- 
== Dan ==
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 22 Apr 2003 12:28:26 +0200

>    <a href="dns:simon.example.org?type=CERT">a link</a>

Yes.  It could be used instead of, e.g., a FTP URI to link to a
certificate, something people often do from their homepage.

Comparing FTP and DNS can be illustrative: neither provides security
features nor are the protocols MIME aware.

A browser could implement DNS URIs by forming DNS queries and
rendering the DNS response nicely in HTML, just like they do for ftp:,
file:, etc.

> a discussion. But right now there are no references

The TLS draft talk about how it will be used, but it is not a RFC.  I
will try to come up with another reference, and if I can't I'll
include the TLS draft as a informative reference

Thanks.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 22 Apr 2003 13:10:26 +0200

> certificate, something people often do from their homepage.

Just to clarify: I'm not saying the above HTML is a good idea in
general.  In fact, I think it is a bad idea, just like I think using a
FTP URI in the same situation would be a bad idea.  Using HTTP to
transfer certificates is better in the majority of cases.

But it would be _possible_ to write the above.

And it might be useful in _some_ cases.  Just like a FTP URI could be
useful in some cases.  Which these cases are is impossible to say; the
point is to enable the functionality to allow them to be used by other
protocols when believed to be appropriate.

Thanks again.

---

From: "Larry Masinter" <[email-masked]>
Date: Fri, 25 Apr 2003 13:36:16 -0700

Well, I think the general principle is that
"not every Resource Identifier needs to be a URI".
I.e., it should be clear why the proposed URI scheme
needs to be a URI, rather than just some syntax to
talk about something that's useful to talk about.

And the application should be in the draft or
referenced by the draft.

    Intended usage: Broad usage.

From the discussion so far, I question this designation.
It sounds like the usage is narrow and obscure.

   Applications and/or protocols which use this scheme: DNS related
   software.

From the discussion so far, this doesn't seem right. Most
"DNS related software" wouldn't use this scheme.

   Author/Change Controller: IESG

I don't think the IESG would have a good idea of how
to 'change control' this URI scheme.

I think once you remove section 1.2, that having a
separate section 1.1 isn't necessary.

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Simon Josefsson
> Subject: [Uri-review] Re: [Uri-review]

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 26 Apr 2003 01:57:38 +0200

> And the application should be in the draft or

The second paragraph of the introduction tried to argue for this,
although it didn't give explicit examples.  Since it obviously didn't
work, I have rewritten it and added explicit examples (RFCs).  The TLS
draft is still one of the best use cases, but as published RFCs could
be found, perhaps it is more stable to reference them?

   The primary motivation behind defining a Uniform Resource Identifier
   (URI) for DNS resources, instead of using another non-URI syntax that
   embed the domain, type value and class value, is that applications
   that stores or retrieve certificates today uses URIs for this
   purpose.  Thus, defining a URI scheme for DNS resources allows these
   existing protocols to be used with certificates in DNS without having
   to add DNS specific modifications to said protocols.  In order to not
   introduce interoperability or security considerations, protocols that
   uses these URIs naturally must have been written to allow for future,
   as of writing yet undefined, URIs to be used.

   A few examples of protocols that may utilize DNS URIs:

   o  The OpenPGP Message Format [6], where an end-user may indicate the
      location of a copy of any updates to her key, using the "preferred
      key server" field.

   o  The X.509 Certificate Request Message Format [7], where the
      subscriber can indicate using URLs where she want the certificate
      to be published.

   o  The X.509 Online Certificate Status Protocol [10], where the OCSP
      responder can indicate where a CRL can be found.

   The DNS URI scheme defined here can, of course, be used to reference
   any DNS data, and is not limited to only certificates.  The purpose
   of this specification is to define a generic DNS URI, not a specific
   DNS solution for certificates stored in DNS.  Browsers may implement
   support for DNS URIs by forming DNS queries and render DNS responses
   using HTML, similar to what is done for FTP.

> It sounds like the usage is narrow and obscure.

I agree, the text was stolen from another URI template, and I kept it
because I didn't know what to write.  It now says:

   Intended usage: Whenever DNS resources are useful to reference by
   protocol independent identifiers, often when the data is more
   important than the access method.  Since software in general has
   coped without this so far, it is not anticipated to be implemented
   widely, nor migrated to by existing systems, but specific solutions
   (especially security related) may find this appropriate.

> "DNS related software" wouldn't use this scheme.

I agree here too.  It now says:

   Applications and/or protocols which use this scheme: Security related
   software.  It may be of interest to auxilliary DNS related software
   too.

> to 'change control' this URI scheme.

It now refers to me, although I note that most URI templates published
as RFCs says IESG.

> separate section 1.1 isn't necessary.

I collapsed it into the introduction.

The entire new version can be found at
http://josefsson.org/draft-josefsson-dns-uri.txt.  I'll wait for
comments on the above before sending it to the I-D editor.

Thanks again.

---

From: "Larry Masinter" <[email-masked]>
Date: Fri, 25 Apr 2003 18:03:13 -0700

I like this better. You might want to just move the
"changes to this version" stuff into an appendix,
so that it's easier to lop off.

I just thought of another issue, RFC 3490 (IDNA).

I realized that now that IDN is making progress you
might need to address the internationalization issues.

http://www.w3.org/International/iri-edit/

and, in particular,
  http://lists.w3.org/Archives/Public/public-iri/2003Apr/0028.html.

Your proposed URI scheme uses which encoding for the
DNS server name, and which encoding for the actual
DNS name?

Larry

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 26 Apr 2003 13:42:26 +0200

> so that it's easier to lop off.

Done.

>   http://lists.w3.org/Archives/Public/public-iri/2003Apr/0028.html.

Updated text:

   Character encoding considerations: The characters are encoded as per
   the "URI Generic Syntax" RFC [4].  The DNS protocol do not consider
   character sets, it simply transports opaque data.  In particular, the
   DNS URI is considered a internationalized domain name (IDN) unaware
   domain name slot, in the terminology of [13].  The reason for this is
   that making the URI contain an IDN aware domain name slot would make
   it impossible to express certain valid DNS domain names, as the DNS
   allows all octet sequences to be used as domain labels.  Applications
   with internationalization needs should support the ASCII encoding
   described in [13].

> DNS server name, and which encoding for the actual

The URI encoding.  DNS is not aware of charsets, domain labels are
considered opaque octet sequences.  Applications that need support for
internationalized domain names should use the ASCII compatible
encoding defined in IDNA.  As the text above says, the other option,
to make this URI scheme use a specific charset (e.g., UTF-8) and make
it IDN-aware, would make it impossible to express all valid domain
names in the URI, because not all possible octet sequences are valid
UTF-8.

Updated version at <http://josefsson.org/draft-josefsson-dns-url.txt>.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 28 Apr 2003 23:02:07 +0200

I tried to clarify the character encoding section further.  I left the
rationale in parenthesis, but perhaps it should simply be removed.

Updated document at URL in Subject.  Unless there are more comments I
will send the new version to the I-D editor Thursday.

   Character encoding considerations: The characters are encoded as per
   the "URI Generic Syntax" RFC [4].  The DNS protocol do not consider
   character sets, it simply transports opaque data.  In particular, the
   "dnsname" field of the DNS URI are to be considered an
   internationalized domain name (IDN) unaware domain name slot, in the
   terminology of [13].  (The reason for this is that making these
   fields be IDN aware by, e.g., specifying that they are UTF-8 [6]
   strings, would require further encoding mechanisms to be able to
   express all valid DNS domain names.  This is because the DNS allows
   all octet sequences to be used as domain labels, so UTF-8 strings do
   not cover all possibilities.  Instead of defining further encoding
   mechanisms, we point applications with internationalization needs at
   the ASCII encoding described in [13] which should be satisfactory.)
   The considerations for "hostport" are discussed in [4]