[Koha-devel] Sip2 and Sip.pm

[Joe Atzberger]

On Mon, Jul 6, 2009 at 11:01 AM, Colin Campbell <
colin.campbell at ptfs-europe.com> wrote:

> On 07/06/2009 03:00 PM, Joe Atzberger wrote:
>
>> Colin --
>>
>> Koha SIP can handle dossy ^M line endings just fine.  The detection of
>> line endings is essentially delegated to the IO::Socket::INET and Socket
>> modules with local $/ = "\012".
>>
> The problem is that the protocol states that all messages end in a carrage
> return (hex 0d). There is no requirement to set linefeed as a terminator as
> it is not a message separator.
>

The stuff I mentioned are the particulars of the implementation.  You are
welcome to experiment with other components, but I think you would find
unilaterally setting to \010 wil break far more than it will help.

I agree with you on what the spec says, but at the time of implementation,
ZERO clients available to Koha developers actually behaved that way,
including the reference implementation from 3M.  At this time, the number of
such clients available to us is still zero.  We would need more information
about the clients in question:

   - What are they?
   - How widespread is their use?
   - Are they the *current* version of their implementation or orphaned
   legacy code?
   - Does the developer still support the implementation?
   - Are they open source? (you've suggested they are not)

 > I don't see any reason for a client to send hex 0a or any other control
> character in any message field.
>
It's allowed so they will. I've seen it on a number of occasions.


It would also be "allowed" to renegotiate the telnet handshake midstream.
Nobody does this.

I'll restate my contention.  The SC has a defined number of commands and
those have a defined number of required and optional fields.  None of the
data to be communicated in those fields should legitimately contain hex 0a
or other control characters.   For example, if your branchcode contains a
linefeed, Koha will break in many other places, including before you are
able to get a full transaction response from SIP.

When do you imagine it would be appropriate for a SIP client to send, for
example, a BELL character or BACKSPACE character?

It may be possible to make the line-ending an
>> attribute of the SIPconfig account, such that you could have a different
>> one for a given SIP terminal.  Or more likely, you can get the clients
>> to send a different line ending.
>>
>>  This would be the way to go for flexibility. At the moment the assumption
> is interwoven with the protocol handling. I don't think expecting the
> clients to send different line endings is likely as these are usually closed
> (often windows) binaries.


You could still run a middle layer on localhost.  But if it can be handled
cleanly via SIPconfig, I would support that.


> Its a lot easier to handle the vagaries of the clients in the perl code.


Maybe.  I'm sure it isn't easier to develop a whole new SIP emulator to
support testing on the new config though.

--Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20090706/fc7ab19f/attachment-0003.htm>