Re: [tor-dev] Comments on proposal 279 (Name API)

meejah wrote: > > It was suggested I post this to tor-dev; I prototyped a small thing > that allows the prop-279 APIs to be tested against actual-Tor without > changing Tor. That is, it does the "abuse the control-protocol" thing > but speaks to prop-279 style subprocesses. >

Re: [tor-dev] Comments on proposal 279 (Name API)

It was suggested I post this to tor-dev; I prototyped a small thing that allows the prop-279 APIs to be tested against actual-Tor without changing Tor. That is, it does the "abuse the control-protocol" thing but speaks to prop-279 style subprocesses. This is just proof-of-concept and would need

Re: [tor-dev] Comments on proposal 279 (Name API)

On Sat, 8 Apr 2017 08:47:51 +0100 Alec Muffett wrote: > However: on this conference call it was made abundantly clear to all > present - one could almost hear fingers being wagged - that it would > be a bad thing for Onion addresses to (1) contain anything other than >

Re: [tor-dev] Comments on proposal 279 (Name API)

On 8 April 2017 at 03:23, Yawning Angel wrote: > On Fri, 7 Apr 2017 11:44:03 +0100 > Alec Muffett wrote: > > If I was in charge, I would say that we risk overthinking this, and it > > would be better to: > > > >- mandate use of fully

Re: [tor-dev] Comments on proposal 279 (Name API)

On Fri, 7 Apr 2017 11:44:03 +0100 Alec Muffett wrote: > If I was in charge, I would say that we risk overthinking this, and it > would be better to: > >- mandate use of fully DNS-compliant syntax, including but not > limited to: acceptable max length, max label

Re: [tor-dev] Comments on proposal 279 (Name API)

> > > I suggest that we require all address suffixes to end with .onion; > > other TLDs are not reserved like .onion is, and maybe we shouldn't > > squat any we haven't squatted already. > > FWIW it's not at all clear to me that this is a concern that IETF or > ICANN will care about. Hi. My

Re: [tor-dev] Comments on proposal 279 (Name API)

On 04/06/2017 09:13 AM, Jeremy Rand wrote: > Hi Nick! > > Nick Mathewson: >> Section 2.1 and elsewhere: > >> I suggest that we require all address suffixes to end with .onion; >> other TLDs are not reserved like .onion is, and maybe we shouldn't >> squat any we haven't squatted already. > >

Re: [tor-dev] Comments on proposal 279 (Name API)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Nick! Nick Mathewson: > Section 2.1 and elsewhere: > > I suggest that we require all address suffixes to end with .onion; > other TLDs are not reserved like .onion is, and maybe we shouldn't > squat any we haven't squatted already. FWIW it's

Re: [tor-dev] Comments on proposal 279 (Name API)

On 04/04/2017 12:50 AM, Nick Mathewson wrote: > On Mon, Apr 3, 2017 at 8:20 AM, George Kadianakis > wrote: >> Nick Mathewson writes: >>> Section 2.1 and elsewhere: >>> >>> I suggest that we require all address suffixes to end with .onion; >>> other

Re: [tor-dev] Comments on proposal 279 (Name API)

On Mon, Apr 3, 2017 at 8:20 AM, George Kadianakis wrote: > Nick Mathewson writes: >> Section 2.1 and elsewhere: >> >> I suggest that we require all address suffixes to end with .onion; >> other TLDs are not reserved like .onion is, and maybe we

Re: [tor-dev] Comments on proposal 279 (Name API)

Nick Mathewson writes: > Hi ! I'll make some comments here on the draft onion naming API at > > https://gitweb.torproject.org/torspec.git/tree/proposals/279-naming-layer-api.txt > > (Some of these are probably things you already meant, or already said > elsewhere.) >

Re: [tor-dev] Comments on proposal 279 (Name API)

Hi, I would like to do some addition as well. Section 2.3. System configuration [TORRC] - Do we really need a priority list? - Should we just make a priority based on the ordering? Section 2.3.1. Tor name resolution logic - Should tor check the based on regex? - How should it reponds when is