Summary

RFC 2251 fidelity

Represent existing directory protocols with new transport syntax

Backwards compatibility with DSML 1

Use XML - AGREED

Transport protocol independence

OOB security

Directory interoperability for very common operations – UNRESOLVED, DEFER

Optional knowledge of tree structure – UNRESOLVED, DEFER

Batching

URL naming

RFC 2251 Fidelity

Means anything you can do with LDAP still makes sense, client can use either

But doesn’t include bind

Does include extended operations and controls (agreed but question whether they work well). Basic controls needed to support raw extensibility.

Doesn’t include inetorgperson, 2256, etc.

Need 2252, 2253, 2254, 2255 et al also? – no 2251 is core

What do we use for the filter representation?

How we represent stuff is less crucial than that there is a mapping of the operations.

Questions on RFC 2251 fidelity

Is it limited to request/response – not async ops or unsolicited notifications

Represent existing directory protocols with new transport syntax

Don’t want new protocols

Don’t want divergence in way protocols are handled

2251 conformance necessary but not sufficient

What about LDAP extensions, VLV etc?

Just make an alternative representation, don’t try to solve LDAP problems in DSML

Proposed additions that might provide functionality not in LDAP should be evaluated very carefully. (Eg. specifying serial/parallel operation and interoperability for common operations)

Backwards compatibility with DSML 1

Do we use DSML 1 syntax where possible?

Attributes with structured syntax could be a problem – want to make them more XSLT-friendly (they are opaque in DSML 1.0)

Transport protocol independence

Bind, async operations are issues.

We should identify specific protocols that can be used.

If simple request/response, then can use any protocol

Could be useful to have standard mappings to some particular protocols.

OOB Authentication

Do credentials stay in the transport layer or can they be exposed at the application layer?

Have transport credentials at application layer plus additional credentials also

Issue of re-using secured connections for performance reasons

Require OOB authentication and have inband authentication as an option also?

How is identity asserted for access control?

Is there a man-in-the-middle attack if authentication is OOB?

Should Id and authentication information be included in DSML? AGREED NOT

I.e. agreed no inband authentication

Batching

DSML should not specify serialism or parallelism of operations

With a large number of operations, it can be valuable to be able to say which can be performed in parallel

This can make processing complex

But doesn’t have to – serial is default and can be used even where parallel is indicated

So it’s OK provided it is truly optional – agreed should be an explicitly stated advisory option in DSML 2

URI naming

Ability to access a URI that has a directory operation encoded in it and have the result of the operation returned in DSML (a la LDAP URL)

Have to understand what this means in context of transport independence.

Eg dsml://host:port.dc=xx . .

Are they needed for referrals?

Defer until we have a written proposal.

Defined relationship to SAML

Use of DSML by SAML and use of SAML by DSML

Don’t want to rely on SAML for any authentication

SAML may be interested in using DSML, but don’t want to hold DSML work up

Unsolicited notification of change

Related to lcup?

Has to be protocol-dependent

Leave it to post 2.0? Could then be harder to put it in if we want to

Doesn’t impact the format of DSML

But would want to include unsolicited notification (from 2251) in the DTD

Agreed defer pending receipt of a written proposal.

XSLT-friendly

Structured attributes – eg comma-delimited not tagged – harder to process. More general XML issue than just XSLT

Agreed that this is an aim

Different types of Referral

Referral v Continuation reference

Issue of LDAP URL

Agree do what LDAP does & defer anything above this to v 3.0

There are broader issues beyond LDAP that should be addressed, but later

Schema Discovery

LDAP supports this, but way you do it may differ between LDAP servers

The LDAP standards do cover this

Group needs to validate what products do

Should there be a standard translation that transforms the LDAP representation of the schema to XML?

But given timescale we should leave things other than just doing what LDAP does to a later version.

Ability to define enums, ranges etc.

Aids processing text strings that have internal structure

Should be addressed at the LDAP level rather than the DSML level

XML Schema

Potential v3 item.

Can be expressed with a DTD

Ie – the DSML language itself should be able to be so expressed

DTDs have limited capability to express certain things – such as can’t say that an attribute must be either a string or two or more value tags. Eg. Can’t precisely express rules for a credit card number.

XML schema should be provided as a bare minimum

There are many DTD-oriented XML tools, some recently that work on schema.

