>> In a well designed system, names are only used to name things.
>
>I disagree, I think.
>
>In a "well designed" system, a name is meaningful to different parties
>differently. We can use it as a person's easy to remember name, or we
>can use it to express a relationship, or we can use it to ensur
>IMHO, I believe that there can be a way to attach resolution semantics to
>top-level names and implement this in the API level. IOW, for DNS "above
>the DNS" in the software stack. This is just a belief, not a certainty.
Well, sure, that's how .onion and .local work now. But there's no
general
I'm glad to see this thread on the list.
First, a plug for this draft which is an attempt to lay a foundation for
the discussion. There's at least one outstanding edit for it, it's not
complete and is intended to be changed via discussions like this. The
document hasn't been considered for WG ad
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Jacob Appelbaum wrote:
> Hi,
>
> On 11/29/15, Philip Homburg wrote:
>>
>> It is only later, at the application layer that the name is used
>> again.
>>
>> It is here that .onion goes one step further. Onion 'names' are
>> derived from public ke
Mark,
> What is the actual harm, discounting aesthetics?
For one thing, names not supported by the underlying infrastructure will
_always_ leak.
In the bad old days, when an application got a string ending in .UUCP, .BITNET,
.CSNET, etc., it had to know that those strings had to be treated dif
Hi,
On 11/29/15, Philip Homburg wrote:
>>> The purpose of the domain name system is to name things. We have IP
>>> addresses and we want to refer to them using names. We do the same thing
>>> with mail domains, etc.
>>
>>That is not the sole purpose - we use DNS for keys, for time stamps,
>>for d
>> The purpose of the domain name system is to name things. We have IP
>> addresses and we want to refer to them using names. We do the same thing
>> with mail domains, etc.
>
>That is not the sole purpose - we use DNS for keys, for time stamps,
>for data of all kinds.
In a well designed system, n
On 11/29/15, Philip Homburg wrote:
>>.onion was the chosen approach precisely because nothing else but lookup
>> and s
>>ubsequent routing has to change; there are no other application-level
>> decision
>>s about .onion, and that's a feature. HTTP still works, TLS still works
>> (once
>>you can ge
>.onion was the chosen approach precisely because nothing else but lookup and s
>ubsequent routing has to change; there are no other application-level decision
>s about .onion, and that's a feature. HTTP still works, TLS still works (once
>you can get a cert), links still work, HTML still works. S
Hi George,
> I have a different perspective on this question Mark.
>
> Firstly, I find use of .magic as the extreme RHS of a name, to force
> special behaviour architecturally disqueting.
>
> I really do worry about what we think we're building when we encode this
> behaviour into name strings.
I'm not the WG Chair who is handling the day-to-day responsibilities (I
just do all the other boring DNS stuff), but I do know this:
- design team is being put together but was not complete
- Ralph Droms (AD for 6761) is the head of the design team
- they are still looking for 1-2 people with
I have a different perspective on this question Mark.
Firstly, I find use of .magic as the extreme RHS of a name, to force
special behaviour architecturally disqueting.
I really do worry about what we think we're building when we encode this
behaviour into name strings. It leads to all kinds of b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 11/26/2015 06:38 AM, Mark Nottingham wrote:
>
> Given this context, I was disturbed to hear the design team presentati
on
> in Yokohama
>
So you mean there's an already working team on the revision of RFC6761,
and that team had the time to prepa
RFC7230 Section 2.7.1 says this about hostnames in HTTP URLs:
"""
If host is a registered name, the registered name is an indirect identifier for
use with a name resolution service, such as DNS, to find an address for that
origin server.
"""
... which builds on how RFC3986 Section 3.2.2 talks
14 matches
Mail list logo
