Summary:	ASTERISK-07723: RFC-compliant enumlookup macro is borked.
Reporter:	Jonathan S. Shapiro (shap)	Labels:
Date Opened:	2006-09-12 00:01:46	Date Closed:	2011-06-07 14:07:22
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/Configuration
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	The enumlookup macro given at http://www.voip-info.org/wiki/view/Asterisk+func+enumlookup is wrong. It uses '-' as a separator character. The problem with this, of course, is that '-' is a perfectly valid domain name character. Apparently '-' got adopted because it is the default for CUT. My suggestion is to replace '-' with space (' '), which is at least not legal in domain names. But in the process of deprecating the old built-in function, did anybody stop to think how much harder this is to configure? I don't have any problem with the idea of the macro, but something comparable in functionality to enum.conf is desirable. In case it provokes any interesting thoughts, I'm wondering if the "global variables" mechanism in extensions.conf cannot be used here with a slight augmentation: allow '+=' as in make, and then augment the macro to accept a space-separated list of domains to be searched as an argument.
Comments:	By: Serge Vecher (serge-v) 2006-09-13 10:08:41 murf: this bug calls for your attention ;) By: Steve Murphy (murf) 2006-09-15 11:31:07 I went to the wiki; I see comments at the top to correct the macro behavior in question. I noted that the AEL version didn't look very nice, as its spacing is lost on display, so I replaced all the tabs with spaces to make the indentation appear as it should, which makes it more readable. I'm not exactly clear on what further to do; shap could just as well update the macros in the wiki as I could, rather than adding comments to the wiki. Is this a complaint against the inner workings of ENUMLOOKUP? If you supply a patch for ENUMLOOKUP, that works, we may be persuaded to include it in 1.6...! But if you considerably change the workings of ENUMLOOKUP, even if it is for the better, everyone that's using it now in their dialplans will either praise or curse you, for breaking their dialplans when they upgrade. So, mayhaps a new function with the added intelligence? By: Jonathan S. Shapiro (shap) 2006-09-15 11:49:53 Actually, those comments weren't by me. There is actually a bigger problem. The CUT macro uses '-' as a default separator, and this has led to an unfortunate de facto default that '-' is used as a separator in many configurations -- most notably it is almost universal in all of the examples that i have seen anywhere. The '-' isn't a good separator because it is legal in both URLs and email addresses. What we really need to do here is pick a separator that *doesn't* conflict, recommend that for future use, and deprecate the default separator in CUT because it was a bad choice. For the moment, issue warnings, and obsolete the bad default it in 1.6 or 1.8. The problem is what to choose as the recommended practice. Here are a bunch of bad options:  '-', '_' -- both legal in domain names or email names  ','      -- already used as argument separator for functions  '|'      -- used as separator in extension plans  ' '      -- probably the best choice, but has significance in              some fields. I tend to favor ' ', because it is familiar from MAKE and we could easily augment the variables mechanism to use it effectively. However, I note that there are other contexts where ' ' should not be significant. Notably in Dial arguments, where the following *should* work interchangeably but do not:  Dial(ext1&ext2,,)   -- works  Dial(ext1 & ext2,,) -- more readable, but broken I shall try to gather my thoughts on this and send them to asterisk-dev. I'm concerned, however, that sending this mail so near a release will cause it to be negatively received, since (from other interactions) the developers are obviously feeling under pressure right now. murf, serge-v: I assume that it's too late to have CUT issue a warning in 1.4 when the unspecified default separator is used? If it's too late, I don't even want to mention it. Would appreciate guidance. By: jmls (jmls) 2006-11-01 12:43:12.000-0600 where should we take this one for further discussion ? By: Steve Murphy (murf) 2006-11-01 13:10:37.000-0600 Conferred with a few other developers; It would be bad form to change the default and possibly have hundreds of dialplans go haywire when they upgrade to the next release. It's just as simple to just specify the separator you desire in your own code. When three out of three developers vote "no" to such a proposal, you have to think that it won't fly in the general community. So, with your permission, can I close this? By: Steve Murphy (murf) 2006-11-02 07:44:03.000-0600 I didn't mention that someone did propose that the default could be changed via setting a variable. That variable could be consulted by the app, and if set, would serve as the default for CUT. This isn't an entirely bad idea, as it does not affect current users. I don't know if any other apps use this strategy; or if the community would be OK with it, but it seems a bit more likely to me. jmls-- I'd have to look thru my logs, wasn't it you that made this proposal? Anyone game to write up a patch, and see if this flies? By: Jonathan S. Shapiro (shap) 2006-11-02 08:30:48.000-0600 I didn't mean to suggest changing the default argument value. I meant to suggest eliminating any defaulting of the cut criteria. The right way to go about this is to do one release where warnings are issued about the default, and provide a tool (a script) that will automatically insert the hyphens into current scripts where they are missing. In the next release, the absence of an explicitly specified cut criteria becomes an error. The reason to eliminate the default is (a) it will encourage people to actually check those scripts when they learn why the default is being eliminated, and (b) the current default misleads authors into writing incorrect scripts (as occured in the ENUM lookup script and various others). Defaults are only a good idea when there is a really obvious choice that has almost no chance of being the wrong thing in practice. Offhand, I can't think of anything that would meet that criteria where CUT is concerned. By: Steve Murphy (murf) 2006-11-17 17:57:42.000-0600 I just sent out a message to the asterisk-dev mailing list as a poll on what people would prefer here. Let's either deep-6 this, or put it into effect, one of the two. It's been sitting around too long. By: Steve Murphy (murf) 2006-11-24 20:43:19.000-0600 Sorry shap, community response was not in your favor, or so it appears. Corydon said this:        CUT was originally written to remove the CHANNEL unique identifier        appended to the end, which is why the '-' is the default character.                I think the reason for removing the default is lacking.  If I was        writing it today, knowing all that I've used CUT for, I would have set        the default to '|', as that character is unavailable with the current        syntax (but will be available for syntax in 1.4), but I see absolutely        no reason to change it now.  Getting the wrong result should be just as        much of a reason to check your syntax as getting an error message, so        that's not a good reason for changing it. And so it boils down to cost/benefit sort of argument, where forcing users to provide a separator will do them no better good than using the default, if they provide the wrong one. Is it OK to close this bug? It wasn't a bad idea, but it doesn't look like it'll fly, either. By: Steve Murphy (murf) 2006-12-07 12:10:25.000-0600 Sorry, I'll close this for the time being. If you have any more input, feel free to re-open this bug!