Andrew Sullivan wrote:
>
> In the other case, it's an indication that the _namespace_ is
> different: that if you resolve that name on the Internet without
> special enabled software, you aren't getting the service you desired,
> regardless of the protocol you happen to be using. In theory, these
Hi,
I have been reading this draft with a view to designing an implementation.
In an attempt to understand section 6 I tried to pull it apart in to
more sections. I have attempted to describe the behaviour of each possible
type of name server (e.g., auth, recursive, caching, forwarding, stub, et
On Wed, Jan 07, 2015 at 01:59:42PM +, Tony Finch wrote:
> hostnames do not have a way to specify a name's class. But it is perfectly
> feasible to install a new system resolver module which changes the way
> part of the namespace works without requiring changes to any of the apps.
For these pu
On Jan 7, 2015, at 10:19 AM, Andrew Sullivan wrote:
> For these purposes, a separate resolver is needed anyway. So a
> different class is just as feasible.
You seem to be missing Tony's point.
The point is that there is already a UI for typing, for example, "foo.onion".
There is no UI for ty
just for the record, the prior art was not referenced in this draft, even though
Warren was notified when he was working on its predecessor. it would be nice
to actually acknowledge prior art.
http://archive.icann.org/en/meetings/saopaulo/presentation-cadr-07dec06.pdf
/bill
PO Box 12317
Marina
the cadr software triggered updates on either a change in value of a referenced
retype, OR, when sent a
signal in an oob fashion (e.g. look for an update now)
in either case, the child was triggering synchronization - which is also what
your draft does.
/bill
PO Box 12317
Marina del Rey, CA
On Wed, Jan 07, 2015 at 11:05:35AM -0500, Ted Lemon wrote:
> You seem to be missing Tony's point.
>
> The point is that there is already a UI for typing, for example, "foo.onion".
>
No, I get that, and I understand why we're using the name _instead_ as
an indicator. This is really the same r
On Jan 7, 2015, at 11:12 AM, Andrew Sullivan wrote:
> No, I get that, and I understand why we're using the name _instead_ as
> an indicator. This is really the same reason people used underscores
> with TXT RRs as a selector instead of a different RRTYPE in lots of
> cases: you use the interface
Andrew Sullivan wrote:
>
> My only real point is that the Tor case and, say, the GNS case are
> really basically different, because one of them would actually be
> susceptible to a different URI scheme whereas others don't work that
> way.
I don't think that is true. You can use ssh or http or sm
On Wed, Jan 07, 2015 at 04:45:46PM +, Tony Finch wrote:
> I don't think that is true. You can use ssh or http or smtp or imap or any
> TCP application over Tor, and you can use the GNS to resolve A and
> records to use for any purpose too.
Christian Grothoff was arguing up-thread that tha
On 01/07/2015 08:20 PM, Andrew Sullivan wrote:
> On Wed, Jan 07, 2015 at 04:45:46PM +, Tony Finch wrote:
>> I don't think that is true. You can use ssh or http or smtp or imap or any
>> TCP application over Tor, and you can use the GNS to resolve A and
>> records to use for any purpose too
> On Jan 7, 2015, at 8:59 AM, Tony Finch wrote:
>
> Andrew Sullivan wrote:
>>
>> In the other case, it's an indication that the _namespace_ is
>> different: that if you resolve that name on the Internet without
>> special enabled software, you aren't getting the service you desired,
>> regardl
Every morning I wake up, racked with guilt for not having actually
reviewed this document. I open my mailbox, and one of Paul Hoffman's
"Bi-weekly reminder of the documents for the WG" emails pops up,
making me cringe... well, no more...
Below are some comment, in OPR/C format.
Almost entirely nit
13 matches
Mail list logo
