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

Tue Jan 21 14:47:27 CST 2014

Would you extend TECH being lower case to replacing all cases where PJSIP
is output in response to an ARI request (and thus could get copied into a
URL)?  For example, instead of:

  {
    "technology": "IAX2",
    "resource": "demo",
    "state": "unknown",
    "channel_ids": []
  },
  {
    "technology": "PJSIP",
    "resource": "200",
    "state": "offline",
    "channel_ids": []
  },

You would want:

  {
    "technology": "iax2",
    "resource": "demo",
    "state": "unknown",
    "channel_ids": []
  },
  {
    "technology": "pjsip",
    "resource": "200",
    "state": "offline",
    "channel_ids": []
  },

Or would it be sufficient to say that lowercase is preferred, but due to
case insensitivity it's not necessary to change all existing cases where it
is output?

On Tue, Jan 21, 2014 at 2:14 PM, Leif Madsen <lmadsen at thinkingphones.com>wrote:

> One change:
>
> TECH: case insensitive, case determined by actual technology name,
> convention is all lowercase but either will match
>
> -----Original Message-----
> From: Scott Griepentrog <sgriepentrog at digium.com>
> Reply-to: Asterisk Application Development discussion
> <asterisk-app-dev at lists.digium.com>
> To: Asterisk Application Development discussion
> <asterisk-app-dev at lists.digium.com>
> Subject: Re: [asterisk-app-dev] Standardization of Case for ARI URIs
> Date: Tue, 21 Jan 2014 13:08:15 -0600
>
> 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).
>
>
>
>
> PREFIX: case insensitive
>
>
> PATH: case insensitive
>
>
> TECH: case insensitive, case determined by actual technology name,
> convention is all UPPERCASE, but either will match
>
>
> RESOURCE: case sensitive, must match actual configured value.
>
>
> ID: case sensitive, must match actual identifier
>
>
> OPERATION: case insensitive
>
>
>
>
> 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.
>
>
>
>
> 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.
>
>
>
>
> On Tue, Jan 21, 2014 at 11:51 AM, Leif Madsen
> <lmadsen at thinkingphones.com> wrote:
>         I agree with Paul here. Lets assume we're working with a
>         standard web
>         type interface and not have a preferred uppercase convention
>         just
>         because "that's how Asterisk has always done it".
>
>         The preference should be for lowercase throughout, except for
>         any
>         channel or peer identifiers which need to be case sensitive due
>         to
>         naming conventions.
>
>         Leif.
>
>         -----Original Message-----
>         From: Paul Belanger <paul.belanger at polybeacon.com>
>         Reply-to: Asterisk Application Development discussion
>         <asterisk-app-dev at lists.digium.com>
>         To: Asterisk Application Development discussion
>         <asterisk-app-dev at lists.digium.com>
>         Subject: Re: [asterisk-app-dev] Standardization of Case for ARI
>         URIs
>         Date: Mon, 20 Jan 2014 15:45:36 -0500
>
>         Personally, I prefer everything to be lower case when possible.
>          So,
>         things like TECH, if PJSIP, pjsip, PjSiP, are all valid inside
>         asterisk, lets round down to pjsip.  However, if ENDPOINT is
>         case
>         sensitive in Asterisk, then expect the end user to enter it as
>         such.
>
>         So using your example above:
>
>         127.0.0.1:8088/ari/endpoints/pjsip/200
>
>         or
>
>         127.0.0.1:8088/ari/endpoints/pjsip/FooBar
>
>         or
>
>         127.0.0.1:8088/ari/endpoints/pjsip/foobar
>
>         All return different endpoints.
>
>         Additionally, have we even considered embedding the actually
>         resource
>         URL when we list an object in the return result? Then Asterisk
>         can
>         tell the user exactly how to get a specific item in the list.
>
>         For example, we create a links: [] object, that would list the
>         actual
>         URI for said item.
>
>
>
>
>         --
>
>         Leif Madsen
>         Lead UC Systems Engineer
>         c: +1-613-800-7610
>         http://thinkingphones.com
>
>
>         _______________________________________________
>         asterisk-app-dev mailing list
>         asterisk-app-dev at lists.digium.com
>         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 at lists.digium.com
> http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
>
> --
> Leif Madsen
> Lead UC Systems Engineer
> c: +1-613-800-7610
> http://thinkingphones.com
>
>
> _______________________________________________
> 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/20140121/26b2f74a/attachment-0001.html>