Desirable to have a DTD but

MS draft uses a schema

Leave as open issue.

Do as schema first – then consider making DTD (but leave schema as the normative version)


	RFC 2251 fidelity
	Represent existing directory protocols with new transport syntax
	Backwards compatibility with DSML 1
	Use XML - AGREED
	Transport protocol independence
	OOB security
	Directory interoperability for very common operations – UNRESOLVED, DEFER
	Optional knowledge of tree structure – UNRESOLVED, DEFER
	Batching
	URL naming


	Means anything you can do with LDAP still makes sense, client can use either
	But doesn’t include bind
	Does include extended operations and controls (agreed but question whether they work well). Basic controls needed to support raw extensibility.
	Doesn’t include inetorgperson, 2256, etc.
	Need 2252, 2253, 2254, 2255 et al also? – no 2251 is core
	What do we use for the filter representation?
	How we represent stuff is less crucial than that there is a mapping of the operations.


	Is it limited to request/response – not async ops or unsolicited notifications


	Don’t want new protocols
	Don’t want divergence in way protocols are handled
	2251 conformance necessary but not sufficient
	What about LDAP extensions, VLV etc?
	Just make an alternative representation, don’t try to solve LDAP problems in DSML
	Proposed additions that might provide functionality not in LDAP should be evaluated very carefully. (Eg. specifying serial/parallel operation and interoperability for common operations)


	Do we use DSML 1 syntax where possible?
	Attributes with structured syntax could be a problem – want to make them more XSLT-friendly (they are opaque in DSML 1.0)


	Bind, async operations are issues.
	We should identify specific protocols that can be used.
	If simple request/response, then can use any protocol
	Could be useful to have standard mappings to some particular protocols.


	Do credentials stay in the transport layer or can they be exposed at the application layer?
	Have transport credentials at application layer plus additional credentials also
	Issue of re-using secured connections for performance reasons
	Require OOB authentication and have inband authentication as an option also?
	How is identity asserted for access control?
	Is there a man-in-the-middle attack if authentication is OOB?
	Should Id and authentication information be included in DSML? AGREED NOT
	I.e. agreed no inband authentication


	DSML should not specify serialism or parallelism of operations
	With a large number of operations, it can be valuable to be able to say which can be performed in parallel
	This can make processing complex
	But doesn’t have to – serial is default and can be used even where parallel is indicated
	So it’s OK provided it is truly optional – agreed should be an explicitly stated advisory option in DSML 2


	Ability to access a URI that has a directory operation encoded in it and have the result of the operation returned in DSML (a la LDAP URL)
	Have to understand what this means in context of transport independence.
	Eg dsml://host:port.dc=xx . .
	Are they needed for referrals?
	Defer until we have a written proposal.


	Use of DSML by SAML and use of SAML by DSML
	Don’t want to rely on SAML for any authentication
	SAML may be interested in using DSML, but don’t want to hold DSML work up


	Related to lcup?
	Has to be protocol-dependent
	Leave it to post 2.0? Could then be harder to put it in if we want to
	Doesn’t impact the format of DSML
	But would want to include unsolicited notification (from 2251) in the DTD
	Agreed defer pending receipt of a written proposal.


	Structured attributes – eg comma-delimited not tagged – harder to process. More general XML issue than just XSLT
	Agreed that this is an aim


	Referral v Continuation reference
	Issue of LDAP URL
	Agree do what LDAP does & defer anything above this to v 3.0
	There are broader issues beyond LDAP that should be addressed, but later


	LDAP supports this, but way you do it may differ between LDAP servers
	The LDAP standards do cover this
	Group needs to validate what products do
	Should there be a standard translation that transforms the LDAP representation of the schema to XML?
	But given timescale we should leave things other than just doing what LDAP does to a later version.


	Aids processing text strings that have internal structure
	Should be addressed at the LDAP level rather than the DSML level


	Ie – the DSML language itself should be able to be so expressed
	DTDs have limited capability to express certain things – such as can’t say that an attribute must be either a string or two or more value tags. Eg. Can’t precisely express rules for a credit card number.
	XML schema should be provided as a bare minimum
	There are many DTD-oriented XML tools, some recently that work on schema.
	Desirable to have a DTD but
	MS draft uses a schema
	Leave as open issue.
	Do as schema first – then consider making DTD (but leave schema as the normative version)