Reference Implementation Meeting 2010-07-27

Notes from Reference Implementation Workgroup
Date: July 27, 2010
Time: 12pm-1pm
Attendees: Srinivas Chennamaraja, George Cole, Didi Davis, Greg Meyer, Richard Braman, Stephen Outten, John Moehrke, Paul Saxman, Don Jorgenson, Patrick Pyette, Nael Hafez, Vince Lewis, Umesh Madan, Andy Thorson, Arien Malec, Brian Behlendorf, Uvinie Hettiaratchy, Charles Curran, Chaminda Gunaratne, Chris Lomonico, Srinivas Koka, Claudio Sanchez
Actions from this Week

#	Date	Action	Status	Owner	Due Date
11	07/27/10	Look into hosting options	Open	Brian Behlendorf	8/03/10
12	07/27/10	Ask Implementation Geographies group to do list of end user email clients.	Open	Brian Behlendorf	07/28/10

Actions from last Week

#	Date	Action	Status	Owner	Due Date
9	07/20/10	Update code source repository with changes	Open	Arien	7/27/10
10	07/20/10	Meet within subteams and develop wiki pages	Open	WG	07/27/10

Notes
Brian Behlendorf

• Would like to go through an update on progress so far. Then open up to conversation about scheduling.
• Increase participation in August 17th deliverables.
• Most progress made by C# team.

Umesh Madan

• Just made a check in this morning with some more fixes on API. First sample of integration with SMTP server. Same integration used for demo. Intended as a sample to give people an idea.
• Would like to set up another call later this week. Met with smaller team last week.
• Sean wrote up a document that discusses at a higher level the various components that we need and divvy up the work.
• If you haven’t seen it yet, it’s linked off the C# Implementation page.
• We need work done on sequelSQL database.
• Another thing I’d recommend is that it might be happy to have the XDR/XDS teams across Java and C# to talk to see if any common patterns.
• Going to work on getting the gateway built. Goal is to get it done this week.
• More unit tests also being done.

Sri Koka

• Great work from Sean. In last week’s meeting, discussed C# methodology. Not familiar with open source documents. Sean did some great work on that.
• He put some thoughts on how XDS B can be incorporated with NHIN Direct.
• Once Umesh has SMTP work done, we will put XDS messages with SMTP protocol.

Umesh Madan

• Can start development work upfront because code can be written regardless and can be built independently.
• Goal by next week is to have something to run a script.
• The source management system, I’m still getting used to it.
• This is a voluntary system, we’re looking to people to own an area and do what you think is right and then wait for feedback.

Arien Malec

• Brian, what do you think about passion winning over process?

Brian Behlendorf

• Only risk is that people can say that other people are handling the problems. We should think about how new people arrive on set of pages related to reference implementation and know how to plug in. This is a challenge.
• Right now it feels like there’s a lot of momentum, but hard to map that momentum to progress. Not sure how to map that against what pilots are going to need.
• Once we reach a milestone, it’d be useful to create some content that could be looked at by participants to see where they can plug in.

Umesh Madan

• Precisely that concern.
• It might be useful to take Sean’s doc and move to wiki.

Brian Behlendorf

• Having an updated page for 14 different reference implementations would be helpful.

Umesh Madan

• If other people who want to look at agent code for .NET and learn about it, please let me know.

Srinivas Chennamaraja

• We’re trying to figure out where we can help. Any SMTP implementations with Java?

Arien Malec

• There is some Java work laid out on the wiki.

Srinivas Chennamaraja

• I looked at software components and we can help with admin tools. I don’t know what the priority is and where that fits in. Would like to help with that for Java.

Umesh Madan

• Any expertise would be welcome.

Brian Behlendorf

• In terms of admin, most people have their own DNS servers already and putting a CERT record is not a software change, but a change in configuration.

Umesh Madan

• On Windows side, we’re going to use MIME, which we’re not used.

Brian Behlendorf

• Anything in here is free game. The best way to do that is to start fleshing out wiki pages. As you can see from reference implementation components page.

Sri Koka

