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

Thu Jan 23 10:41:34 CST 2014

Distilling all comments down, I now have this plan which will be
implemented unless there is significant disagreement:

PREFIX: case sensitive, lower case required

PATH: case sensitive, lower case required

TECH: case INsensitive (accept SIP & sip), current CAPS will be allowed to
continue but recommendation is to lower case all TECH names

RESOURCE: case sensitive, must match actual configured value.

ID: case sensitive, must match actual identifier

OPERATION: case sensitive, lower case required

On Thu, Jan 23, 2014 at 3:56 AM, Ben Merrills
<b.merrills at mersontech.co.uk>wrote:

> > On Wed, Jan 22, 2014 at 6:15 AM, Daniel Jenkins <dan.jenkins88 at gmail.com
> >
> > wrote:
> > >
> > >
> > >
> > > On Wed, Jan 22, 2014 at 11:03 AM, Walter Doekes
> > > <wjdoekes+asterisk-dev at osso.nl> wrote:
> > >>
> > >> On 22/01/14 11:37, Daniel Jenkins wrote:
> > >>>
> > >>> 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
> > >>
> > >>
> > >> No. I think we've settled on sensitive and lowercase whenever
> > >> (easily) possible. And case sensitive for the parts that matter.
> > >>
> > >> Just because the RFC says that URLs are case sensitive, does not mean
> > >> that the RFC forbids aliases.
> > >>
> > >>
> > >>
> > >>> 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,
> > >>
> > >>
> > >> The point is, that if you make the decision to stick with UPPERTECH
> > >> you'll have a hard time switching later.
> > >>
> > >> If we settle for these rules, we are forward compatible with an
> > >> optional lowertech future:
> > >>
> > >> - case sensitive (usually lowercase) everywhere,
> > >> - except technology names, which are case insensitive and have an
> > >> uppercase canonical form (for now)
> > >>
> > >> 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.
> > >>
> > >>
> > >> Walter
> > >>
> > >>
> > >> _______________________________________________
> > >> asterisk-app-dev mailing list
> > >> asterisk-app-dev at lists.digium.com
> > >> http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
> > >
> > >
> > > Hi Walter,
> > >
> > > 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.
> > >
> > > 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.
> > >
> > > 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
> > >
> > > 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.
> > >
> > > 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?
> > >
> > > Dan
> > >
> > My turn to +1 Dan.  Lets be honest, if this was behind an HTTP server
> (via
> > Asterisk serving up the content) we wouldn't even be having this
> discussion.
> > I think we are pretty much there, lower case URLS, only when model, tech,
> > item, foo, is actually case sensitive, I think everybody is on board
> with that.
> >
> [skrusty]
> Sounds about right to me! Lower case as a general rule is pretty much (I
> think) the norm, and the way to proceed. Otherwise it's just going to get
> messy.
>
> +1 Dan and Paul ;)
>
>
> > --
> > Paul Belanger | PolyBeacon, Inc.
> > Jabber: paul.belanger at polybeacon.com | IRC: pabelanger (Freenode)
> > Github: https://github.com/pabelanger | Twitter:
> > https://twitter.com/pabelanger
> >
> > _______________________________________________
> > asterisk-app-dev mailing list
> > asterisk-app-dev at lists.digium.com
> > http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
>
> _______________________________________________
> asterisk-app-dev mailing list
> asterisk-app-dev at lists.digium.com
> http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
>

-- 
[image: Digium logo]
Scott Griepentrog
Digium, Inc · Software Developer
445 Jan Davis Drive NW · Huntsville, AL 35806 · US
direct/fax: +1 256 428 6239 · mobile: +1 317 507 4029
Check us out at: http://digium.com · http://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20140123/bd60002b/attachment.html>