[Ietf-not43] issues and questions on FIRS

[Andrew Newton]

I have a couple of questions regarding FIRS, some of them being 
complaince issues.
So that the lines between these issues do not blur, I've broken them out:

1) Naming Syntax of inetDnsDomainSyntax (Section 3 in 
draft-ietf-crisp-firs-dns).
2) The implementation of 3.1.8.
3) The implementation of 3.2.8.
4) Enumeration of error codes.

If I have simply overlooked something, I apologize.  Please hit me over 
the head with the pointers.

#1 - Naming Syntax of inetDnsDomainSyntax (Section 3 in 
draft-ietf-crisp-firs-dns).

First, I do not understand why the domain name is being specified as 
UTF-8.  I understand that this is being done in consideration of IDN's, 
but this is a service about the actually registered domain names.  While 
the UTF-8 equivalences are important, the key for the domain names (the 
rdn in this case) should be the wire equivalence since this about the 
registration of these domain names.  In other words, I think the key 
should be the 7-bit ASCII versions that show up in zone files and via 
dig, etc... and not the 8-bit versions.

Second, why are the 8-bit versions escaped?  Is there an issue with 
supporting UTF-8 or Unicode?  Just curious.

Third, point (a) in that section states how the escaped values must be 
stored.  I don't know if this is valid or not.  It could be right, but 
I'm a little concerned that this is making an assumption about how 
information is stored in a registry/registrar that just doesn't exist. 
As in, it MUST be this version of the ASCII escaped UTF-8, when what is 
stored might actually be the ASCII version and the Unicode version 
(non-escaped).

#2 - The implementation of 3.1.8.

There was mention of 3.1.8 in the meeting by Peter, but I do not see it 
addressed in the drafts.  Looking through the jabber logs, Peter 
proposed various methods to do this.  These were defined as: using the 
bind operation, special policy entries, and server-side extended operations.

The use of the bind operation would be overloading of LDAP's 
authentication mechanism and would likely cause confusion.  Plus I do 
not see how it would be tied to a query.  The second option of 
special-purpose policy entries would probably work, but I think the 
convention for doing it would be hard to coordinate.  The third option 
of an extended server-side operation I do not understand.

It would seem that this would be easily done with another control.  As 
in, the control for "only check permissions" is set and then the query 
is issued.  The control is then "released" after the answer.  I don't 
know.  This is just me theorizing.

Because LDAP supports a generic query syntax and because service 
providers are likely to deny all queries not explicitly allowed to 
prevent data mining, this requirement seems more important for the FIRS 
proposal.

#3 - The implementation of 3.2.8.

Looking at the jabber logs, there is also discussion of this item with 
theorizing about how it might be done but no mention of it in the 
drafts.  Nor can I find it.  I think the conversation in the jabber logs 
is correct with regard to this only needing to be done on the LDAP 
attribute level and not the LDAP value level, which Peter seemed to 
think would be harder to do.  However, either the control or the 
reserved values (or whatever) do need to be specified.

#4 - Enumeration of error codes.

Given the recent discussion on error codes and the mention of these in 
the jabber logs, I think it is necessary to fully enumerate them so that 
we can better understand what needs further clarification.  Some of the 
error codes would naturally map to existing LDAP error codes, but as we 
discussed with the bags, some will not.  This will help with listing 
which new codes needed to be defined.

-andy