Subject: [Simple] Update to xcap package

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 16 Feb 2004 17:32:04 -0500

Folks,

I've submitted a revision to the xcap event package. Until it appears in 
the archives, you can pick it up at:

http://www.jdrosen.net/papers/draft-ietf-simple-xcap-package-01.txt

The changes from the last version:

1. Notifications contain the before and after etags

2. Inclusion of the schema

3. defined a mechanism for subscribing to documents in the global tree
- define a well known user name to subscribe to.

4. changed MIME type of change documents to use +xml convention in rfc 3023.

There are really two major open issues.

The first is alignment with the config framework. Indeed, there has been 
some attempt at some alignment, and this will be reflected in the config 
framework revision that is pending. With documents in place, we will be 
able to have a look at how it might look so a decision can be made 
shortly. I am personally on the fence on this topic.

The second open issue is, what is the scope of this event package. That 
is, what is it that you are subscribing to? There are three possible things:

The first is that subscription is to the document itself, in which case 
a full state update in a NOTIFY contains the current document. The 
second is a subscription to the revision history, which gives you 
changes, but not the full state of the document. The third option is to 
just subscribe to the etag, so that you know that something changed, but 
the notifications don't tell you anything about what changed. Which do 
we need? The latter is the simplest, good for the case where third
party modification of documents is rare. If xcap is utilized in the 
scope for which it was proposed - management of a user's provisioned 
data, I do believe these events would be rare, and that this would be 
the ideal design choice. As such, my own preference would be to do that.

Thoughts?

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: "Chris Boulton" <[email-masked]>
Date: Tue, 17 Feb 2004 08:48:59 -0000

Jonathan - just so I've got a clear picture ;-)  With option 3, you are
proposing that a user is only notified that a document has changed But
NOT what has changed - this would then be retrieved as required using
XCAP operations(GET).  If this is the case, it certainly seems the
cleanest and less problematic solution.

Chris.

>-----Original Message-----
>From: Jonathan Rosenberg [mailto:[email-masked]]
>Sent: 16 February 2004 22:32
>To: Simple WG
>Subject: [Simple] Update to xcap package
>
>Folks,
>

This message has been scanned for viruses by MailControl - www.mailcontrol.com

---

From: "Chris Boulton" <[email-masked]>
Date: Tue, 17 Feb 2004 08:48:59 -0000

Chris.

---

From: [email-masked]
Date: Tue, 17 Feb 2004 11:56:22 +0200

I'm not sure if this is the most efficient though. I would go for a combination of all three: The first NOTIFY returns the full document with an etag, subsequent NOTIFYs return changes along with the new etag.

Filters can be used to get etags only.

/Hisham

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Chris Boulton
> Sent: 17.February.2004 10:49
> To: Jonathan Rosenberg; Simple WG
> Subject: RE: [Simple] Update to xcap package
> 
> 
> >4. changed MIME type of change documents to use +xml 
> convention in rfc
> >3023.
> >
> >

---

From: [email-masked]
Date: Wed, 18 Feb 2004 09:37:16 +0200

I had the use case in my mind that if we have a list that is shared amongst 100 or even 10000 employees and one modifies it, then this will result in 100 NOTIFYs. Each then might generate a GET.

Also for a conference using XCAP, it might be true that there is one creator, but there could be many privileged users who have read rights and can subscribe to the changes in the conference policy.

I'm not sure if the cost of sending the changes in a NOTIFY as opposed to just sending the etag is so great.

/Hisham

> ext Jonathan Rosenberg
> Sent: 17.February.2004 23:51
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Simple] Update to xcap package
> 
> 
> 
> 
> 
> [email-masked] wrote:
> 
> > I'm not sure if this is the most efficient though. I would go for a
> > combination of all three: The first NOTIFY returns the full document
> > with an etag, subsequent NOTIFYs return changes along with the new
> > etag.
> > 
> Sorry to not be clear; this is exactly proposal 1. I wasnt saying
> that proposal one DOESNT include etag, it would also include it.
> 
> I think the choice is driven largely by use case. If we 
> expect that it 
> is infrequent for anyone else but a user to update their own content, 
> then option 3 is the right choice. Hisham - can you comment 
> on the use 
> cases that you think will make this efficiency important?
> 
> Thanks,
> Jonathan R.
> 
> --

