<div dir="ltr"><div class="gmail_default" style="color:rgb(102,0,0)">Okay, so the consensus I'm hearing is to change from case sensitive throughout to case sensitive only for identifiers and resources, and leave everything else insensitive and lower case (including technology).</div>
<div class="gmail_default" style="color:rgb(102,0,0)"><br></div><div class="gmail_default"><div class="gmail_default"><font color="#660000"><br></font></div><div class="gmail_default"><font color="#660000">PREFIX: case insensitive</font></div>
<div class="gmail_default"><font color="#660000"><br></font></div><div class="gmail_default"><font color="#660000">PATH: case insensitive</font></div><div class="gmail_default"><font color="#660000"><br></font></div><div class="gmail_default">
<font color="#660000">TECH: case insensitive, case determined by actual technology name, convention is all UPPERCASE, but either will match</font></div><div class="gmail_default"><font color="#660000"><br></font></div><div class="gmail_default">
<font color="#660000">RESOURCE: case sensitive, must match actual configured value.</font></div><div class="gmail_default"><font color="#660000"><br></font></div><div class="gmail_default"><font color="#660000">ID: case sensitive, must match actual identifier</font></div>
<div class="gmail_default"><font color="#660000"><br></font></div><div class="gmail_default"><font color="#660000">OPERATION: case insensitive</font></div><div style="color:rgb(102,0,0)"><br></div><div style="color:rgb(102,0,0)">
<br></div><div style="color:rgb(102,0,0)">Going forward (all future ARI URIs), the standard then is that all portions of a URI are case insensitive except where they are identifiers or resource names where the case matters.</div>
<div style="color:rgb(102,0,0)"><br></div><div style="color:rgb(102,0,0)"><br></div><div style="color:rgb(102,0,0)">Unless I receive any objections to this plan, I will go ahead and implement this later (in the coming days) when I get to the originating issue.</div>
<div style="color:rgb(102,0,0)"><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 21, 2014 at 11:51 AM, Leif Madsen <span dir="ltr"><<a href="mailto:lmadsen@thinkingphones.com" target="_blank">lmadsen@thinkingphones.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I agree with Paul here. Lets assume we're working with a standard web<br>
type interface and not have a preferred uppercase convention just<br>
because "that's how Asterisk has always done it".<br>
<br>
The preference should be for lowercase throughout, except for any<br>
channel or peer identifiers which need to be case sensitive due to<br>
naming conventions.<br>
<br>
Leif.<br>
<div class="HOEnZb"><div class="h5"><br>
-----Original Message-----<br>
From: Paul Belanger <<a href="mailto:paul.belanger@polybeacon.com">paul.belanger@polybeacon.com</a>><br>
Reply-to: Asterisk Application Development discussion<br>
<<a href="mailto:asterisk-app-dev@lists.digium.com">asterisk-app-dev@lists.digium.com</a>><br>
To: Asterisk Application Development discussion<br>
<<a href="mailto:asterisk-app-dev@lists.digium.com">asterisk-app-dev@lists.digium.com</a>><br>
Subject: Re: [asterisk-app-dev] Standardization of Case for ARI URIs<br>
Date: Mon, 20 Jan 2014 15:45:36 -0500<br>
<br>
Personally, I prefer everything to be lower case when possible.  So,<br>
things like TECH, if PJSIP, pjsip, PjSiP, are all valid inside<br>
asterisk, lets round down to pjsip.  However, if ENDPOINT is case<br>
sensitive in Asterisk, then expect the end user to enter it as such.<br>
<br>
So using your example above:<br>
<br>
<a href="http://127.0.0.1:8088/ari/endpoints/pjsip/200" target="_blank">127.0.0.1:8088/ari/endpoints/pjsip/200</a><br>
<br>
or<br>
<br>
<a href="http://127.0.0.1:8088/ari/endpoints/pjsip/FooBar" target="_blank">127.0.0.1:8088/ari/endpoints/pjsip/FooBar</a><br>
<br>
or<br>
<br>
<a href="http://127.0.0.1:8088/ari/endpoints/pjsip/foobar" target="_blank">127.0.0.1:8088/ari/endpoints/pjsip/foobar</a><br>
<br>
All return different endpoints.<br>
<br>
Additionally, have we even considered embedding the actually resource<br>
URL when we list an object in the return result? Then Asterisk can<br>
tell the user exactly how to get a specific item in the list.<br>
<br>
For example, we create a links: [] object, that would list the actual<br>
URI for said item.<br>
<br>
<br>
<br>
<br>
--<br>
</div></div><span class="HOEnZb"><font color="#888888">Leif Madsen<br>
Lead UC Systems Engineer<br>
c: +1-613-800-7610<br>
<a href="http://thinkingphones.com" target="_blank">http://thinkingphones.com</a><br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
asterisk-app-dev mailing list<br>
<a href="mailto:asterisk-app-dev@lists.digium.com">asterisk-app-dev@lists.digium.com</a><br>
<a href="http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev" target="_blank">http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><img alt="Digium logo" src="https://my.digium.com/images/graphics/digium_RGB_signature.gif" width="288" height="50" style="color:rgb(0,0,0);font-family:Arial,Helvetica,sans-serif;font-size:12px"><div>
Scott Griepentrog<br>Digium, Inc · Software Developer<br>445 Jan Davis Drive NW · Huntsville, AL 35806 · US<br>direct/fax: +1 256 428 6239 · mobile: +1 317 507 4029<br>Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> · <a href="http://asterisk.org" target="_blank">http://asterisk.org</a><br>
</div></div>
</div>