Re: [idn] Document Status?

[John C Klensin <klensin@jck.com>]

--On Thursday, 12 September, 2002 00:47 +0000 "Adam M. Costello"
<idn.amc+0@nicemice.net.RemoveThisWord> wrote:

> John C Klensin <klensin@jck.com> wrote:
> 
>>       Just as has been the case with LDH names, some zone
>>       administrators may impose restrictions, beyond those
>>       imposed by the protocol, on the characters or strings
>>       that may be registered as labels in their zones.  Such
>>       restrictions do not impact the protocols themselves; a
>>       query for a name that does not exist will yield the
>>       same response regardless of the reason why it is not in
>>       the relevant zone.  Restrictions imposed on a per-zone
>>       basis MUST NOT have any impact on the behavior of the
>>       on-the-wire protocol, and MUST NOT assume that clients
>>       issuing queries or interpreting responses will have any
>>       knowledge of zone-specific restrictions or conventions.
> 
> Thanks John, that looks helpful.  I just have a few nitpicky
> comments and questions about the precise wording.
> 
>     Just as has been the case with LDH names,
> 
> The phrase "LDH name" or "LDH label" appears nowhere in the
> document, so let's not introduce it now.  Let's say "ASCII
> names".

I was trying to convey the gist of an approach.   As far as I'm
concerned, one of the problems with the document is that it
suffers from too many writing styles already; you don't need
mine too.  But "ASCII names" doesn't quite do it either: if you
want to be precise, probably the right thing is to refer to the
definition.  E.g., "Just as has been the case with the
'preferred syntax' of the DNS specification [RFC1035, Section
2.3.1]",...   Those who know what this points to will know;
those who don't may benefit from looking it up.
 
>     some zone administrators
> 
> Let's say "DNS zone administrators".  This text would be going
> into section 2, which currently does not talk about DNS at
> all, so we need to establish that context for this paragraph.

ok
 
>     may impose restrictions, beyond those imposed by the
> protocol,
> 
> Which protocol?  Maybe you mean "imposed by DNS or IDNA".

that would be ok

>     on the characters or strings that may be registered as
> labels     in their zones.  Such restrictions do not impact
> the protocols     themselves;
> 
> Which protocols are not impacted?  Recently you were saying how
> important it is for DNS update protocols to have distinct
> return codes for "invalid name" versus "inadmissible name", so
> this part of the DNS protocol *would* be impacted by per-zone
> name restrictions.

If the IDNA spec has any impact on any [other] DNS-related
protocol, it falls outside the WG's scope.  So, either the
sentence as I wrote it is correct, or you have just supplied the
petard on which you would presumably like to be hoisted.

>     a query for a name that does not exist will yield the same
> response     regardless of the reason why it is not in the
> relevant zone.
> 
> Okay.
> 
>     Restrictions imposed on a per-zone basis MUST NOT have any
> impact on     the behavior of the on-the-wire protocol,
> 
> Again, which protocol?

See above, but I would welcome better text for this.
 
>     and MUST NOT assume that clients issuing queries or
> interpreting     responses will have any knowledge of
> zone-specific restrictions or     conventions.
> 
> I'd rather not insert requirements into the terminology
> section. Couldn't we say "have no impact" and "cannot assume
> that clients"?

See comment above about writing styles.

> Here's a stab at addressing these concerns, although you might
> be able to come up with something better:
> 
>     Just as has been the case with ASCII names, some DNS zone
>     administrators may impose restrictions, beyond those
> imposed by     DNS or IDNA, on the characters or strings that
> may be registered     as labels in their zones.  Such
> restrictions have no impact on the     syntax or semantics of
> DNS protocol messages; a query for a name     that does not
> exist will yield the same response regardless of     the
> reason why it is not in the zone.  Clients issuing queries or
>     interpreting responses cannot be assumed to have any
> knowledge of     zone-specific restrictions or conventions.

Modulo comments above, probably close enough.

     john