---

From: [email-masked]
Date: Thu, 19 Feb 2004 11:06:16 +0200

> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 19.February.2004 06:48
> > I had the use case in my mind that if we have a list that is shared
> > amongst 100 or even 10000 employees and one modifies it, then this
> > will result in 100 NOTIFYs. Each then might generate a GET.
> 
> OK.
> 
> > 
> > Also for a conference using XCAP, it might be true that there is one
> > creator, but there could be many privileged users who have read
> > rights and can subscribe to the changes in the conference policy.
> > 
> > I'm not sure if the cost of sending the changes in a NOTIFY as
> > opposed to just sending the etag is so great.
> 
> One thing we need to figure out is the format for the NOTIFY. 
> WHats in 
> the event package at the moment won't work, because there are 
> many valid 
> results that can be obtained from applying the xcap operations to a 
> document. 

I'm sorry, I don't understand what you mean by saying that many valid results can be obtained. Can you elaborate?

Thanks,
Hisham

> You need a proper "diff" format, I think. If you 
> want a pure 
> XML diff, XSLT is a choice, though you may not want to 
> process that on a 
> phone. A standard patch file format is another choice. I 
> welcome other 
> ideas.
> 
> -Jonathan R.
> 
> 
> --

---

From: [email-masked]
Date: Mon, 23 Feb 2004 12:59:22 +0200

You can probably indicate the position of the insertion using the xpath like expression. Something like:

PUT http://document/foo/bar[@id="3 and 3"]

<bar id="3"/>

or

PUT http://document/foo/bar[@id="3 and position()=3"]

<bar id="3"/>

Valid xpath expressions, but not sure if they are valid http URIs.

/Hisham

> Sent: 22.February.2004 10:23
> inline.
> >> -----Original Message----- From: ext Jonathan Rosenberg
> >> [mailto:[email-masked]] Sent: 19.February.2004 06:48 To:
> >> Khartabil Hisham (Nokia-TP-MSW/Helsinki) Cc: [email-masked];
> >> [email-masked] Subject: Re: [Simple] Update to xcap package
> >> 
> >> 
> >> 
> >> 
> >> 
> >>> I had the use case in my mind that if we have a list that is
> >>> shared amongst 100 or even 10000 employees and one modifies it,
> >>> then this will result in 100 NOTIFYs. Each then might generate a
> >>> GET.
> >> 
> >> OK.
> >> 
> >> 
> >>> Also for a conference using XCAP, it might be true that there is
> >>> one creator, but there could be many privileged users who have
> >>> read rights and can subscribe to the changes in the conference
> >>> policy.
> >>> 
> >> One thing we need to figure out is the format for the NOTIFY. WHats
> >> in the event package at the moment won't work, because there are 
> >> many valid results that can be obtained from applying the xcap
> >> operations to a document.
> > 
> > 
> > I'm sorry, I don't understand what you mean by saying that 
> many valid
> > results can be obtained. Can you elaborate?
> 
> Sorry for being unclear on it.
> 
> Lets say I have a document like this:
> 
> <foo>
>    <bar id="1"/>
>    <bar id="2"/>
> </foo>
> 
> and I do an xcap addition operation:
> 
> PUT http://document/foo/bar[@id="3"]
> 
> <bar id="3"/>
> 
> 
> XCAP requires that the server create this element such that a 
> GET to the 
> same URI returns the same body. However, there are three ways 
> that the 
> server could do such an insertion and still meet that definition:
> 
> <foo>
>    <bar id="3"/>
>    <bar id="1"/>
>    <bar id="2"/>
> </foo>
> 
> OR
> 
> <foo>
>    <bar id="1"/>
>    <bar id="3"/>
>    <bar id="2"/>
> </foo>
> 
> OR
> 
> <foo>
>    <bar id="1"/>
>    <bar id="2"/>
>    <bar id="3"/>
> </foo>
> 
> 
> The current xcap-package includes a hash in the notify, to allow the 
> client to match what they did against what the server has. I believe 
> that, in this hash, ordering of elements and attributes is 
> signficiant. 
> As a result, the hash computed by the server might not match the one 
> computed by the client, since both client and server did the insert 
> separately.
> 
> A different "diff" format can be defined which is more precise about 
> where the server did the insertion. For any element, specifying its 
> parent and previous sibling is sufficient. If we want the 
> hash to remain 
> in the notifications, we'd need to define a format like that.
> 
> Hope this clarifies.
> 
> -Jonathan R.
> 
> 
> --

