Meeting minutes
from DSML Teleconference -
1) List of
attendees
Winston
Bumpus Chaired
Shon Vella
Jeff Bohren
Rob Weltman
John McGarvey
Christine
Tomlinson
Gavenraj Sodhi
2) Minutes
Continued from paper:
-Voting decisions. Haven't talked about this yet.
Action: James Tauber and Gavenraj will work through rules and guidelines
----
DSML Filters
- RFC or XML-based
Representation of XML may be easier for clients?
- Easier for XML-based representation.
- e.g., smart cell-phone
Parse it either way. XML-based should be easier to parse
Do we have XML schema to represent XML schema?
- Sent out on Monday. Includes and, or, not.
- This was done in DAML. Done in DTD. Will be extracted. Not changed.
- We should have this written up. Action: Get this out and closed by next week.
Next item: Operational Grouping.
- Christine's latest proposal creates an idea that the grouping of operations should be seperated from the specification.
- Two different statements.
- Separate but needs to be discussed.
- Needs some sort of Operation Grouping as a replacement to LDIF and will simplify some types of clients. It is important that base DSML support the port of this groupings.
- We should have best practices. At a minimum their should be a clear distinction of transporting operations where they are clearly orchestrated.
- Take batch.exe and discuss it as specification.
- Where would this specification be agreed upon? Is it totally separate than this working group.
- No. Establish working group approach as to batch packaging of operations.
- Separating the batch proposal will help to build a better quality product for DSML
- Would you have a DSML v2 implementation that does not support batch?
- Sure.
- We talked about parallel vs. sequential. Are we saying that parallel or serial is going to be supported via DSML v2 xsd (batch.xsd)
- Can you give example where grouping of operations is not useful or is a burden on implementation?
- XML.gateway does not require. Uses a different strategy of orchestration of operations. Batch would be additional stuff that would not be part of that application.
------
Notion of having request ID is good idea but not sure how that decision will make an impact.
- Close grouping of operations discussion? Would not reach consensus... Should be fundamental part of DSML v2, multiple operations of DSML client.
- Bind is out of band for DSML v2.
- One operation at a time vs. many operations occurring...
- If we set batch aside, XML document may still be sent with multiple request without batch envelope. Advantages of envelope, requests are grouped together, and support asynchronous operations as discussed in John's mail.
- To john's point, many operations may be sent in one file. Sync in orchestration of operations. In Microsoft proposal this was very limited.
- Does an envelope preclude iPlanet's model.
- Should have layered approach to build on top of.
- iPlanet states that should have set of operations.
- Does it have to be in base spec?
- Should not be an issue as not much has been specified? e.g.., bind information with XML elements, referrals...
Action: Understand to what degree is build a framework vs. full specification what DSML v2 server and DSML v2 client can talk to.
- Question on request IDs. Comes under operation grouping? Great idea. Consensus.
- Makes a statement that DSML v2 encourages asynchronous activities as well as synchronous.
- Adds bare metal to DSML where you can add asynchronous to the top of.
-------------
DN Aliases
- Idea is to not require DSML v2 applications to have to have a lot of name space traversal logic. e.g., user trying to get his information but doesn't know his dn.
- What gateway would have to do is to have a way to assign a meaning to this.
- This (authenticated identity)
- Person Query Route (where do you place in the tree) e.g., hosted environment
- Create route
-Physical
- Service
- Would like to see some extensibility strategy not just a list. Aliases bound to various DNs.
- This should go to the LDAP level
- LDAP does not have this.
- This is an implementation detail.
- DSML v2 should be nice for this to go forward.
- We did not want DSML to cover up what can be done in LDAP.
- Suggestion: Someone should take a stab at defining criteria what should be done LDAP vs DSML v2.
- Would take a long time to get into LDAP and would take a short time for DSML. Would solve some things within IETF in respect to implementation details.
- Item is still on the table.
- Parallel processing (purposes of transaction) which is very different in MS Proposal.
Action ITEM: Get some proposals to the table for putting verbose into DSML.
- Distinguish names as an implementation
- What notion of interoperability we are trying to achieve? Not clear if bind (if put of band) may help with interoperability.
Christine Action Item: Put straw proposal on Bind proposal and filter mechanism.
- Flush out proposal on Aliases.
---------------------
F2F discussion - postponed till next week.