Re: Fwd: [dns-rrtype-applications] New RR Application - DOA

--===============8321685968983256900==
Content-Type: multipart/alternative; boundary="94eb2c1914aef89937055552c216"

--94eb2c1914aef89937055552c216
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

HI Olafur,

I do not think think specification retains some ambiguities at the moment.
A couple of issues:

In section  3.1.2, the document says: 'For the value 2 ("URI") the DOA-DATA
contains a UTF-8 encoded string representing the URI from which the DOA
object can be obtained.'   This is appears to assume a limited set of URI
types related to client/server retrieval (what happens if this has "mailto:
[email protected]" as a value? or bitcoin:mumble?).  In general, actually
listing the acceptable URI schemes is more useful and can easily be made
part of an extensible registry.

In section 3.1.3, the document says "For the value 3 ("HDL") the DOA-DATA
contains a UTF-8 encoded string representing the handle from the Handle
System [RFC3650] from which the DOA object can be obtained."  RFC 3650
limited the set of characters appropriate for Handles to Version 3 of the
UCS (see section 3).  I don't follow the current work, but it seems that
this document either needs to preserve that restriction or to point to
later documents that removed it.  Note also that section 6.1 of RFC 3650
argued explicitly against using the DNS for the Handle system.  Since DOAs
are currently distributed with the Handle system, it would likely be useful
to indicate why an RR for this purpose works now when it did not on
publication of the core Handle documents.

This statement:

"DNS software implementing the DOA RR type MUST NOT drop or otherwise
refuse to handle the DOA RRs containing an unknown or unsupported
DOA-location and MUST treat the DOA-DATA portion of the RR as an abstract
opaque field."

seems to amount to "DNS software must not fail when serving syntactically
correct data in an RR." That's rather an odd thing to say, and I kind of
wonder why it belongs in a document registering this RR type.  Perhaps some
more data on this point is required or perhaps the statement can be removed=
.

In general, I think the authors would do well to look back at the history
of the URN-related DNS systems (possibly with a large adult beverage in
hand).  What they propose in this draft is somewhere between a generic URI
pointer to a handle, a re-implementation of the data URI scheme in the DNS,
the DDDS without all that pesky NAPTR business, and a way of storing opaque
strings of no known utility.  There are already ways to do most of this, in
other words, and its not clear what lumping them together here is really
that good at doing.

While engaged in that review, I really hope that  they go back through Chip
Sharp's description of the DOA system ( https://www.internetsociety.
org/doc/overview-digital-object-architecture-doa).  I think it does a good
job of reviewing why many of the most valued elements of the DOA (e.g.
persistenc) are properties created by assurances from the issuers and not
by the protocol itself.  Thinking on that more may inspire them to adjust
this proposal.

regards,

Ted

On Thu, Jul 27, 2017 at 7:41 AM, Olafur Gudmundsson <[email protected]> wrote:

> Dear Colleagues
> The RRType experts received the application below,
> I have been selected as the expert, after reviewing the application it
> meets all criteria for acceptance.
>
> This message is to solicit any reasons that the applications should not b=
e
> accepted.
> The last day for comment on the application is August 8=E2=80=99th.
>
> Any reports of implementations experience would be helpful.
>
> Olafur
>
>
> Begin forwarded message:
>
> *From: *Ray Bellis <[email protected]>
> *Subject: **[dns-rrtype-applications] New RR Application - DOA*
> *Date: *July 25, 2017 at 11:41:43 AM EDT
> *To: *[email protected]
>
> Please find attached an RR application template for the "DOA" RR type.
>
> The link to the I-D describing the RR is:
>
> <https://www.ietf.org/internet-drafts/draft-durand-doa-over-dns-02.txt>
>
> I am obviously recusing myself from evaluation of this application :)
>
> Please address any questions to both authors of the I-D.
>
> Ray
>
>
> _______________________________________________
>
>
>
> _______________________________________________
> dnsext mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dnsext
>
>