---

From: [email-masked]
Date: Tue, 24 Feb 2004 14:11:21 +0200

Something else occured to me. Modifying your example not to include id attribute, we have:

<foo>
   <bar>a</bar>
   <bar>b</bar>
</foo>

PUT http://document/foo/bar

<bar>c</bar>

We end up with (c replaces a):

<foo>
   <bar>c</bar>
   <bar>b</bar>
</foo>

The desire was to add a 3rd <bar> element, but instead the first one was replaced. Oops.

Now I do a GET:

GET http://document/foo/bar

What does that return? <bar>c</bar>, <bar>b</bar> or both? It is not guaranteed to return what you put using PUT.

At the moment, the only way to add c is to replace the whole of <foo>. Is this good enough and acceptable? Of course we can give ids to every <bar>, but that's too much, IMO.

The other thing we can do is something like:

PUT http://document/foo/bar="c"

<bar>c</bar>

But there's no point in having a PUT content in this case, and it doesn't work if bar has sub-elements.

/Hisham

---

From: [email-masked]
Date: Wed, 25 Feb 2004 17:13:30 +0200

> Sent: 25.February.2004 06:37
> Yes, something like this would work. No doubt fuller xpath 
> would enable
> us to more concretely specify insertion points. Its not clear whether
> these are needed in xpath per se, but rather in the "diff" sent in the
> notifications for the package.
> 
> A few more comments inline:
> 
> This is not legal, I don't think.

It is legal in xpath, but not xcap.

/Hisham

> I believe its http://example.com/document/foo/bar[@id="3" and 
> position()="3"]
> 
> 
> > 
> > <bar id="3"/>
> > 
> As Ted points out, they would need to be escaped.
> 
> -Jonathan R.
> 
> 
> --

---

From: [email-masked]
Date: Wed, 25 Feb 2004 17:19:40 +0200

Jonathan,

Apparently (according to Jari), the current solution in xcap supports this:

we have:

<foo>
   <bar>a</bar>
   <bar>b</bar>
</foo>

PUT http://document/foo/bar[3]

<bar>c</bar>

<foo>
   <bar>a</bar>
   <bar>b</bar>
   <bar>c</bar>
</foo>

This helps. There is the limitation that you can only add an element at the end, otherwise it is a replace. I'm ok with that.

One comment inline...

> Sent: 25.February.2004 06:53
> No; the above request would fail since the URI identifies multiple 
> existing elements. It needs to identify one.
> 
> > 
> > What does that return? <bar>c</bar>, <bar>b</bar> or both? 
> It is not guaranteed to return what you put using PUT.
> 
> Neither, because of the above constraint, this would also return an 
> error (again - unless we modify xcap to allow multiple 
> elements in get/put).
> 
> > 
> > At the moment, the only way to add c is to replace the 
> whole of <foo>. Is this good enough and acceptable? Of course 
> we can give ids to every <bar>, but that's too much, IMO.
> 
> You need a way to uniquely identify it. Its no different than 
> adding a 
> file to a directory - it has to be unique amongst other files.
> 
> > 
> > But there's no point in having a PUT content in this case, 
> and it doesn't work if bar has sub-elements.
> 
> Something like this would work, yes. The proper syntax you 
> are looking 
> for is http://example.com/document/foo/bar[text()="c"]. Yes, its 
> redundant, but if you want to use text content to uniquely identify 
> elements, then thats what you would have to do.
> 
> If an element has sub-elements, you can also select based on the 
> sub-elements. For example, if your doc is:
> 
> <?xml version="1.0" encoding="UTF-8"?>
>   <foo>
>     <bar id="1"><foo2></foo2></bar>
>     <bar id="2"><foo1></foo1></bar>
>   </foo>
> 
> then this would get the second bar:
> 
> GET http://example.com/document/foo/bar[foo1]
> 
> 
> So, the question is - what kind of information do we want to 
> allow xcap 
> to use to uniquely identify an element for deletion, insertion or 
> creation? Right now, the spec focuses on element names and 
> attributes. 
> One would need to design one's schema to make sure that these 
> existed as 
> unique identifiers. It is easy to add any of the following:
> 
> 1. text content
> 2. names of child elements
> 3. boolean operators (i.e., a child exists)
> 4. existence of attributes

