Re: Standardization of Case for ARI URIs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxx> wrote:
> On Wed, Jan 22, 2014 at 6:15 AM, Daniel Jenkins <dan.jenkins88@xxxxxxxxx>
> wrote:
> >
> >
> >
> > On Wed, Jan 22, 2014 at 11:03 AM, Walter Doekes
> > <wjdoekes+asterisk-dev@xxxxxxx> 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@xxxxxxxxxxxxxxxx
> >> 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@xxxxxxxxxxxxxx | IRC: pabelanger (Freenode)
> Github: https://github.com/pabelanger | Twitter:
> https://twitter.com/pabelanger
>
> _______________________________________________
> asterisk-app-dev mailing list
> asterisk-app-dev@xxxxxxxxxxxxxxxx
> http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev

_______________________________________________
asterisk-app-dev mailing list
asterisk-app-dev@xxxxxxxxxxxxxxxx
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev



--
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
_______________________________________________
asterisk-app-dev mailing list
asterisk-app-dev@xxxxxxxxxxxxxxxx
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev

[Index of Archives]     [Asterisk SS7]     [Asterisk Announcements]     [Asterisk Users]     [PJ SIP]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Linux API]

  Powered by Linux