Subject: Concerns about domain based names drafts

From: Sam Hartman <[email-masked]>
Date: Thu, 17 Jan 2008 14:09:24 -0500

Folks, trying to resolve the domain based name drafts.

In the base spec, the IANA considerations does not describe which registry IANA should make an OID assignment in.

Also, the text sounds like you are recommending a value for the ASN.1
OID string.
However your recommended value includes underscores; I didn't think that was permitted.

I think you want to separate the OID assignment from the recommended constant name (and value) for C bindings.

Section 5 seems to normatively introduce gss_import_name_utf8.  The
specification of that function is not sufficient for implementation.
In addition, I didn't think we planned to introduce import_name_utf8
or display_name_utf8 in this spec.  I thought we intended to have an
informational note explaining how those functions will deal with the
domain based names.
The behavior for ACE encodings ing existings functions does need to be normative.

The kerberos draft still uses .tld examples rather than .example
examples.

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Sam Hartman <[email-masked]>
Date: Thu, 17 Jan 2008 14:11:27 -0500

Another important issue:
The ABNF is hugely garbled in the draft.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 18 Jan 2008 10:06:43 +0000

>The ABNF is hugely garbled in the draft.
Yes, my mistake. I forgot to insert "=" :-).

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 18 Jan 2008 20:38:53 +0000

Hi Sam,

>In the base spec, the IANA considerations does not describe which registry IANA should make an OID assignment in.
I need help on locating the corresponding registry.

>However your recommended value includes underscores; I didn't think that was permitted.
There seem to be some mistake here. The parent OID had no underscores 
anywhere.

>I think you want to separate the OID assignment from the recommended constant name (and value) for C bindings.
Right.

>The behavior for ACE encodings ing existings functions does need to be normative.
Nico should comment on this.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 21 Jan 2008 22:12:13 -0600

On Thu, Jan 17, 2008 at 02:09:24PM -0500, Sam Hartman wrote:
> In the base spec, the IANA considerations does not describe which
> registry IANA should make an OID assignment in.

OK, this is not a problem.

> Also, the text sounds like you are recommending a value for the ASN.1

Yes.  IANA gets a pass at the document before it makes it onto the
RFC-Editor queue, so this did not trouble me.

> However your recommended value includes underscores; I didn't think

-05 says:

   IANA is requested to assign a new OID for the new GSS-API name type
   defined in this document.  This OID should have the following prefix:

   {iso(1) org(3) dod(6) internet(1) security(5) nametypes(6) gss-
   domain-based(5)}

No underscores there... :)

> I think you want to separate the OID assignment from the recommended
> constant name (and value) for C bindings.

The constant name is not being registered (there being no registry for
the name).  Hmmm...  Is there even a registry for {iso(1) org(3) dod(6)
internet(1) security(5) nametypes(6)}?  I don't see one.

> specification of that function is not sufficient for implementation.

I what way is it not sufficient?

> informational note explaining how those functions will deal with the

I don't see why we cannot introduce these here.  These functions are
pretty much the result of the discussions at Chicago and on the list.

> The behavior for ACE encodings ing existings functions does need to be

It isn't?

> The kerberos draft still uses .tld examples rather than .example

Oops, I can fix that.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 22 Jan 2008 08:17:49 -0500

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> Oops, I can fix that.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 22 Jan 2008 10:12:17 -0600

>     Nicolas> Oops, I can fix that.

Did you mean to say something other than quoting me?  :)  Or is this a
hint that I should just submit a new I-D?

---

From: Sam Hartman <[email-masked]>
Date: Tue, 22 Jan 2008 17:27:43 -0500

>> I think you want to separate the OID assignment from the
    >> recommended constant name (and value) for C bindings.

    Nicolas> The constant name is not being registered (there being no
    Nicolas> registry for the name).  Hmmm...  Is there even a
    Nicolas> registry for {iso(1) org(3) dod(6) internet(1)
    Nicolas> security(5) nametypes(6)}?  I don't see one.

I think you do want to say what constant people should use; I don't
think you can register it since there is no registry.

    >> Section 5 seems to normatively introduce gss_import_name_utf8.
    >> The specification of that function is not sufficient for
    >> implementation.

    Nicolas> I what way is it not sufficient?

Doesn't define inputs, outputs, statuses, semantics.  Yes, a lot of
this text will be copied from the existing spec.  However if you are
going to define new functions you need to actually specify all the
things that 2743 does for the functions.

    >> In addition, I didn't think we planned to introduce
    >> import_name_utf8 or display_name_utf8 in this spec.  I thought
    >> we intended to have an informational note explaining how those
    >> functions will deal with the domain based names.

    Nicolas> I don't see why we cannot introduce these here.  These
    Nicolas> functions are pretty much the result of the discussions
    Nicolas> at Chicago and on the list.

They are not within the scope of the draft.

    >> The behavior for ACE encodings ing existings functions does

    Nicolas> It isn't?

No, I was making it clear that this should not change.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 22 Jan 2008 16:56:22 -0600

> think you can register it since there is no registry.

Either way, there's no registry even for that OID arc.

> things that 2743 does for the functions.

I disagree.  The text reads:

   Support for non-ASCII internationalized domain names SHOULD be
   provided through a new function, GSS_Import_name_utf8(), that
   operates exactly like GSS_Import_name(), except that it MUST accept
   internationalized domain names both, as UTF-8 strings and as ACE-
   encoded strings via its input_name_string argument.

GSS_Import_name_utf8() is defined in terms of GSS_Import_name().  I
think that should be sufficient.  Perhaps the text should be a bit
clearer ("operates exactly like" might not imply "has the same input
and output parameters" to some readers), but otherwise I think that
cutting and pasting text from RFC2743 and RFC2744 would do a disservice
to readers.

> They are not within the scope of the draft.

Please elaborate; why not?

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 24 Jan 2008 23:13:32 -0600

> registry IANA should make an OID assignment in.

I've fixed this.  There is no such registry, therefore there are no IANA
considerations.  However, the manner in which the OID was obtained is
now described.

> Also, the text sounds like you are recommending a value for the ASN.1

Now we just out and out allocate it.

> However your recommended value includes underscores; I didn't think

There were no underscores in the OID in the I-D.

> constant name (and value) for C bindings.

This is now irrelevant :)

> The behavior for ACE encodings ing existings functions does need to be

I believe the *_utf8() functions belong in this document.  I see no
reason to publish a separate RFC just describing those two functions.
I've seen no objections from the WG, but if desired we can call for
consensus.  I've updated the description, however, to be more exact.

The *_utf8() functions are recommended, while the ACE behaviour of the
regular functions is required.

> The kerberos draft still uses .tld examples rather than .example

Fixed.

New I-Ds have been submitted.

Nico
--

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 25 Jan 2008 10:28:54 +0000

>consensus.  I've updated the description, however, to be more exact.
Speaking as an individual: no objections from me.