[Koha-devel] Sip2 and Sip.pm

[Joe Atzberger]

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".

I don't see any reason for a client to send hex 0a or any other control
character in any message field.

In the spec, the transport layer is unspecified.  We have telnet and RAW.
The multiplicity of telnet implementations in the wild was a serious
impediment to development.  In fact, Koha does not even try to provide a
"real" telnet server inasmuch as you cannot send telnet control sequences
and expect any beneficial result.  In particular, you cannot send them
mid-session.  The handshake is minimal.  So in the end, we went with an
implementation that (1) was testable with the best available SIP tools,
namely the 3M emulator, and (2) supported additional telnet implementations,
like putty or those on linux.

Please feel free to identify the vendors with incompatible implementations.
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.
Other than that, I don't see any available perl interface that provides a
better telnet layer to swap in.

-- 
Joe Atzberger
LibLime - Open Source Library Solutions


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

> Hi,
>   there's an underlying assumption in Koha's Sip implementation that
> messages from sip units will be terminated by carriage return line feed.
> This works with many sip clients (including 3M). However the sip2
> standard mandates that sip messages are terminated by carriage return
> (hex 0d). That means any client that implements the standard as
> specified (and I know of at least 2 such vendors) can't connect to
> Koha's implementation (which sits waiting for the CR). It also means
> that those units that send hex 0a in the body of text can cause grief.
> I'm wondering if anyone has any thoughts on improving the server side.
>
> Cheers
> Colin
> --
> Colin Campbell
> Software Engineer, PTFS Europe Limited
> Content Management and Library Solutions
> +44 (0) 208 366 1295 (phone)
> +44 (0) 7759 633626  (mobile)
> colin.campbell at ptfs-europe.com
> skype: colin_campbell2
>
> http://www.ptfs-europe.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20090706/3c7c0b2e/attachment-0003.htm>