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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 

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
--- Begin Message ---

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  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?

 

 

Cheers

 

Alan

Description: cid:image001.png@01CD4491.87A64560

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: alan.murdock@xxxxxxxxxxxxx  W: www.ncia.nato.int

 

 

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

 

FYI


--- End Message ---
--- Begin Message ---

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:Alan.Murdock@xxxxxxxxxxxxx]
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

 

 


--- End Message ---
[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]