1 and 2 at least, not sure about 3 and 4.

/Hisham

> 
> Its just a complexity/flexibility trade off. I would be willing to 
> expand the scope of xcap a bit here; I suspect names of child 
> elements 
> and text content might also be useful. If we start adding 
> more and more, 
> we may as well go back to full xpath support and just 
> reference the spec.
> 
> And again, I view that as different from the scope of the 
> notification 
> format, where we may want to use more functionality in order to 
> guarantee that we have a way to specify a unique insertion point.
> 
> -Jonathan R.
> 
> --

---

From: [email-masked]
Date: Wed, 25 Feb 2004 17:21:20 +0200

Why can't an element be uniquely identified by its value?

/Hisham

> ext Joel M. Halpern
> Sent: 25.February.2004 15:20
> To: [email-masked]
> Thinking both about the "SIMPLE" case, and about other things 
> that might 
> use XCAP, I think this is a mistake.  XCAP is not about 
> modifying arbitrary 
> documents.  It is about modifying documents that have been 
> designed to be 
> used in conjunction with XCAP.  As such, it seems to me perfectly 
> reasonable to say that all repeated elements of all such 
> documents must 
> have uniquely identifying attributes.  In fact, such 
> attributes are a good 
> idea anyway.  (Otherwise, one amplifies the confusion associated with 
> replacing keying material, for example.)
> 
> Yours,
> Joel M. Halpern
> 
> At 11:53 PM 2/24/2004 -0500, Jonathan Rosenberg wrote:
> allow xcap to 
> >use to uniquely identify an element for deletion, insertion 
> or creation? 
> >Right now, the spec focuses on element names and attributes. 
> One would 
> >need to design one's schema to make sure that these existed 
> as unique 
> >identifiers. It is easy to add any of the following:
> >
> >1. text content
> >Its just a complexity/flexibility trade off. I would be 
> willing to expand 
> >the scope of xcap a bit here; I suspect names of child 
> elements and text 
> >content might also be useful. If we start adding more and 
> more, we may as 
> >well go back to full xpath support and just reference the spec.
> 
>

---

From: [email-masked]
Date: Wed, 25 Feb 2004 17:21:20 +0200

/Hisham

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 25 Feb 2004 11:29:26 -0500

An element "can" be uniquely identified by its value.  It "can" be uniquely 
identified by contained elements.
The question is not whether we need those forms of identification.  We are 
not trying to select paragraphs from free text.  We are trying to select 
information elemetns in a structured document.
In this environment, adding more ways to identify components adds complexity.
If we need the complexity, so be it.
But if we do not need it, we should avoid it.

Yours,
Joel M. Halpern

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 25 Feb 2004 11:29:26 -0500

Yours,
Joel M. Halpern

---

From: [email-masked]
Date: Thu, 26 Feb 2004 10:21:39 +0200

Sorry I meant this:

PUT http://document/foo/bar[@id="3" and 3]

I had the quotes at the wrong place

> Sent: 25.February.2004 18:20
> I dont think its legal xpath; or at least, it doesnt do what 
> you want. 
> Its saying to choose the element bar whose id attribute is 
> equal to "3 
> and 3". So, it would select an element in a document like this:
> 
> <foo>
>    <bar id="3 and 3"/>
> </foo>
> 
> If you want the element whose id attribute is 3 and whose 
> position is 3, 
> the and cannot be in quotations.
> 
> Note that it doesnt seem to work in XML spy either.
> 
> -Jonathan R.
> --

---

