Eliot Lear wrote:
> we will find another list for this purpose.
Please consider to pick an existing list like pesci or newtrk
or similar, creating new lists for everything is just bad.
> 2026 must be revised and not merely updated
Your points (4) to (7) sound good, but not (1) to (3). I've
n
I support the textual descriptions of the changes Eliot made. However
I'm concerned that as with any effort to revise RFC 2026, there will
llikely be changes in wording that have unintended consequences. I am
not personally convinced that the value of revising RFC 2026 justifies
the risk of probl
On Thursday, September 28, 2006 07:32:17 AM +1000 Mark Andrews
<[EMAIL PROTECTED]> wrote:
Except it doesn't say "label"; that's your interpretation. I grant it
is an entirely reasonable interpretation, and in fact the alternate
interpretation that was suggested is not one that would have o
>
>
> On Wednesday, September 27, 2006 08:49:19 AM -0400 John C Klensin
> <[EMAIL PROTECTED]> wrote:
>
> > Sure. But that isn't what the term means in common (non-IETF)
> > practice and the document is quite specific that the return
> > value contain exactly one label (er, "item") with no prov
On Wednesday, September 27, 2006 08:49:19 AM -0400 John C Klensin
<[EMAIL PROTECTED]> wrote:
Sure. But that isn't what the term means in common (non-IETF)
practice and the document is quite specific that the return
value contain exactly one label (er, "item") with no provision
at all for two
--On Wednesday, 27 September, 2006 08:09 -0700 Dave Crocker
<[EMAIL PROTECTED]> wrote:
>
>
> John C Klensin wrote:
>> Dave, unfortunately, if "suffix" is formally defined, I
>> haven't been able to find it.
>
> Right.
>
> I was not intending to suggest that the specification was
> acceptab
some of this I've said elsewhere, but not here. sorry if you've already
seen it.
IMHO this is fundamentally a very dubious option because DNS is the
authoritative source of name-to-address mappings, and the way to find
out what DNS name is assigned to a particular network address is to
query
--On Wednesday, 27 September, 2006 09:52 -0700 "David W.
Hankins" <[EMAIL PROTECTED]> wrote:
> I'm not sure why this discussion has broken out on
> [EMAIL PROTECTED]
> Is it not better for iesg@ and [EMAIL PROTECTED]
Because Last Call announcements invite such discussion. Some
people tend to
Harald,
On Wed, 27 Sep 2006, Harald Alvestrand wrote:
> FWIW, "domain suffix" is used in RFC 3263, 3588, 4183 and 4620. In none
> of these documents does it seem that the author has seen a requirement
> for a definition; "a domain name that is intended to be used as a suffix
> of a complete dom
On Mon, Sep 25, 2006 at 11:07:32AM -0700, Lisa Dusseault wrote:
>
> On Sep 23, 2006, at 2:20 AM, Julian Reschke wrote:
>
> >
> >But as a matter of fact, draft-newman-i18n-comparator-14 doesn't
> >define any collations that would actually solve the Unicode NF
> >issue, so it's not really clear
FWIW, "domain suffix" is used in RFC 3263, 3588, 4183 and 4620. In none
of these documents does it seem that the author has seen a requirement
for a definition; "a domain name that is intended to be used as a suffix
of a complete domain name" seems to be the implied definition.
A pity that Ver
David W. Hankins wrote:
I am, however, a little skeptical at how useful it is going to be
to define the term 'domain name suffix'. I suspect the author of
this draft started by calling them 'zone suffixes' and was asked by
DNS zones are an administrative construct, not a user-visible naming
On Tue, 26 Sep 2006, Fred Baker wrote:
> On Sep 26, 2006, at 1:15 PM, Frank Ellermann wrote:
>
> >Sorry, probably that's all obvious, but where is ["domain suffix"]
> >defined ?
>
> At the Verisign site. It is the new-speak for use when all us ancient
> geeky types would prefer "TLD".
I fail
I'm not sure why this discussion has broken out on [EMAIL PROTECTED]
Is it not better for iesg@ and [EMAIL PROTECTED]
On Wed, Sep 27, 2006 at 08:41:27AM -0700, Dave Crocker wrote:
> as John noted, the term "item" is not defined, so we don't know how many
> labels (dns fields) are permitted. Thi
Bill Fenner wrote:
While I was confused too as to what this option is intended to be used
for, I think that
The domain suffix in the 'domain suffix' field ...
MUST be encoded as specified in the section of RFC3315
titled "Representation and use of domain names".
sufficiently specifies
On 9/27/06, Dave Crocker <[EMAIL PROTECTED]> wrote:
2. It does not specify any syntactic detail for the
field of the DHCP option. Is it a dotted ascii string? Some other
encoding?
While I was confused too as to what this option is intended to be used
for, I think that
The domain suffix in
John C Klensin wrote:
Dave, unfortunately, if "suffix" is formally defined, I haven't
been able to find it.
Right.
I was not intending to suggest that the specification was acceptable,
and apologize for not making that clear.
I was merely noting that the construct only made sense in ter
--On Wednesday, 27 September, 2006 06:49 -0700 Dave Crocker
<[EMAIL PROTECTED]> wrote:
> Fred Baker wrote:
>>> Sorry, probably that's all obvious, but where is ["domain
>>> suffix"] defined ?
>>
>> At the Verisign site. It is the new-speak for use when all us
>> ancient geeky types would pre
Fred Baker wrote:
Sorry, probably that's all obvious, but where is ["domain suffix"]
defined ?
At the Verisign site. It is the new-speak for use when all us ancient
geeky types would prefer "TLD".
Not quite. A TLD is the right most (visible) field, like com, net, my
or us, whereas a "s
Stig,
in the MDRS project my group works on to support multilingual
distributed referential systems we use the concept of Usage Level
Domain which may have a problem with your usage of "suffix". "suffix"
the usual/legal term used for the TLD in many non technical/general
languages. I tend to
--On Wednesday, 27 September, 2006 11:33 +0200 Frank Ellermann
<[EMAIL PROTECTED]> wrote:
> Stig Venaas wrote:
>
>> In the context of this draft, the term domain suffix is not
>> meant to be just the TLD. If "domain suffix" generally means,
>> or is thought of as, just the TLD, then the draft s
Please find in draft-lear-ietf-rfc2026bis-00.txt a preliminary revision
of, well, RFC 2026. It contains the following changes:
1. A new two step process for standardization where the second step
is optional. In other words, you get an STD # at the first step.
This is a bit of com
Stig Venaas wrote:
> In the context of this draft, the term domain suffix is not
> meant to be just the TLD. If "domain suffix" generally means,
> or is thought of as, just the TLD, then the draft should use
> some other term instead.
The term is okay if you mention that it's supposed to be one
o
John C Klensin wrote:
--On Wednesday, 27 September, 2006 09:19 +0200 Stig Venaas
<[EMAIL PROTECTED]> wrote:
Frank Ellermann wrote:
Fred Baker wrote:
["domain suffix"]
It is the new-speak for use when all us ancient geeky types
would prefer "TLD".
It's what a client might add to it's h
--On Wednesday, 27 September, 2006 09:19 +0200 Stig Venaas
<[EMAIL PROTECTED]> wrote:
> Frank Ellermann wrote:
>> Fred Baker wrote:
>>
>> ["domain suffix"]
>>
>>> It is the new-speak for use when all us ancient geeky types
>>> would prefer "TLD".
>
> It's what a client might add to it's host
Frank Ellermann wrote:
Fred Baker wrote:
["domain suffix"]
It is the new-speak for use when all us ancient geeky types
would prefer "TLD".
It's what a client might add to it's hostname to form an FQDN. Typically
also used as domain search path by many systems if no explicit search
path is
26 matches
Mail list logo