• How does the process work? Whose going to pitch in requirements?

Arien Malec

• We do have a specification for the agent, which Umesh and Sean wrote and edited and published. There is a requirements document in terms of the specification.

Greg Meyer

• Since we’re doing this in split languages, trying to do integration testing. Making sure reference implementations are in sync.

Umesh Madan

• Short term, what I would suggest is to update it periodically and make sure it’s working.

Greg Meyer

• Maybe what it comes down to is that each team has to stand up an implementation of each language.

Sri Koka

• We can code, but hosting is expensive. Can any of the companies throw in some hardware to do sandbox testing? Any volunteers?

Arien Malec

• I think companies donated some technology before, and if that doesn’t work long term, should figure out something.

Brian Behlendorf

• If companies on the call can volunteer, that would be great.
• If not, I can take an action item to look into it, but would take time and may be more expensive.
• If others on the call can think about volunteering that in the next few days that would be great.

Umesh Madan

• Still working on it internally, so more information coming soon.

Brian Behlendorf

• Maybe Codeplex would have something for us. I will look into it.
• Any other questions regarding .NET implementation.
• Encourage organizations that have institutional investment in .NET making staff available.
• Greg Meyer – Java side?

Greg Meyer

• Last week we checked our initial proof of concept.
• Beyond that, no additional updates.
• We did do a resource allocation of getting agent up to date.
• Over next week or two, you will see current agent coming up to spec.
• Other than that, we don’t have resource commitments to that.

Brian Behlendorf

• No outstanding code to check in? Or your contribution is set at what you have now?

Greg Meyer

• We haven’t prioritized what our commitment is going to be above and beyond the agent. We will get it up to Umesh’s spec and get that in by next week.
• Have more information later on in the week.
• We do have Java key store and people are using with success inside Java code base. We provided a populated key store.

Umesh Madan

• What we have so far should be enough to get people rolling.
• As you look at spec, please correct or enhance spec.

Brian Behlendorf

• Maybe hold off on updates with Java unless someone else has remaining questions?

Greg Meyer

• One of the things we did provide is bridge the gap between SMTP and agent. As we push code over next few weeks, going to look at other paradigms, not just Apache. I know Umesh is looking at Microsoft SMTP. Provide documentation around post fix.

Umesh Madan

• Interested in finding out how that goes.

Brian Behlendorf

• I think that’s fine. There has to be at least one configuration.

Greg Meyer

• We did some analysis and even if you pick one stack with postfix, there are three or four configurations that you could run. I put a small post out there in terms of documentation. We really need deployment strategy. It’s really going to depend on what your stack looks like.

Umesh Madan

• In end reference implementation team needs to present recommended bits.

Srinivas Chennamaraja

• How do you test that reference implementation conforms to a spec?

Umesh Madan

• Since writing spec ourselves, there is a test and implementation group which will verify this.

Arien Malec

• A conformance guide is a key deliverable. Assuming that this group will support that.

Greg Meyer

• Can do that through some functional tests.

Brian Behlendorf

• Encourage to make use of wiki when possible.

John Moehrke

• One other piece of conformance testing and another reason to write implementation guide is to make sure we’re also hitting the requirements of NHIN Direct.
• I’m concerned we’re spending a lot of time on how to re-invent an email application. Are we also making sure these agents can interoperate with off the shelf email applications?

Umesh Madan

• That’s my primary test environment.

Greg Meyer

• That’s my point with bridging piece. We’ll go through conformance testing on that piece. But hard to test every off the shelf technology.

John Moehrke

• I was talking about email client. One of the expected ways to use NHIN Direct in most low tech way for the doctor is using something like Thunderbird. If they can’t just use off the shelf email clients, and yes there’s no automation, when talk to agents that do have automation, we may have missed the mark.
• As working with reference model, you should look at this. May have gone too far in writing specification and it no longer interoperates with off the shelf email client.

Umesh Madan

• Absolutely, we are testing with email clients like Outlook Express.
• Hoping will have volunteers for testing and finding bugs.

Brian Behlendorf

