Re: Standardization of Case for ARI URIs

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

 



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@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxx>
Reply-to: Asterisk Application Development discussion
<asterisk-app-dev@xxxxxxxxxxxxxxxx>
To: Asterisk Application Development discussion
<asterisk-app-dev@xxxxxxxxxxxxxxxx>
Subject: Re: 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@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx>
        Reply-to: Asterisk Application Development discussion
        <asterisk-app-dev@xxxxxxxxxxxxxxxx>
        To: Asterisk Application Development discussion
        <asterisk-app-dev@xxxxxxxxxxxxxxxx>
        Subject: Re: 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@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

--
Leif Madsen
Lead UC Systems Engineer
c: +1-613-800-7610
http://thinkingphones.com


_______________________________________________
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