W dniu 08.07.2016, pią o godzinie 17∶28 +0530, użytkownik vaibhav singh
napisał:
> XMPP XEP's. In Band registration was something that caught my eye, as
> the XEP itself said that it is utterly insecure and recommended
> people not to use it.
I don't see that wording in XEP. You are probably
W dniu 11.03.2016, pią o godzinie 15∶33 +0100, użytkownik Peter Waher
napisał:
> What is the preferred way of sending an image in chat today?
XEP-0137 Describes publishing SI-FT advertisement using [1].
In such case I display a button in the chat window, allowing user to
download the file,
W dniu 29.02.2016, pon o godzinie 18∶30 +0100, użytkownik Fabian Beutel
napisał:
> When joining a room, the user could include some kind of flag in the
> initial presence stanza that prevents the server from sending all the
> other presences and goes straight to sending back the new occupants
>
Dnia 2015-11-10, wto o godzinie 17:10 -0600, Sam Whited pisze:
> > What do you suggest to replace it with?
>
> I suggest we replace it with nothing.
Closing the network is not the answer.
People need a way of joining the network.
If we deprecate the existing widely deployed standards, people
Dnia 2015-11-04, śro o godzinie 09:44 +, Kevin Smith pisze:
> is it time to deprecate (and obsolete) 77 and send a clear
> message that this should not be being used on open networks?
What do you suggest to replace it with?
--
/o__ "Yes, it's the right planet, all right, " he said again.
Dnia 2015-11-05, czw o godzinie 12:45 -0500, Travis Burtrum pisze:
> Rendered version can be found at
> https://burtrum.org/xeps/tls-srv.html
Isn't smart proxy like sslh[1] better suited for the use case?
[1] http://www.rutschle.net/tech/sslh.shtml
--
/o__
(_<^' Love sometimes expresses
presence. Also the specification has issues already
mentioned in this thread.
5. Is the specification accurate and clearly written?
Yes.
--
Tomasz Sterna @ http://abadcafe.pl/ @ http://xiaoka.com/
IBB.
--
Tomasz Sterna @ http://abadcafe.pl/ @ http://www.xiaoka.com/
for misinterpretation and mistakes like ie.
frying/freezing your plants.
When you specify the unit, at least you give a chance to err-out on
unhandled unit if the control is unable to convert.
--
Tomasz Sterna @ http://abadcafe.pl/ @ http://www.xiaoka.com/
Dnia 2013-07-16, wto o godzinie 14:24 -0700, Justin Karneges pisze:
I'm assuming that you're doing direct client to client connections
for this (eg, link local, etc)? Otherwise the server should ensure
that the presence is kept up to date.
You're correct in that a typical client should not
file transfer protocols; i.e. establishing
direct client-to-client connections, negotiating/detecting server
enforced policies regarding used bandwidth and stanza size, etc.
--
Tomasz Sterna:(){ :|:};:
Instant Messaging ConsultantOpen Source Developer
http
communicate only the fact that the resource is available (not
detailed information such as the show/, status/, priority/, or
presence extensions).
May I ask what is the rationale behind this?
Why the server should not answer with the presence stanza of the probed
resource?
--
Tomasz Sterna
Instant
to resource constraints)
to use TLS encryption?
What about S2S links? These are mostly not SASL authenticated.
--
Tomasz Sterna
Instant Messaging Consultant : Open Source Developer
http://tomasz.sterna.tv/ http://www.xiaoka.com/
Dnia 2010-04-27, wto o godzinie 15:56 +0100, Artur Hefczyc pisze:
My understanding of this is that: the server supports both
jabber:client and
jabber:server namespaces.
'OR' returns false if both sides of the OR are false. Therefore, if
the server
receives jabber:client packet over s2s
Dnia 2010-03-20, sob o godzinie 12:48 +0200, Väisänen Teemu pisze:
The server knows client's IP address, so what if the server would also
check country, operator, etc. and send some (location) related
information back to the client, if the client requested these types of
information, not just
Dnia 2010-03-12, pią o godzinie 11:52 +0100, Laurent Eschenauer pisze:
In onesocialweb, our use cases imply that all connected resources
should receive a message when sent to the bare JID.
You should use presence/ packet instead of message/.
Presence packets are routed to all available
Dnia 2010-03-05, pią o godzinie 12:53 -0600, XMPP Extensions Editor
pisze:
Version 0.1 of XEP-0279 (Server IP Check) has been released.
URL: http://xmpp.org/extensions/xep-0279.html
Yet Another Way?
jabberd2 supports http://delta.affinix.com/specs/xmppstream.html#myip
for some time now.
Dnia 2010-03-05, pią o godzinie 12:53 -0600, XMPP Extensions Editor
pisze:
XEP-0279 (Server IP Check) has been released.
This protocol is hard to implement in servers with strong separation of
client connection handling and client session handling (jabberd14,
jabberd2, Tigase AFAIK).
In these
Dnia 2010-03-08, pon o godzinie 14:56 +0100, Remko Tronçon pisze:
The clean separation of RFC 3920 and RFC 3921 allows this.
XEP-0279 breaks this and causes tight coupling of these layers.
On the other hand, if your server implementation has a hard time
figuring it out, don't support it.
Dnia 2010-03-08, pon o godzinie 16:18 +, Matthew Wild pisze:
How would you propose to do it without tight coupling?
http://delta.affinix.com/specs/xmppstream.html#myip
Some may say it is spamming all clients with a feature that may or may
not be useful.
But it is a case of offering every
Dnia 2010-03-05, pią o godzinie 07:01 -0600, XMPP Extensions Editor
pisze:
XEP-0232 (Software Information) has been Deferred because of
inactivity.
What stops it from moving to Proposed?
want this feature, and will use XEP-0092 instead forever
For the record:
jabberd2 implements it and it works alongside XEP-0092.
--
Tomasz Sterna
Instant Messaging EDI Consultant
Open Source Developer
http://tomasz.sterna.tv/ http://www.xiaoka.com/
it would be
useful to base it on some of the message characteristics?
--
Tomasz Sterna
Xiaoka.com
(for
XHTML-IM), and a new application/xmpp-msg+xml type to contain the
original message stanza in full. It's much, much simpler than trying
Good idea. I like it very much. :-)
--
Tomasz Sterna
Xiaoka.com
Dnia 2010-01-05, wto o godzinie 14:14 +0100, Tomasz Sterna pisze:
3. thread/ converts directly to References:
I'm not sure thread *does* convert, given that thread is a single
string for all messages within a thread, whereas References is a
list
of message ids.
Right. I
during the verification code entry with a first_auth not callable
error.
Should I just forget the XMPP Federation thingy and proceed with
self-signed certificate?
--
Tomasz Sterna
Instant Messaging EDI Consultant
Open Source Developer
http://tomasz.sterna.tv/ http://www.xiaoka.com/
, nor with the XEP text.
It works fine parallely to jabber:iq:time support.
--
Tomasz Sterna
Instant Messaging EDI Consultant
Open Source Developer
http://tomasz.sterna.tv/ http://www.xiaoka.com/
, nor with the XEP text.
It works fine parallely to XEP-0091 support.
--
Tomasz Sterna
Instant Messaging EDI Consultant
Open Source Developer
http://tomasz.sterna.tv/ http://www.xiaoka.com/
Should we still stick to GPS only? Or be GPS-independant?
Should we add some fields to reflet the different other technologies?
Will new ones appear in the future? (highly probable?)
Does it matter where you get your geographical coordinates from?
--
Tomasz Sterna
Instant Messaging EDI
favor the roster
items eXtensions?
--
Tomasz Sterna
Instant Messaging EDI Consultant
Open Source Developer
http://tomasz.sterna.tv/ http://www.xiaoka.com/
it is processing XMPP packets.
--
Tomasz Sterna
Instant Messaging EDI Consultant
Open Source Developer
http://tomasz.sterna.tv/ http://www.xiaoka.com/
?
--
Tomasz Sterna
Instant Messaging EDI Consultant
Open Source Developer
http://tomasz.sterna.tv/ http://www.xiaoka.com/
the worse.
--
Tomasz Sterna
Instant Messaging EDI Consultant
Open Source Developer
http://tomasz.sterna.tv/ http://www.xiaoka.com/
version) or ...
Peter,
I don't want to be picky, but this raises a question:
- Where should I put the 'ver' attribute?
This is a technical document after all, so it should be strict and leave
no place for doubt. Even at the cost of over explaining.
--
Tomasz Sterna
Instant Messaging EDI
send to the client current roster version when sending complete
roster?
I guess I should add ver attribute to the iq-result query item, but that
is only a guess.
--
Tomasz Sterna
Instant Messaging EDI Consultant
Open Source Developer
http://tomasz.sterna.tv/ http://www.xiaoka.com/
in jabberd2 SVN repository. :-)
Seems the example on full result has been left out.
Maybe it needs a sentence or two about that.
I think so.
--
Tomasz Sterna
Instant Messaging EDI Consultant
Open Source Developer
http://tomasz.sterna.tv/ http://www.xiaoka.com/
This is a crude hack and I'm against encouraging it.
If we really want to have IRC actions on MUC let's do it properly, i.e.
actionshrugs/action child of message.
--
/\_./o__ Tomasz Sterna
(/^/(_^^' http://www.xiaoka.com/
._.(_.)_ im:[EMAIL PROTECTED]
MUST be handled by bare JID of this roster
item.
--
/\_./o__ Tomasz Sterna
(/^/(_^^' http://www.xiaoka.com/
._.(_.)_ im:[EMAIL PROTECTED]
Dnia 2008-04-29, wto o godzinie 20:51 +, Gaston Dombiak pisze:
In our case, the server was not keeping any information about the
session [...]
Even the parser state?
This is AFAIR the only thing I need to reset in jabberd.
--
/\_./o__ Tomasz Sterna
(/^/(_^^' http://www.xiaoka.com
, not a Swiss
Army Knife to put anything in, just because we can.
--
/\_./o__ Tomasz Sterna
(/^/(_^^' http://www.xiaoka.com/
._.(_.)_ im:[EMAIL PROTECTED]
Dnia 2008-04-28, pon o godzinie 12:42 +0200, Tomasz Sterna pisze:
I was thinking more along the lines of roster and privacy-list pushes after
item update.
So, I implemented it today, in jabberd 2 trunk, similarly to XEP-0016
and XEP-0191 notification/update pushes:
http://jabberd2.xiaoka.com
-contacts XEP is a good example of over-engineering things that
have good-enough real life solutions already.
--
/\_./o__ Tomasz Sterna
(/^/(_^^' http://www.xiaoka.com/
._.(_.)_ im:[EMAIL PROTECTED]
- Got a certificate list of 2 certificates.
[...]
- Peer's certificate issuer is unknown
- Peer's certificate is NOT trusted
- Version: TLS 1.0
- Key Exchange: RSA
- Cipher: AES 256 CBC
- MAC: SHA
- Compression: DEFLATE
- Handshake was completed
[...]
--
/\_./o__ Tomasz Sterna
(/^/(_^^' http
. folding aąAĄ to a etc.
Eventually we could use slugify ;-)
--
/\_./o__ Tomasz Sterna
(/^/(_^^' http://www.xiaoka.com/
._.(_.)_ im:[EMAIL PROTECTED]
.
This is a client interface implementation issue.
--
/\_./o__ Tomasz Sterna
(/^/(_^^' http://www.xiaoka.com/
._.(_.)_ im:[EMAIL PROTECTED]
-JIG archives on the topic?
This could answer many of your concerns.
--
/\_./o__ Tomasz Sterna
(/^/(_^^' http://www.xiaoka.com/
._.(_.)_ im:[EMAIL PROTECTED]
by detecting compressed stream instead of listening on special wrapper
port.
AFAIK in RFC 3920 there aren't restrictions in this sense.
And it's good. Transport layer should be transparent.
--
/\_./o__ Tomasz Sterna
(/^/(_^^' http://www.xiaoka.com/
._.(_.)_ im:[EMAIL PROTECTED]
Dnia 2008-02-12, Wt o godzinie 08:49 -0700, Peter Saint-Andre pisze:
[EMAIL PROTECTED]/resourcepart
These are just parts of an address, after all, and have no real
meaning
on their own.
Well... domain on its own is a valid JID.
--
/\_./o__ Tomasz Sterna
(/^/(_^^' http
of [EMAIL PROTECTED] Oh, btw, I do want to keep the
chat history so this strange thingy JRU is no good...
And with different gateways we loose the fallback to try Gateway2 when
selected Gateway1 resource is not available (default highest priority
resource message routing fallback).
--
/\_./o__ Tomasz
clicking the contact) when I know that I will always be
wanting to communicate only with the given one?
--
/\_./o__ Tomasz Sterna
(/^/(_^^' http://www.xiaoka.com/
._.(_.)_ im:[EMAIL PROTECTED]
Dnia 2008-02-01, Pt o godzinie 00:17 +0100, Tomasz Sterna pisze:
I found e serious issue with FC 3921bis Managing Presence Subscriptions.
[...]
Shall I take no answers to my post as:
- nobody is really interested in the issue ?
- I already am on all list members KILLFILEs ?
I think we need
Dnia 2008-02-03, N o godzinie 10:43 +0100, Tomasz Sterna pisze:
So I actually need full JID based subscriptions.
I did some thinking and come to conclusion that it would be hard to
allow full JID based presence subscriptions.
Especially 3.1.5. Server Processing of Outbound Subscription Approval
...
--
/\_./o__ Tomasz Sterna
(/^/(_^^' http://www.xiaoka.com/
._.(_.)_ im:[EMAIL PROTECTED]
to have the same information in only one place!)
-1
I think, the service identity name is the name of the service, not the
software powering the service.
ex:
identity name='Xiaoka.com XMPP server' type='im' category='server'/
--
/\_./o__ Tomasz Sterna
(/^/(_^^' http://www.xiaoka.com
it in jabberd 2.
You may check current SVN trunk, or see it live on chrome.pl server.
--
/\_./o__ Tomasz Sterna
(/^/(_^^' http://www.xiaoka.com/
._.(_.)_ im:[EMAIL PROTECTED]
it? ;-)
--
/\_./o__ Tomasz Sterna
(/^/(_^^' http://www.xiaoka.com/
._.(_.)_ im:[EMAIL PROTECTED]
in the XEP-0115 noise a month ago or
so.
--
/\_./o__ Tomasz Sterna
(/^/(_^^' http://www.xiaoka.com/
._.(_.)_ im:[EMAIL PROTECTED]
the long xmlns='http://jabber.org/protocol/caps' string?
--
/\_./o__ Tomasz Sterna
(/^/(_^^' http://www.xiaoka.com/
._.(_.)_ im:[EMAIL PROTECTED]
reply in one packet too.
--
/\_./o__ Tomasz Sterna
(/^/(_^^' http://www.xiaoka.com/
._.(_.)_ im:[EMAIL PROTECTED]
On Cz, 2007-12-20 at 15:14 -0700, Peter Saint-Andre wrote:
Which is better?
(1) Allow a denial of service attack.
(2) Strictly adhere to the letter but not the spirit of the RFC.
I really don't know...
That's why I'm asking here.
--
/\_./o__ Tomasz Sterna
(/^/(_^^' Xiaoka.com
the
thirdparty, that you proved that you are you, and it may let you in.
--
/\_./o__ Tomasz Sterna
(/^/(_^^' Xiaoka.com
._.(_.)_ XMPP: [EMAIL PROTECTED]
times people do not read the documentation
from the beginning to the end. They tend to jump directly in, using
chapter anchors, text search etc. So for full details see... pointers
are very helpful.
--
/\_./o__ Tomasz Sterna
(/^/(_^^' Xiaoka.com
._.(_.)_ XMPP: [EMAIL PROTECTED]
deliver the stanza...
--
/\_./o__ Tomasz Sterna
(/^/(_^^' Xiaoka.com
._.(_.)_ XMPP: [EMAIL PROTECTED]
has an interested resource to protect from SPIM.
Why does 3.1.3.4 does not have such protection? Only offline users are
protected?
You may flood online user with presence-subscriptions, making her go
offline to protect from the flood.
--
/\_./o__ Tomasz Sterna
(/^/(_^^' Xiaoka.com
does not take into account if the item already have
subscription='from'
and pushes unneeded presence packet to the wire.
--
/\_./o__ Tomasz Sterna
(/^/(_^^' Xiaoka.com
._.(_.)_ XMPP: [EMAIL PROTECTED]
binding.
Instead, we documented the full JID binding in RFC3921bis and encourage
it even more... :-/
--
/\_./o__ Tomasz Sterna
(/^/(_^^' Xiaoka.com
._.(_.)_ XMPP: [EMAIL PROTECTED]
Tomasz Sterna
(/^/(_^^' Xiaoka.com
._.(_.)_ XMPP: [EMAIL PROTECTED]
:-/
TCP buffers are not infinite and congestion control kicks very soon and
takes care of excessive bytes.
Wikipedia has some good articles of it. Please read
http://en.wikipedia.org/wiki/TCP_congestion_avoidance_algorithm
--
/\_./o__ Tomasz Sterna
(/^/(_^^' Xiaoka.com
._.(_.)_ XMPP
slash, not any other 'normalized' slash.
--
/\_./o__ Tomasz Sterna
(/^/(_^^' Xiaoka.com
._.(_.)_ XMPP: [EMAIL PROTECTED]
'/' in the JID means that the resource has just started.
Some libraries extend it to caracters such as c/o (8453). The rational
behind that is that it contains a fraction.
I think they do wrong.
--
/\_./o__ Tomasz Sterna
(/^/(_^^' Xiaoka.com
._.(_.)_ XMPP: [EMAIL PROTECTED]
documents for Historical and iteroperability reasons, a
protocol that evolved in the Jabber community and is still in use.
When GPG came into Jabber there was no XHTML-IM yet. ;-)
--
/\_./o__ Tomasz Sterna
(/^/(_^^' Xiaoka.com
._.(_.)_ XMPP: [EMAIL PROTECTED]
in the meantime, reinstalled the system
or just purged the caches?
How would you know if you need to send me the file again, or you just
could reuse the CID?
--
/\_./o__ Tomasz Sterna
(/^/(_^^' Xiaoka.com
._.(_.)_ XMPP: [EMAIL PROTECTED]
Dnia 12-11-2007, pon o godzinie 23:48 +0100, Alexander Gnauck pisze:
I assume they
used multiple accounts to overcome the karma settings. So the per user
karma does not help here.
What about per connection karma, I had describe?
--
/\_./o__ Tomasz Sterna
(/^/(_^^' Xiaoka.com
we dropped the idea, and moved to the file transfer based method.
--
/\_./o__ Tomasz Sterna
(/^/(_^^' Xiaoka.com
._.(_.)_ XMPP: [EMAIL PROTECTED]
to authorise. Additionally it wants to read your vCard data.
What do you want to do?
[Authenticate and allow access] [Only authenticate] [Cancel]
--
/\_./o__ Tomasz Sterna
(/^/(_^^' Xiaoka.com
._.(_.)_ XMPP: [EMAIL PROTECTED]
server data. Easy thing to
implement.
What we could design though, is XMPP based transport for OpenID requests
between servers.
But IIUC the main PITA is XMPP usage, because it's easier and more
natural for web servers to talk HTTP not XMPP.
--
/\_./o__ Tomasz Sterna
(/^/(_^^' Xiaoka.com
that the acceptance is valid (one-time,
until some date or forever).
--
/\_./o__ Tomasz Sterna
(/^/(_^^' Xiaoka.com
._.(_.)_ XMPP: [EMAIL PROTECTED]
Dnia 09-11-2007, Pt o godzinie 23:34 +, Dave Cridland pisze:
In particular, think of it in terms of a (mythical?) server that
supports XEP-0198 as well.
commercial
jabberd 2.1 supports XEP-0198
/commercial
although only on the very basic level.
--
/\_./o__ Tomasz Sterna
from the Consumer would be done with the
token, and provided access to the restricted api's
If I understand correctly, what you are describing is
OpenID authorized by XMPP.
It is already in use. Please see http://openid.xmpp.za.net/
--
/\_./o__ Tomasz Sterna
(/^/(_^^' Xiaoka.com
that XEP-0020 was heavily hacked
lately. And it still shows some rough edges. ;-)
I don't think 2.2 contradicts 2.1. Perhaps it would help for me to add
some flow diagrams and also show the example at the end of section 2.2?
Couldn't hurt. :-)
--
/\_./o__ Tomasz Sterna
(/^/(_^^' Xiaoka.com
out related
data channels and let them in.
Special handling, special modules, special setup - ergo: nobody bothers.
This is one of the reasons why HTTP (one connection) is omnipresent,
even for file archives, and FTP is becoming forgotten.
--
/\_./o__ Tomasz Sterna
(/^/(_^^' Xiaoka.com
Dnia 05-11-2007, Pn o godzinie 16:23 +0100, Tomasz Sterna pisze:
Alternatively we could invent binary-2-utf mapping which has less
overhead than BASE64.
Simplest that comes to mind:
Let's take first 256 allowable UTF-8 characters and assign them to 256
values of a single byte.
That would
UTF-8 character. (Maybe '' to '»' :)
--
/\_./o__ Tomasz Sterna
(/^/(_^^' Xiaoka.com
._.(_.)_ XMPP: [EMAIL PROTECTED]
an effective binary blob
representation?
--
/\_./o__ Tomasz Sterna
(/^/(_^^' Xiaoka.com
._.(_.)_ XMPP: [EMAIL PROTECTED]
on network, read all or full buffer (lets say max 4kB),
push it trough utf-8-internal strings and take the whole lot and feed
it to the parser.
So you read until '' is spotted, as Greg suggested.
--
/\_./o__ Tomasz Sterna
(/^/(_^^' Xiaoka.com
._.(_.)_ XMPP: [EMAIL PROTECTED]
. ;-)
and slow.
I would guess that you would need a _very_ targeted benchmark to
actually see a slowdown.
Let's keep in mind, we're I/O bound, so processor time in our context is
cheap.
--
/\_./o__ Tomasz Sterna
(/^/(_^^' Xiaoka.com
._.(_.)_ XMPP: [EMAIL PROTECTED]
nightmare?
--
/\_./o__ Tomasz Sterna
(/^/(_^^' Xiaoka.com
._.(_.)_ XMPP: [EMAIL PROTECTED]
normal roster-push to the user.
Thoughts?
Good idea.
I'm willing to implement it. :-)
--
/\_./o__ Tomasz Sterna
(/^/(_^^' Xiaoka.com
._.(_.)_ XMPP: [EMAIL PROTECTED]
Dnia 01-11-2007, Cz o godzinie 17:25 -0400, Joe Hildebrand pisze:
![CDATA[ YOUR DATA HERE ]]
nul?
Not only NULs.
CDATA section still needs to be valid UTF-8. So you cannot put any
binary chunk inside. And ]] string, which might happen in binary
data.
--
/\_./o__ Tomasz Sterna
'
xmlns='http://jabber.org/protocol/ibb'/
/iq
We need some way of assigning this IBB to XTLS.
(This could be also related to IBB-FT, etc.)
--
/\_./o__ Tomasz Sterna
(/^/(_^^' Xiaoka.com
._.(_.)_ XMPP: [EMAIL PROTECTED]
to client
implementors.
I think, that we should document best practices to do so, and
standardize the extensions you had described, in sake of
interoperability.
So please, do share. :-) It's the reason this list was created for. :-)
--
/\_./o__ Tomasz Sterna
(/^/(_^^' Xiaoka.com
._.(_.)_ XMPP
the schema.
So, this basically jeopardizes the feature-not-implemented error.
Any packet for a feature that is not implemented in server does not
match the known schema.
And if a server knows it conforms to it's schema - it implements the
feature.
--
/\_./o__ Tomasz Sterna
(/^/(_^^' Xiaoka.com
like opening another stream inside a context of previous
stream. :-)
--
/\_./o__ Tomasz Sterna
(/^/(_^^' Xiaoka.com
._.(_.)_ XMPP: [EMAIL PROTECTED]
invisible state when
forwarded without touching.
And what about IQs? Most of them are handled by server?
What should it do when receiving iq/ of unknown type? Error? Ignore?
--
/\_./o__ Tomasz Sterna
(/^/(_^^' Xiaoka.com
._.(_.)_ XMPP: [EMAIL PROTECTED]
to blocked contacts.
--
Tomasz Sterna
Xiaoka.com http://www.xiaoka.com/
. (With same error for aoutgoing messages as in XEP-0191.)
--
Tomasz Sterna
Xiaoka.com http://www.xiaoka.com/
the time. Or at
least I'm too lazy to work on a whole new protocol.
What I meant is that:
We really could do better [than simple invisibility] with Privacy Lists.
For the rest, let me start a new thread. :-)
--
Tomasz Sterna
Xiaoka.com http://www.xiaoka.com/
it's time to think of Stacked Privacy Lists (more than one PL
enabled at a time) that would make XEP-0126 much more sensible.
--
Tomasz Sterna
Xiaoka.com http://www.xiaoka.com/
. If a packet passes the first active list it is put through second
and so on.
--
Tomasz Sterna
Xiaoka.com http://www.xiaoka.com/
generates low traffic, I am able to run it
cheaply.
If it would generate high transfers, I would be forced to pay for other
people bandwidth usage. Not nice.
--
Tomasz Sterna
Xiaoka.com http://www.xiaoka.com/
1 - 100 of 119 matches
Mail list logo