--94eb2c1914aef89937055552c216
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div><div><div><div>HI Olafur,<br><br>=
</div>I do not think think specification retains some ambiguities at the mo=
ment.=C2=A0 A couple of issues:<br><br></div>In section=C2=A0 3.1.2, the do=
cument says: &#39;For the value 2 (&quot;URI&quot;) the DOA-DATA contains a=
 UTF-8 encoded string representing the URI from which the DOA object can be=
 obtained.&#39;=C2=A0=C2=A0 This is appears to assume a limited set of URI =
types related to client/server retrieval (what happens if this has &quot;ma=
ilto:<a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>&q=
uot; as a value? or bitcoin:mumble?).=C2=A0 In general, actually listing th=
e acceptable URI schemes is more useful and can easily be made part of an e=
xtensible registry.<br><br></div>In section 3.1.3, the document says &quot;=
For the value 3 (&quot;HDL&quot;) the DOA-DATA contains a UTF-8 encoded str=
ing representing the handle from the Handle System [RFC3650]  from which th=
e DOA object can be obtained.&quot;=C2=A0 RFC 3650 limited the set of chara=
cters appropriate for Handles to Version 3 of the UCS (see section 3).=C2=
=A0 I don&#39;t follow the current work, but it seems that this document ei=
ther needs to preserve that restriction or to point to later documents that=
 removed it.=C2=A0 Note also that section 6.1 of RFC 3650 argued explicitly=
 against using the DNS for the Handle system.=C2=A0 Since DOAs are currentl=
y distributed with the Handle system, it would likely be useful to indicate=
 why an RR for this purpose works now when it did not on publication of the=
 core Handle documents.<br></div><br></div>This statement:<br><br>&quot;DNS=
 software implementing the DOA RR type MUST NOT drop or otherwise refuse to=
 handle the DOA RRs containing an unknown or unsupported DOA-location and M=
UST treat the DOA-DATA portion of the RR as an abstract opaque field.&quot;=
<br><br>seems to amount to &quot;DNS software must not fail when serving sy=
ntactically correct data in an RR.&quot; That&#39;s rather an odd thing to =
say, and I kind of wonder why it belongs in a document registering this RR =
type.=C2=A0 Perhaps some more data on this point is required or perhaps the=
 statement can be removed.<br><br></div>In general, I think the authors wou=
ld do well to look back at the history of the URN-related DNS systems (poss=
ibly with a large adult beverage in hand).=C2=A0 What they propose in this =
draft is somewhere between a generic URI=C2=A0 pointer to a handle, a re-im=
plementation of the data URI scheme in the DNS, the DDDS without all that p=
esky NAPTR business, and a way of storing opaque strings of no known utilit=
y.=C2=A0 There are already ways to do most of this, in other words, and its=
 not clear what lumping them together here is really that good at doing.<br=
><br>While engaged in that review, I really hope that=C2=A0 they go back th=
rough Chip Sharp&#39;s description of the DOA system ( <a href=3D"https://w=
ww.internetsociety.org/doc/overview-digital-object-architecture-doa" target=
=3D"_blank">https://www.internetsociety.<wbr>org/doc/overview-digital-<wbr>=
object-architecture-doa</a>).=C2=A0 I think it does a good job of reviewing=
 why many of the most valued elements of the DOA (e.g. persistenc) are prop=