From: [email-masked]
Date: Thu, 26 Feb 2004 10:21:39 +0200

Sorry I meant this:

---

From: [email-masked]
Date: Thu, 26 Feb 2004 13:07:38 +0200

> From: Jari Urpalainen [mailto:[email-masked]]
> Sent: 26.February.2004 10:04
> To: ext Jonathan Rosenberg
> Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); [email-masked];
> [email-masked]
> On Sun, 2004-02-22 at 10:23, ext Jonathan Rosenberg wrote:
> 
> > XCAP requires that the server create this element such that 
> a GET to the 
> > same URI returns the same body. However, there are three 
> ways that the 
> IMO you could simply define in the base spec that when appending
> node(sets) or attributes with conditions like this, the insertion will
> take place to the end of siblings. This would then behave 
> similarly when
> adding by using index-numbers (bar[3]) unless you want to 
> enable "real"
> inserts like in XUpdate http://www.xmldb.org/xupdate/. Btw. the
> xml-libraries that I am aware of, behave like this anyway.
> 
> If ordered inserts are really required (which I doubt, at least
> currently there seem to be no AU cases for that) one possibility could
> be that you'll give additionally also the index for insertion like
> 
> PUT http://document/foo/bar[@id="3"][2]

I don't think this works. This selects the second occurance of bar with id 3.

/Hisham
> BR,
> Jari

---

From: [email-masked]
Date: Thu, 26 Feb 2004 13:07:38 +0200

/Hisham

---

From: [email-masked]
Date: Thu, 26 Feb 2004 14:00:52 +0200

> Sent: 25.February.2004 18:28
> > Apparently (according to Jari), the current solution in 
> xcap supports
> > this:
> > 
> > we have:
> > 
> > <foo> <bar>a</bar> <bar>b</bar> </foo>
> > 
> > <foo> <bar>a</bar> <bar>b</bar> <bar>c</bar> </foo>
> 
> Correct. c does not replace a; c is added at the end as you 
> have shown.
> XCAP currently allows selection by element name, element position, or
> element filtered by value of an attribute.

Oops, I didn't mean to say c replaces a. A copy paste error, sorry.

> 
> > 
> > This helps. There is the limitation that you can only add an element
> > at the end, otherwise it is a replace. I'm ok with that.
> 
> OK, good. I think its also worth noting in xcap that this is a useful 
> case for doing basic insertion operations. I also make sure 
> to note the 
> importance of designing the schema in a way that makes it 
> efficient with 
> xcap.
> 
> >> So, the question is - what kind of information do we want to allow
> >> xcap to use to uniquely identify an element for deletion, insertion
> >> or creation? Right now, the spec focuses on element names and 
> >> attributes. One would need to design one's schema to make sure that
> >> these existed as unique identifiers. It is easy to add any of the
> >> following:
> >> 
> >> 1. text content 2. names of child elements 3. boolean operators
> >> (i.e., a child exists) 4. existence of attributes
> > 
> > 
> Can you provide some motivating cases for 1 and 2? Is there 
> something in 
> CPCP?

