Subject: NATO Comments on <draft-kille-ldap-xmpp-schema-01.txt> (LDAP Schema for supporting XMPP in White Pages) to Informational RFC

From: "Steve Kille" <[email-masked]>
Date: Mon, 11 Sep 2017 08:37:25 +0100

I received some comments from Alan Murdock / NATO on the draft.   I thought
it would be helpful to share these comments and my response

These will be addressed in the update -03 of this specification

Steve

Subject: RE: Last Call: <draft-kille-ldap-xmpp-schema-01.txt> (LDAP Schema for supporting XMPP in White Pages) to Informational RFC
From: "Murdock Alan" <[email-masked]>
To: "Steve Kille" <[email-masked]>
Date: Wed, 6 Sep 2017 13:28:05 +0100

Steve,

Thanks for providing with insight on this matter and accept my profuse
apologies for being unable to respond earlier. The following comments have
been coordinated among a limited group of key stakeholders in the Agency
including Michael Laukner and his team. If you have any questions or
concerns, please let me know.

Comments from NCIA on < draft-kille-ldap-xmpp-schema-01.txt >:

Para 3.1

"This section defines a new Auxiliary Object Class (JIDObject) which   may
be associated with any primary structural Object Class." 

RFC4512 does not define a "primary" Object Class.

Or perhaps better,  copy the style of RFC4523 and say:

"This section defines a new Auxiliary Object Class (JIDObject) that is used
to augment entries for objects that act as an XMPP entity."

What does it mean when an entry has the objectclass JIDObject but it doesn't
contain a 'jid' attribute (as the 'jid' attribute is marked as optional)?

The uidObject (RFC4519), simpleSecurityObject (RFC4524), nisObject
(RFC2307), domainRelatedObject(RFC4524) and  dcObject(RFC4519) are all
auxiliary object classes with a single attribute which is mandatory. So for
example, if an entry does not have a 'uid' attribute, it is not marked as a
'uidObject'.

It would make sense to be consistent with this approach and make the 'jid'
attribute mandatory within JIDObject object class. 

(It is noted that labeledURIObject (RFC2079) is the exception to the above
rule.)

Para 3.2

"This section defines the JID attribute referenced by the ObjectWithJID
JIDObject Auxiliary Object Class." This should be "JIDObject auxiliary
class".

Para 5

"This schema enables publishing for the publication of XMPP JIDs, . "

Overall:

.         Refer to the object class as "jidObject" rather than "JIDObject" -
as per other auxiliary classes noted above.

.         Security Considerations should point to RFC 4510 for general LDAP
security considerations.

.         The addition of a Terminology Section can succinctly describe  a
"bare JID" and a "full JID" with a an example to illustrate the difference
without having to search in RFC 7622 for an understanding.

.         Is there anything we need to be cogniscent about with relation to
string comparisons? In LDAP string prep is defined in RFC 4518  which is
based upon RFC 3454. RFC 7622 moved away from RFC 3454 to RFC 7465. At least
some wording needs to be included related to potential discrepancies.

.         After reviewing
<https://technet.microsoft.com/en-us/library/cc961575.aspx>
https://technet.microsoft.com/en-us/library/cc961575.aspx  and
<http://www.rfc-editor.org/rfc/rfc4519.txt>
http://www.rfc-editor.org/rfc/rfc4519.txt  it is not clear whether there is
an impact when setting up a user account in AD. Can you clarify or provide
guidance e.g. does it imply that for every user account, the "jid" has to be
assigned?

Cheers

Alan

Alan Murdock

Principal Scientist

NATO Communications and Information Agency

Core Enterprise Services | 

Oude Waalsdorperweg 61, 2597 AK The Hague, Netherlands

T: +31 70 374 3555

E:  <mailto:> [email-masked]  W: www.ncia.nato.int

From: Steve Kille [mailto:[email-masked]] 
Sent: Friday, September 01, 2017 6:16 PM
To: [email-masked]
Subject: FW: Last Call: <draft-kille-ldap-xmpp-schema-01.txt> (LDAP Schema
for supporting XMPP in White Pages) to Informational RFC

FYI

Subject: RE: Last Call: <draft-kille-ldap-xmpp-schema-01.txt> (LDAP Schema for supporting XMPP in White Pages) to Informational RFC
From: "Steve Kille" <[email-masked]>
To: <[email-masked]>
Cc: "'Steve Kille'" <[email-masked]>
Date: Thu, 7 Sep 2017 16:05:29 +0100

