<html>
 <body>
  <div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
   <table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
    <tr>
     <td>
      This is an automatically generated e-mail. To reply, visit:
      <a href="https://reviewboard.asterisk.org/r/2269/">https://reviewboard.asterisk.org/r/2269/</a>
     </td>
    </tr>
   </table>
   <br />





<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
 <p style="margin-top: 0;">On January 8th, 2013, 9:11 a.m., <b>elguero</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Based on a quick look, I like it! The documentation is very clearly written.

Just a few thoughts:

Tags - My first thought was that multiple tags should not be on separate lines, like in the example provided for sip peers in sip.conf.  Generally, one would think that the first tag would be overwritten by the second tag.  What about a comma delimited list and then we could call that setting &quot;tags&quot; instead of &quot;tag&quot; (tags=special_endpoints,endpoint_group_one).  I can just picture somebody putting tag towards the top of a peer definition and then another one later on and not figuring out that they have multiple tags and wondering why they are getting messages that they shouldn&#39;t be getting.  Just throwing that out there.

Keys - Keys are case insensitive.  Why not case sensitive?

Port and bindaddr - Why don&#39;t we combine these to one setting, bindaddr?  We are doing that for tlsbindaddr and I believe other parts of Asterisk do this now too.</pre>
 </blockquote>




 <p>On January 8th, 2013, 12:45 p.m., <b>Sean Bright</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">&gt; Keys - Keys are case insensitive.  Why not case sensitive?

I tend to agree.  I would always err on the side of being too strict, rather than accommodating, especially when we aren&#39;t dealing with direct user input (a person typing at a keyboard).</pre>
 </blockquote>








</blockquote>

<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Tags: I&#39;m good with tag_a,tag_b as the mechanism to specify multiple tags.

Port and bindaddr: Sure.

Case sensitivity: this is a tough one. In general, I favor case sensitivity as well (particularly in the domain of programming languages, when an interpreter or compiler exists to aid you). However, in this case I&#39;d make a motion for case insensitivity on a few grounds:
1) Many AMI libraries already assume case insensitivity (StarPy) comes to mind. While library compatibility is not sufficient reason for a decision in this case (after all, the purpose of a specification is to hopefully get the basic rules *right*), it is something to keep in mind.
2) When dealing with an interface protocol, it&#39;s often best to be as forgiving as possible. Third party systems often get things wrong - witness, for example, ASTERISK-20897.
3) Keys that are case insensitively identical are highly unlikely to have different semantics. An action that includes both &#39;Channel&#39; and &#39;channel&#39; - with different meanings - is unlikely to ever be accepted. If it is not acceptable to have actions/events with case insensitive fields, why require case sensitivity?</pre>
<br />








<p>- Matt</p>


<br />
<p>On January 8th, 2013, 8:41 a.m., Matt Jordan wrote:</p>






<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('https://reviewboard.asterisk.org/media/rb/images/review_request_box_top_bg.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
 <tr>
  <td>

<div>Review request for Asterisk Developers.</div>
<div>By Matt Jordan.</div>


<p style="color: grey;"><i>Updated Jan. 8, 2013, 8:41 a.m.</i></p>




<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
 <tr>
  <td>
   <pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">A proposed revamp of the AMI protocol has been written and is available for discussion:

https://wiki.asterisk.org/wiki/display/AST/AMI+1.4+Specification

Please note that this will change the AMI protocol significantly, and represents a major shift in how the protocol represents operations in Asterisk to consumers of the protocol.</pre>
  </td>
 </tr>
</table>





<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">

</ul>

<p><a href="https://reviewboard.asterisk.org/r/2269/diff/" style="margin-left: 3em;">View Diff</a></p>




  </td>
 </tr>
</table>








  </div>
 </body>
</html>