erties created by assurances from the issuers and not by the protocol itsel=
f.=C2=A0 Thinking on that more may inspire them to adjust this proposal.<br=
><br></div>regards,<br><br></div>Ted<br></div><div class=3D"gmail_extra"><b=
r><div class=3D"gmail_quote">On Thu, Jul 27, 2017 at 7:41 AM, Olafur Gudmun=
dsson <span dir=3D"ltr">&lt;<a href=3D"mailto:[email protected]" target=3D"_bla=
nk">[email protected]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div style=3D"word-wrap:break-word">Dear Colleagues=C2=A0<div>The RRType exp=
erts received the application below,=C2=A0</div><div>I have been selected a=
s the expert, after reviewing the application it meets all criteria for acc=
eptance.=C2=A0</div><div><br></div><div>This message is to solicit any reas=
ons that the applications should not be accepted.=C2=A0</div><div>The last =
day for comment on the application is August 8=E2=80=99th.=C2=A0</div><div>=
<br></div><div>Any reports of implementations experience would be helpful.=
=C2=A0</div><div><br></div><div>Olafur</div><div><br></div><div><div><br><b=
lockquote type=3D"cite"><div>Begin forwarded message:</div><br class=3D"m_-=
8050334842743155839Apple-interchange-newline"><div style=3D"margin-top:0px;=
margin-right:0px;margin-bottom:0px;margin-left:0px"><span style=3D"font-fam=
ily:-webkit-system-font,Helvetica Neue,Helvetica,sans-serif;color:rgba(0,0,=
0,1.0)"><b>From: </b></span><span style=3D"font-family:-webkit-system-font,=
Helvetica Neue,Helvetica,sans-serif">Ray Bellis &lt;<a href=3D"mailto:ray@b=
ellis.me.uk" target=3D"_blank">[email protected]</a>&gt;<br></span></div><di=
v style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0p=
x"><span style=3D"font-family:-webkit-system-font,Helvetica Neue,Helvetica,=
sans-serif;color:rgba(0,0,0,1.0)"><b>Subject: </b></span><span style=3D"fon=
t-family:-webkit-system-font,Helvetica Neue,Helvetica,sans-serif"><b>[dns-r=
rtype-applications] New RR Application - DOA</b><br></span></div><div style=
=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px"><spa=
n style=3D"font-family:-webkit-system-font,Helvetica Neue,Helvetica,sans-se=
rif;color:rgba(0,0,0,1.0)"><b>Date: </b></span><span style=3D"font-family:-=
webkit-system-font,Helvetica Neue,Helvetica,sans-serif">July 25, 2017 at 11=
:41:43 AM EDT<br></span></div><div style=3D"margin-top:0px;margin-right:0px=
;margin-bottom:0px;margin-left:0px"><span style=3D"font-family:-webkit-syst=
em-font,Helvetica Neue,Helvetica,sans-serif;color:rgba(0,0,0,1.0)"><b>To: <=
/b></span><span style=3D"font-family:-webkit-system-font,Helvetica Neue,Hel=
vetica,sans-serif"><a href=3D"mailto:[email protected]" targ=
et=3D"_blank">dns-rrtype-applications@ietf.<wbr>org</a><br></span></div><br=
><div><div>Please find attached an RR application template for the &quot;DO=
A&quot; RR type.<br><br>The link to the I-D describing the RR is:<br><br>&l=
t;<a href=3D"https://www.ietf.org/internet-drafts/draft-durand-doa-over-dns=
-02.txt" target=3D"_blank">https://www.ietf.org/<wbr>internet-drafts/draft-=
durand-<wbr>doa-over-dns-02.txt</a>&gt;<br><br>I am obviously recusing myse=
lf from evaluation of this application :)<br><br>Please address any questio=
ns to both authors of the I-D.<br><br>Ray<br></div></div></blockquote></div=
></div></div><br><div style=3D"word-wrap:break-word"><div><div><blockquote =
type=3D"cite"><div><div>______________________________<wbr>________________=
_<br></div></div></blockquote></div><br></div></div><br>___________________=
___________<wbr>_________________<br>
dnsext mailing list<br>
<a href=3D"mailto:[email protected]">[email protected]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dnsext" rel=3D"noreferrer"=
 target=3D"_blank">https://www.ietf.org/mailman/<wbr>listinfo/dnsext</a><br=
>
<br></blockquote></div><br></div>

--94eb2c1914aef89937055552c216--


--===============8321685968983256900==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
dnsext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsext

--===============8321685968983256900==--