Hi, I had an extensive discussion with Greg Newby yesterday morning on various topics, but most of the time we spent discussing the recommendation that Hiro brought up: "Why is SmartFrog-based language specification submitted as a recommendation track?" To be even more specific, Hiro recommended that it be resubmitted as a "Community Practice" because there will not be two reference implementations as a result of the standardization process. I checked with two other main drivers (Softricity and NEC) and neither indeed planned to pursue a reference implementation of the SmartFrog-based language at the time. I also checked with technical area directors and their recommendation was not to go with community practices because that track is applicable to something that is as commonly used as FTP and they have not considered SF to be that wide-spread. With all this information on my mind I approached Greg to discuss whether we should change submission to experimental or even informational track. Our discussion was quite productive. I updated Greg that SmartFrog is in fact in active use by a number of universities, HP, and other parties; that it has been open-sourced; and that the submitted spec is the most formal specification of the SF language (goes well beyond the reference manual published for the language, system, and component model). Then we discussed the issue of the target type. At the moment the document has reached the point of the recommendation track and formally we can take it any way we want. The reasons for sticking with the recommendation track are the following: a) At the moment it is not clear that there will or will not be another reference implementation and one already exists. Two other partners claimed that they will not create one, but it is possible that other parties may create one. We would need to come up with another independently implemented SF-language parser that would create the same output as the existing one. b) If the XML-based language interoperates with the SF-based language, that would be another proof point (this would require two other reference implementations of the XML-based language specs, though, but this is also open or the discussion). c) If after the process, there are no other reference implementations, we can still downgrade the document. However, Greg and I estimated the value of proceeding the recommendations track at the moment. I welcome comments to this discussion by email or by phone (650 236-2906 office, 650 468-3929 cell). Hiro, I appreciate your thoughtful suggestion. It was a good observation and it took us some time to truly understand all the implications. I hope that the final outcome works for you. If not, I'd be glad to continue discussion until we find a solution that will work for everyone. As you can see from the Greg's note below, we also agreed to provide some additional front-matter to the document. Finally, I will submit this email to Source Forge to capture this discussion. I recommend that any follow-ups also be submitted there. Thanks, Dejan. Greg's GridForge input is available at https://forge.gridforum.org/tracker/?func=detail&atid=414&aid=827&group_ id=90 and also copied below: Comment By: Greg Newby (2004-12-08 11:35:03) Per a telephone conversation with Dejan, I now agree this should be recommendation track. The authors are essentially providing a CDDLM specification which, at the same time, is the most formal specification for SmartFrog. There is already one reference implementation, and we anticipate there will be more by the end of the GGF's recommendation review timeline. Some additional front matter will be added to provide further background on SmartFrog, as well as the nature of existing reference implementations and the relationship to CDDLM (as an application area for SmartFrog).