On 07/06/2009 05:00 PM, Joe Atzberger wrote:
> 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 t
On Mon, Jul 6, 2009 at 11:01 AM, Colin Campbell <
colin.campb...@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 So
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 e
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
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). Th
