<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 22, 2014 at 11:03 AM, Walter Doekes <span dir="ltr"><<a href="mailto:wjdoekes+asterisk-dev@osso.nl" target="_blank">wjdoekes+asterisk-dev@osso.nl</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 22/01/14 11:37, Daniel Jenkins wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Oh go on then, I'll chip in a little more than just +1'ing Paul,<br>
<br>
URLs should be case sensitive, I think we've settled on that now<br>
</blockquote>
<br></div>
No. I think we've settled on sensitive and lowercase whenever (easily) possible. And case sensitive for the parts that matter.<br>
<br>
Just because the RFC says that URLs are case sensitive, does not mean that the RFC forbids aliases.<div class="im"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'd prefer for SIP technology and any technology to be lowercase in the<br>
url but if that's a crazy amount of work right now, then I'm fine with<br>
it being Upper, or whatever the technology is set to within Asterisk,<br>
</blockquote>
<br></div>
The point is, that if you make the decision to stick with UPPERTECH you'll have a hard time switching later.<br>
<br>
If we settle for these rules, we are forward compatible with an optional lowertech future:<br>
<br>
- case sensitive (usually lowercase) everywhere,<br>
- except technology names, which are case insensitive and have an uppercase canonical form (for now)<br>
<br>
If we then later decide to make lowertech the canonical form -- for starters by updating lots of json output everywhere -- newer scripts that use lowertech will still work on older ari versions.<span class="HOEnZb"><font color="#888888"><br>

<br>
<br>
Walter</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
asterisk-app-dev mailing list<br>
<a href="mailto:asterisk-app-dev@lists.digium.com" target="_blank">asterisk-app-dev@lists.digium.<u></u>com</a><br>
<a href="http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev" target="_blank">http://lists.digium.com/cgi-<u></u>bin/mailman/listinfo/asterisk-<u></u>app-dev</a></div></div></blockquote><div><br></div><div>
Hi Walter,</div><div><br></div><div>My point was that TECH should be whatever it is in Asterisk and should not be case insensitive, it just makes working with it more complex - everything should be case sensitive and lower where possible, in the case of an device id or whatever then it should be what's set in Asterisk - but for URL descriptors everything should be lower.</div>
<div><br></div><div>In the grand scheme of things, you should never build your application with knowledge you are guessing from your own knowledge - for example, the ARI should list it's available technologies and you should use that list to then construct URLs, or even better, for the result from the ARI when asking for all technologies, to give you a list of urls that you can call for each technology - let the API guide you to where it knows is correct.</div>
<div><br></div><div>There's too much guessing for my liking when people communicate with APIs, they take what they think they know and form their own logic around it - the ARI should tell you everything and your client should be dumb, entirely dumb when it comes to what it knows about Asterisk/ARI</div>
<div><br></div><div>When you treat your application as dumb and rely on the ARI telling you information like URLs to follow etc, the ARI could change things to upper or lower or whatever tomorrow and your application wouldn't care one bit.</div>
<div><br></div><div>You talk about how the RFC doesn't forbid aliases - but an alias is designed to make something easier, how would allowing SIP and sip make things easier if your application got the list of technologies from Asterisk itself?</div>
<div><br></div><div>Dan</div></div><br></div></div>