Re: [ldapext] New Version Notification for draft-stroeder-mailboxrelatedobject-06.txt

[Kurt Zeilenga <[e-mail]>]

Just for the record, the Independent Submission Editor contacted me regarding this draft.  As I'm not terribly active in the LDAP community these days, I suggested he seek review elsewhere such as on this list.

I also noted a couple of things which the IESG might want to consider when the I-D comes before them as an independent submission.
a) Defining an auxiliary object class simply allows 'mail' to be present on entries belong to that class would likely be non-contentious and not terribly likely to create inter-op issues with use of 'mail' as described in standard track documents.

b) How to deal with Internationalized email address in LDAP however is likely far more contentious and far more likely to create inter-op issues with use of 'mail' as described in standard track documents.

That is, I basically hinted that the progressing an independent submission for a simple aux class that allowed for 'mail', and only 'mail', to be present in entries of the class is likely not something that would step on IETF toes... but that doing anything with Internationalized Email Addresses likely would.   However, as I don't have an iron in this fire, I suggested ISE ask an Apps AD early as to what parts of this I-D do step on the IETF toes (one could argue that as there's little LDAP activity in the IETF that none of this does).

Michael, I note that while independent submission is restricted to Informational and Experimental, one doesn't need a WG to pursue standard track.  The IETF processes does allow for individual submissions to be considered for standards track.  (note: independent submission != individual submission). 

Regarding Directory String, I note that while can transfer a BER encoded DirectoryString value, and that would indicate a CHOICE, aside from more commonly transferred using the LDAP syntax (1*UTF8), transfer of BER doesn't imply preservation of the CHOICE.   The general LDAP value preservation rules allows, for instance, a server to return Universal String (in ;binary transfer if they support it for the attribute) even though the value added was a Printable String (when added using ;binary).

Lastly, regarding standardizing Password Policy...  at one time the IETF had before multiple I-Ds here and no clear consensus on which to pursue.  Now there's multiple flavors of password policy in the wild... as well as an X.500 specific password policy spec.    Maybe with different players consensus can be achieved... but I suspect that if the IETF were to pursue this again, especially by forming a WG, that it would likely flounder again due to lack of consensus on various issues.   One might get further by writing an informational RFC which simply documented what some set of implementations do.

-- Kurt