In CPCP, you might need to replace a resource in the ACL, or change its access-type from allowed to blocked. The way XCAP is specified now, as we discussed, you need to know the exact position for the resource you want replace (they don't have unique IDs besides the URI they carry). This might be ok, if we always assume that the client has an exact copy of what is on the server. I.e. The client MUST always know the number of elements present and provide the position where to insert the new element as the last element, and therefore knows the exact position of the element to replace.

If that can't be guaranteed then we need 1 and 2 above for CPCP.

My proposal is:

a. If there is an attribute that uniquely identifies an element, then the client uses that to insert and/or replace.
b. If there is no attribute that uniquely identifies an element, then the client can only insert an element as the last one in a list.

It would also be nice if, for a, the client can indicate the position it wants to insert, for hashing reasons.

/Hisham

---

From: Adam Roach <[email-masked]>
Date: Fri, 27 Feb 2004 21:04:19 -0600

[email-masked] wrote:

> In CPCP, you might need to replace a resource in the
> ACL, or change its access-type from allowed to blocked.
> The way XCAP is specified now, as we discussed, you need
> to know the exact position for the resource you want
> replace (they don't have unique IDs besides the URI they
> carry).

It seems to me that you've identified a shortcoming in
the current CPCP XCAP draft. As Joel pointed out, XCAP
is largely intended to be used on XML documents that
were developed explicitly for use with XCAP. If you
leave no easy way to identify elements in a schema
ostensibly designed for use with XCAP, then I'd say the
schema needs more work.

> In CPCP, you might need to replace a resource in the ACL, or 
> change its access-type from allowed to blocked. The way XCAP 
> is specified now, as we discussed, you need to know the exact 
> position for the resource you want replace (they don't have 
> unique IDs besides the URI they carry). This might be ok, if 
> we always assume that the client has an exact copy of what is 
> on the server. I.e. The client MUST always know the number of 
> elements present and provide the position where to insert the 
> new element as the last element, and therefore knows the 
> exact position of the element to replace.

Erm... isn't that pretty much the case anyway? If the client
doesn't have the most recent document, then any attempted change
will be kicked back because the etag does not match. Now, I'll
admit that it may be easier to implement a client that uses
identifiers rather than positions, but I don't see your
particular objection as a sticking point.

/a

---

From: Adam Roach <[email-masked]>
Date: Fri, 27 Feb 2004 21:04:19 -0600

/a

---

From: [email-masked]
Date: Sun, 29 Feb 2004 18:10:37 +0200

Hi,

> Things can get a lot easier and more flexible if we can 
> generally assume that the client has a copy of the data its modifying, 
> so that it can use position to effect insertions and modifications.
> 
> If its not possible, then I think we need to insist on unique 
> attributes or it just gets really out of hand.

It would be really really nice if we would not need to assume that the client always has a fresh copy. While this may the case in most use cases, for instance large lists manipulated by multiple clients become cumbersome.

Markus 

> Sent: 28 February, 2004 00:22
> >> [mailto:[email-masked]] Sent: 25.February.2004 18:28 To:
> >> something in CPCP?
> > In CPCP, you might need to replace a resource in the ACL, or change
> > its access-type from allowed to blocked. The way XCAP is specified
> > now, as we discussed, you need to know the exact position for the
> > resource you want replace (they don't have unique IDs 
> besides the URI
> > they carry). This might be ok, if we always assume that the client
> > has an exact copy of what is on the server. I.e. The client MUST
> > always know the number of elements present and provide the position
> > where to insert the new element as the last element, and therefore
> > knows the exact position of the element to replace.
> 
> This is really an important assumption to verify or reject.
> 
> Things can get a lot easier and more flexible if we can 
> generally assume 
> that the client has a copy of the data its modifying, so that 
> it can use 
> position to effect insertions and modifications.
> 
> If its not possible, then I think we need to insist on unique 
> attributes 
> or it just gets really out of hand.
> 
> 
> > 
> > a. If there is an attribute that uniquely identifies an 
> element, then
> > the client uses that to insert and/or replace. b. If there is no
> > attribute that uniquely identifies an element, then the client can
> > only insert an element as the last one in a list.
> 
> In both cases, I think that insertion should take place at the end of 
> the list. This vastly simplifies subsequent position based 
> operations on 
> the document.
> 
> > 
> > It would also be nice if, for a, the client can indicate 
> the position
> > it wants to insert, for hashing reasons.
> 
> This appears hard to do. I was unable to come up with a 
> specific reason 
> it would be needed. What do you mean by hashing?
> 
> -Jonathan R.
> 
> 
> --

---

From: [email-masked]
Date: Sun, 29 Feb 2004 18:10:37 +0200

Hi,

Markus

---

From: [email-masked]
Date: Mon, 1 Mar 2004 04:08:26 +0200

> Sent: 28.February.2004 00:22

In the xcap package NOTIFY, there is a hash. The problem is, as we have been discussion, in that a server can insert an element in different positions. Mandating the client to specify the position is one way of solving the hashing problem (of course, the other way is to mandate that a server always appends at the end. I'm not sure how feasible that is since we want to make use of currently existing http servers)..

/Hisham

---

From: [email-masked]
Date: Mon, 1 Mar 2004 04:08:26 +0200

/Hisham