<< The one reason that may still exist for not making DTML Methods traversable as you're suggesting would be if you want to call a DTML Method within the acquisition context of another... something that some people may want to do (I never have though). If a DTML Method chops off everything that follows in the URL, then that remaining part of the URL can't be used for acquiring other methods. << I don't see DTML Methods as "chopping off" the URL so much as "consuming" parts of it. SQL Methods have this behaviour now : www.mysite.com/flavor/cherry/showme Where "flavor" is a SQL Method which takes a single parameter "cherry" and "showme" is a DTML Document which makes some use of the flavor SQL Method. In this instance "flavor" consumes the next part of the url because it is looking for a parameter and when it is finished hands on control to the next, unconsumed part of the URL "showme". Notice though that I have to have the "showme" DTML Method to actually display the results. If "flavor" was a parmeterized DTML Method my URL could become : www.mysite.com/flavor/cherry which makes more sense to me. In this case the "flavor" DTML Method would consume the "cherry" parameter, perhaps call some SQL Method to get the data for the "cherry" display and then display itself. If the parameters could have defaults then I could have URL's like : www.mysite.com/members/ian/ www.mysite.com/members/ian/home www.mysite.com/members/ian/preferences www.mysite.com/members/ian/todo Where "members" is a DTML method which takes parameters <username>,<subsite> (default : "home") and decides what to display based on the parameters passed. This allows my "users" to become virtual (by which I mean DB-based). I can do the last 3 URL's now with SQL Methods ("home", "preferences" and "todo" become DTML documents or methods which are aquired) but I can't do the first URL because SQLMethods don't do any rendering for display. Well, that got rambling but it lays my argument out in full I think. - Ian.