Alan,

I really appreciate the comments.      These will be reflected in an update.

May I share your message and this response with IESG?

From: Murdock Alan [mailto:[email-masked]] 
Sent: 06 September 2017 13:28
To: Steve Kille
Subject: RE: Last Call: <draft-kille-ldap-xmpp-schema-01.txt> (LDAP Schema
for supporting XMPP in White Pages) to Informational RFC

Steve,

Thanks for providing with insight on this matter and accept my profuse
apologies for being unable to respond earlier. The following comments have
been coordinated among a limited group of key stakeholders in the Agency
including Michael Laukner and his team. If you have any questions or
concerns, please let me know.

Comments from NCIA on < draft-kille-ldap-xmpp-schema-01.txt >:

Para 3.1

"This section defines a new Auxiliary Object Class (JIDObject) which   may
be associated with any primary structural Object Class." 

RFC4512 does not define a "primary" Object Class.

[Steve Kille] 

You are right that the word primary is not defined.  I will remove 

Or perhaps better,  copy the style of RFC4523 and say:

"This section defines a new Auxiliary Object Class (JIDObject) that is used
to augment entries for objects that act as an XMPP entity."

[Steve Kille] 

I'll use some of tis wording.

What does it mean when an entry has the objectclass JIDObject but it doesn't
contain a 'jid' attribute (as the 'jid' attribute is marked as optional)?

[Steve Kille] 

I think that it can be useful to define an object as "capable of having a
JID added".     Directory editors which can be driven by schema, such as our
Sodium product can make use of this.    I will reflect this in the text.

The uidObject (RFC4519), simpleSecurityObject (RFC4524), nisObject
(RFC2307), domainRelatedObject(RFC4524) and  dcObject(RFC4519) are all
auxiliary object classes with a single attribute which is mandatory. So for
example, if an entry does not have a 'uid' attribute, it is not marked as a
'uidObject'.

It would make sense to be consistent with this approach and make the 'jid'
attribute mandatory within JIDObject object class. 

(It is noted that labeledURIObject (RFC2079) is the exception to the above
rule.)

[Steve Kille] 

I think that optional is right here.

Para 3.2

"This section defines the JID attribute referenced by the ObjectWithJID
JIDObject Auxiliary Object Class." This should be "JIDObject auxiliary
class".

[Steve Kille] 

Thanks.   This was spotted and is already sorted in
draft-kille-ldap-xmpp-schema- 02.txt

Para 5

"This schema enables publishing for the publication of XMPP JIDs, . "

[Steve Kille] 

Thanks - will sort the wording

Overall:

.         Refer to the object class as "jidObject" rather than "JIDObject" -
as per other auxiliary classes noted above.

[Steve Kille] 

I prefer JIDObject, as the XMPP convention is to use JID and not JID

.         Security Considerations should point to RFC 4510 for general LDAP
security considerations.

[Steve Kille] 

That is sensible

.         The addition of a Terminology Section can succinctly describe  a
"bare JID" and a "full JID" with a an example to illustrate the difference
without having to search in RFC 7622 for an understanding.

[Steve Kille] 

I'll add some examples to clarify.   I don't want to include definitions
that might in some way not be consistent with the normative definitions.

.         Is there anything we need to be cogniscent about with relation to
string comparisons? In LDAP string prep is defined in RFC 4518  which is
based upon RFC 3454. RFC 7622 moved away from RFC 3454 to RFC 7465. At least
some wording needs to be included related to potential discrepancies.

[Steve Kille] 

I don't think so.   Human usage is a key target.  I think that any apps
using the output of this should apply appropriate stringprep rules.   I'll
also note that the directory service doesn't enforce the JID syntax, and
note that values are compared according to the matching rule specified in
the attribute type description, not per XMPP rules.

.         After reviewing
https://technet.microsoft.com/en-us/library/cc961575.aspx  and
http://www.rfc-editor.org/rfc/rfc4519.txt  it is not clear whether there is
an impact when setting up a user account in AD. Can you clarify or provide
guidance e.g. does it imply that for every user account, the "jid" has to be
assigned?

[Steve Kille] 

This should definitely not have implications on AD.  It does not feel quite
right to comment on this.   I can't see why this might imply AD has to use
JIDs.

Cheers

Alan

[Steve Kille] 

Really appreciate the comments.

Best Regards

Steve