Review of draft-ietf-idnabis-defs-10

[John C Klensin]

Paul,

I need to get some rest but, quickly:  I agree that, if there
were no other reasons for those terms, they would be best left
out.  But there are, so the main question becomes whether we are
better or worse off having the terms in a picture (which all of
the other terms are) or not.  I've obviously been inclined
toward inclusion.  I'll fix the definition pointers and try to
rationalize capitalization and figure layout.

    john


--On Sunday, August 23, 2009 11:47 -0700 Paul Hoffman
<phoffman at imc.org> wrote:

> At 2:28 PM -0400 8/23/09, John C Klensin wrote:
>> I favor leaving the "bitstring" and "binary" categories in,
>> not because I like the pictures but because the distinction is
>> already made in the text of Defs (see the last paragraph of
>> Section 2.2), with references and for two other reasons:
>> 
>>	* This distinction has caused confusion in the past,
>>	even among the DNS-expert community.
> 
> Oh, yes. That's why I was asking.
> 
>>	
>>	* Discussions have [re-]started about the direct use of
>>	UTF-8 in the DNS (i.e., without ACE encoding), partially
>>	because it has been done for some time outside the
>>	public DNS, partially because the ACE form (and special
>>	IDNA mappings) interfere with common APIs, and for other
>>	reasons.  See draft-iab-idn-encoding for one perspective
>>	one this. (Because that is an IAB draft, you can assume
>>	that I'm involved with it. You should not assume that I
>>	agree with it.)  If that discussion goes anywhere, the
>>	distinction becomes important because a binary label is
>>	one that contains octets with the high bit set and a
>>	bitstring one is another matter entirely.
> 
> That makes good sense. It's hard to predict the future, but if
> this future comes to be, we probably will not be making
> anything more confusing with our terminology. I am concerned
> about the WG bringing up the issue on our own because of the
> first bullet, but you make a good point that it is being
> brought up whether or not we want it to be.
> 
>> I do think it would be worthwhile to get a reference attached
>> to the figure that points to Section 2.2 and will figure out
>> a way to do that.
> 
> That would help a great deal. It would also be good to use
> consistent capitalization, and maybe even try to use the same
> kinds of boxes as in Figure 1.