On Wed, Jan 22, 2014 at 4:40 AM, Matthew Jordan <mjordan@xxxxxxxxxx> wrote:
On Tue, Jan 21, 2014 at 5:25 PM, Paul BelangerMy 2 cents:
<paul.belanger@xxxxxxxxxxxxxx> wrote:
> Correct me if I am wrong, but when we output the TECH, we just convert
> to to lower case for ARI URIs?On Tue, Jan 21, 2014 at 5:57 PM, Scott
> Griepentrog <sgriepentrog@xxxxxxxxxx> wrote:
>>
>> I was assuming that we would leave TECH to be case INsensitive, and thus it wouldn't matter. We can also then optionally go through and change all json output to lowercase.
>>
> A quick google[1] shows URLs SHOULD be case sensitive, according to
> the RFC. So, we should enforce that from the URL POV.
>
>> If you want to treat TECH as a case sensitive value, then ALL instances of IAX and PJSIP and LOCAL etc would have to be changed everywhere in the code (for any json output anyway) so that you don't have code broken by a lowercase TECH requirement. This would also break some EXISTING ari apps, likely also tests.
>>
>> What about a transitional period (such as Asterisk 12) where TECH is case insensitive and the json output of TECH is lowercased, then later (in trunk & Asterisk 13) the case sensitivity on TECH can be changed?
>>
> I don't think we actually need to change anything in asterisk to make
> TECH case sensitive. Unless you see value in having SIP/foo and
> sip/foo as different endpoints.
>
> [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.3
>
Let's not over-think or complicate this. "SIP" versus "sip" doesn't
feel like it justifies a backwards incompatible change. I care less
about what gets picked then having a ripple effect that spreads
through ARI and Asterisk for very little pay off.
That aside, URLs should be case sensitive (RFCs FTW). That doesn't
mean we can't be accommodating in what we accept. There will never,
ever, ever be a 'sip' and a 'SIP' technology in Asterisk. If someone
provides SIP or sip for a channel technology, we know they are the
same thing; treating them as the same is not bad when there is no
semantic reason not to.
Identifiers of things, however, are case sensitive. We don't know that
there won't be endpoints named Endpoint, endpoint, endpoinT, and
EnDpoInT. If you configure your system with strange names, we should
defer to the system administrator's (admittedly questionable)
judgement.
--
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
_______________________________________________
asterisk-app-dev mailing list
asterisk-app-dev@xxxxxxxxxxxxxxxx
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
Oh go on then, I'll chip in a little more than just +1'ing Paul,
URLs should be case sensitive, I think we've settled on that now
I'd prefer for SIP technology and any technology to be lowercase in the url but if that's a crazy amount of work right now, then I'm fine with it being Upper, or whatever the technology is set to within Asterisk, If i made a FooBar technology tomorrow and it got put into Asterisk as FooBar then I should address it as such in the URL - There should be no form of we accept sip or SIP - yes it means URLs look ugly but it's an API, no-one sees it behind the application you're building. Let's not lose sight of the fact that this is the first iteration into the api design and things may be simpler later on, I'd love a HATEOAS style API but I'm not going to get that any time soon ;)
Dan
_______________________________________________ asterisk-app-dev mailing list asterisk-app-dev@xxxxxxxxxxxxxxxx http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