• We started a page that describes technology environment for average clinician.
• We can take that further and create list of commonly used version numbers.
• Use it also to reach out to programmers.
• Would benefit from having volunteers using average emails clients to use that.

Umesh Madan

• Coming up with classic test matrix would be useful.

Brian Behlendorf

• Worried about end user side more than server side. Maybe we can ask Implementation Geographies team to pull what they’re using.
• That’s another option for us.

John Moehrke

• Also want system to stress that sender who is not using server and receiver that is not using one either. If we don’t interoperate with that environment, don’t understand why using SMTP and using a special agent.
• NHIN already has Connect infrastructure which is an agent that can already talk to all kinds of things.

Greg Meyer

• As part of testing scenario, we did that – tested conformance for native S/MIME and it’s being taken into consideration. Probably more.

Umesh Madan

• Those are in fact a lot of our test cases. The current proposal is to wrap messages in a certain way to make sure all sensitive headers are protected. The way I’ve written agent, depending on how that works out, either way you can set various options for wrapped messages or not. If we wrap messages, default mail clients will not.
• I assume that debate can go on for a bit.

Arien Malec

• I agree with John that we should prioritize testing with ordinary email clients.
• We agreed on taking local responsibility for what’s in and outside of the package. This is another vote for believing that testing with ordinary email clients is a good thing.

Umesh Madan

• What about wrapping?

Arien Malec

• If you’re taking responsibility for encryption, then taking responsibility for what’s inside and outside.

John Moehrke

• If our interoperability layer is such that the only way to succeed is to use the agent model, we have just reinvented the wheel and forcing people to take SMTP and add stuff to it.

Arien Malec

• I think we all agree. The goal here is to have both an agent model that allows transparent encryption for providers who don’t have capability to and who can.

Greg Meyer

• We need to make sure we’ve listed out different deployment models. What the real implementation model is. I agree that standalone S/MIME model needs to be captured.

Umesh Madan

• Look at document that Sean wrote as well. Maybe do a similar one for Java.

Brian Behlendorf

• Action item to ask Implementation Geographies to put together list of end user clients. Corresponding to that, for each of the technology partners in the pilots, asking them their preference for server stack or operating system. End user software is more diverse and harder to enforce.
• If somebody wants to put a page for testing framework for volunteer, that would be cool.
• Clear to me that we need more hands on deck.
• This is difficult to do at beginning of open source project.
• We don’t have luxury of time here so since we do have many companies and quite a few on this phone.
• Two parts to a strategy to get to a point for pilot worthy code:
  • We find a complement to Umesh and Sean on Java side. Hopefully more than one person – project manager who can articulate skeleton of what needs to be pulled together.
  • Focused coordinated effort to have a one week sprint sometime in August. Having a week period where we have clear commitments from developers.
  • To take something from a skeleton, a step beyond list of components that we have.
  • Do a one week targeted sprint and some volunteers for that.
  • Complement with coordinated effort.

Claudio Sanchez

• This is something common. There are a lot of participants but few with expertise to jump into this. I’m finding it difficult to come up to speed. We want to participate but process not in place to put code into repository. Internally exploring what we can do. One of the examples is to get in touch with people and meet with them face to face and then come up to speed.

Arien Malec

• See a clear path for SMTP leg of this. Where we do need help is the XDR side of this. I’ve been doing calls for volunteer for XDS Metadata side of this. I would add to Brian’s suggestion for a focused end point and definition of 80% solution.
• Where we need to find volunteers.

Umesh Madan

• Targeted sprint would be helpful. In our minds we had a certain functionality, at end here’s what we have and the following cases did not work.

Uvinie Hettiaratchy

• In the short term, would be helpful to add names to the reference implementation components list already up on the wiki. Documentation and Testing WG also did this. Longer term, a column should be added for the more detailed skeleton that notes whose working on what.
• This way people will know who to get in contact with if they want to participate on a certain project. Also gives credit where it’s due.

Brian Behlendorf

• That’s a good suggestion. This discussion can be continued on the wiki.