[asterisk-app-dev] Standardization of Case for ARI URIs

[Daniel Jenkins]

On Wed, Jan 22, 2014 at 4:40 AM, Matthew Jordan <mjordan at digium.com> wrote:

> On Tue, Jan 21, 2014 at 5:25 PM, Paul Belanger
> <paul.belanger at polybeacon.com> 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 at digium.com> 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
> >
>
> My 2 cents:
>
> 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 at lists.digium.com
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20140122/91d2dcb8/attachment-0001.html>