Subject: [Simple] WGLC: partial notification

From: Robert Sparks <[email-masked]>
Date: Wed, 21 Apr 2004 09:55:42 -0500

This is a Working Group Last call on the following drafts:

http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-notify-02.txt
http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-pidf-format-01.txt

This abbreviated WGLC will end on Wednesday, April 28.

These drafts went through a previous last call at the beginning of
March. These versions reflect changes due to comments received during
that period. See
https://www1.ietf.org/mail-archive/working-groups/simple/current/msg02519.html
for details.

Please send comments to the list, copying the editor. If you reviewed
the draft and found no issues, please indicate so on the list.

RjS

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

---

From: [email-masked]
Date: Fri, 23 Apr 2004 20:23:55 +0300

Hi,

Your proposal sounds good. Probably the sentence "When one tuple
changes, a new document containing the full set of tuples is delivered."
should read something like -> "When any number of tuples change, a new
document containing the full set of tuples is delivered"

- Mikko

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of ext Robert Sparks
> Sent: Friday, April 23, 2004 6:33 PM
> To: [email-masked]
> Subject: Re: [Simple] WGLC: partial notification
> 
> 
> The abstract for -partial-notification needs to focus 
> more on what the document is defining. I suggest this
> as a replacement for the current text:
>                                                               
>                  Abstract
> 
>    By default, presence delivered using the Presence Event
>    Package for the Session Initiation Protocol is represented
>    in the Presence Information Data Format (PIDF). A PIDF
>    document contains a set of tuples, each representing
>    a different aspect of the presence being reported. When
>    one tuple changes, a new document containing the full set
>    of tuples is delivered. This memo defines an extension
>    allowing delivery of a new document type that contains
>    information about only those tuples that have actually
>    changed.
> 
> On Wed, 2004-04-21 at 09:55, Robert Sparks wrote:
> http://www.ietf.org/internet-drafts/draft->
ietf-simple-partial-notify-0
> > 2.txt

---

From: [email-masked]
Date: Mon, 26 Apr 2004 22:16:48 +0300

Hi,

Thanks for comments. Responses inline:

> Writing as a WG member - not as chair -
> 
> I've sent a list of typo level nits in these drafts to Mikko privately

> -
> 
> While doing a nit review, I found some things that should have 
> received list attention earlier.
> 
> In section 4.4 of -partial-notify it says "The PA SHOULD construct the

> partial presence document according to the following logic:" followed 
> by a bunch of MUST level statements. Why is that SHOULD there? What 
> would it mean to violate it? I suggest striking it and simply saying 
> "The PA constructs"

Yes, SHOULD is probably useless and confusing here. I will remove it.

> Why do we have both "state" and "version"? As defined in these drafts,

> state=full if and only if version=0. You could delete the state 
> parameter with no loss of information, so why is it there?

I believe the original need for the "state" was that the "version" could
be initialized to some random value. Now, if "version" is always
initialized to 0 there is no need for the "state" attribute. Both
solutions should work and if nobody else comments otherwise I will
remove the "state" attribute.

> 3261 currently allows overlapping non-INVITE transactions inside a 
> dialog (there's an open issue suggesting this might be a bad thing, 
> see http://bugs.sipit.net/sipwg/show_bug.cgi?id=686). Neither
> 3265 or simple-presence prohibit overlapping NOTIFYs. For 
> full state documents, having multiple outstanding NOTIFYs is 
> probably manageable. For partial state documents, at least as 
> they are specified here, it could be disastrous. Consider 
> four notifies N1(full), N2(partial), N3(full), N4(partial). 
> If the recipient receives only N1 and N4 (something prevents 
> N2 and N3 from being delivered or simply delays them 
> (packetloss over UDP for example)), it will apply the delta 
> in N4 to the wrong full state document (N1 instead of N3). 

Actually it wouldn't because of "version" handling. Section 4.5 applies
here. But in any case this kind of behavior is quite bad as it might
result in frequent subscription refreshes to obtain full presence state.
More below.

> We
> can preserve the properties of the existing system is we
> forbid sending a NOTIFY with a document with state="partial" 
> when any other NOTIFY transaction is still in progress on this dialog.

This is a good point. Your proposed solution should work. This may cause
some extra implementation effort for PA but I cannot see any way around
this. If no other comments are received I will add text forbidding
sending a NOTIFY with a document with state="partial" (version=0) when
any other NOTIFY transaction is still in progress on this dialog. 

> Section 4.5 of partial-notify says "If the watcher receives a
> presence document whose "version" attribute value (is) higher 
> by more than one with the locally stored value, the watcher 
> assumes that one or more NOTIFYs were lost. The watcher 
> SHOULD either refresh the subscription 
> in order to receive a full presence document or terminate the 
> subscription."  Why is that SHOULD? In what scenario is any 
> other course of action reasonable? (The only one I can think 
> of is _if_ we allow overlapping partial NOTIFYs, then the 
> watcher can wait around for awhile for the gaps to fill in - 
> if we allow this, then we need to explicitly state this as 
> why the above is SHOULD, not MUST. However, I think this 
> should be a MUST.)

Well, there probably isn't any good cases where watcher wouldn't
terminate or refresh subscription. Changing SHOULD to MUST should
provide more consistent behavior.
 
> Just below that, there's a "SHOULD discard the document" if 
> it gets a partial notification with a lower version number. I 
> don't see how this is right at all, and suggest that this 
> MUST trigger a refresh or termination instead. (We wouldn't 
> get to this logic if a NOTIFY was reordered and arrived late 
> - the CSeq processing logic would 
> have caught it).

Right, and if we don't allow sending new NOTIFYs if there is a pending
transaction then I believe reordering should never happen. But if in
this situation watcher receives a presence document with lower version
number there should be no harm in discarding it because it already has a
consistent presence state. This is more or less an error case which
probably should never happen but I think there is no need to refresh or
terminate the subscription.

- Mikko

> I'll send a separate message on the Security Considerations 
> section for -partial-notify.
> 
> RjS
> 
>

---

From: [email-masked]
Date: Tue, 27 Apr 2004 12:36:42 +0300

If the version handling goes as I described in my other email, then it should solve this problem.

N1(full, v=0), N4(partial, v=4). The subscriber realises that there are 2 notifications missing and does not accept N4.

/Hisham

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Robert Sparks
> Sent: 26.April.2004 22:29
> To: Lonnfors Mikko (Nokia-NRC/Helsinki); [email-masked]
> Subject: RE: [Simple] WGLC: partial notification
> 
> 
> (private reply to avoid confusion on the list - we'll go
>  back there after we get closer on this question)
> 
> How does version help here? The recipient has seen exactly
> two documents, the first with version=0 (which happens to
> be N1) and the second has version=1 (which happens to be
> N4). The recipient has no way to know it missed N2 and
> N3. 
> 
> I don't see how version as it's defined helps you at all in this 
> case. We'll need something like the proposal to forbid the
> possibility of overlaps to prevent it.
> 
> RjS
> 
> 
> 
>

---

From: [email-masked]
Date: Tue, 27 Apr 2004 12:33:40 +0300

Here is an example where both state and version are needed:

PA sends N1(full), N2(full), N3(partial).

If the version is set to 0 everytime there is full state, and N2 was never received, the subscriber would then think that N3 is a partial of N1.

To solve this, you need the version to continuously increase by 1, even when a full state is being sent. You would then also need the state attribute to indicate full/partial. The version is used by the subscriber to learn that a NOTIFY was not received (N2).

/Hisham

> ext [email-masked]
> Sent: 26.April.2004 22:17
> To: [email-masked]; [email-masked]
https://www1.ietf.org/mail-archive/working-groups/simple/current/msg02
> 519.html

---

From: [email-masked]
Date: Tue, 27 Apr 2004 12:45:38 +0300

Hi,

> If the version is set to 0 everytime there is full state, and 
> N2 was never received, the subscriber would then think that 
> N3 is a partial of N1.
> 
> To solve this, you need the version to continuously increase 
> by 1, even when a full state is being sent. You would then 
> also need the state attribute to indicate full/partial. The 
> version is used by the subscriber to learn that a NOTIFY was 
> not received (N2).

Ok, so your proposal is that "version" should be scoped with the
subscription i.e. first NOTIFY within a subscription would have
version="0" and then it would be continuously increased by one for every
notifications (regardless if it contains full or partial state)?

How should subscription refreshes be handled? If we have
PA sends N1(full), N2(full), N3(partial)
And N2 is lost watcher would refresh the subscription when it receives
N3. Now
Would the PA send N1(full, version="0") or N4(full, version="3")?

- Mikko 

> > From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of 
> > > can preserve the properties of the existing system is we forbid 
> > > sending a NOTIFY with a document with state="partial" 
> when any other 
> > > NOTIFY transaction is still in progress on
> > this dialog.
> > 
> > > presence document whose "version" attribute value (is) higher by 
> > > more than one with the locally stored value, the watcher assumes 
> > > that one or more NOTIFYs were lost. The watcher SHOULD either 
> > > refresh the subscription in order to receive a full presence 
> > > document or terminate the subscription."  Why is that SHOULD? In 
> > > what scenario is any other course of action reasonable? (The only 
> > > one I can think of is _if_ we allow overlapping partial NOTIFYs, 
> > > then the watcher can wait around for awhile for the gaps 
> to fill in 
> > > - if we allow this, then we need to explicitly state this as
> > number there should be no harm in discarding it because it 
> already has 
> > a consistent presence state. This is more or less an error 
> case which

---

From: [email-masked]
Date: Tue, 27 Apr 2004 12:45:38 +0300

Hi,

- Mikko 

> (version=0) when

---

From: [email-masked]
Date: Tue, 27 Apr 2004 13:04:57 +0300

> From: Lonnfors Mikko (Nokia-NRC/Helsinki) 
> Sent: 27.April.2004 12:46
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); 
> [email-masked]';
> [email-masked]'
> Ok, so your proposal is that "version" should be scoped with 
> the subscription i.e. first NOTIFY within a subscription 
> would have version="0" and then it would be continuously 
> increased by one for every notifications (regardless if it 
> contains full or partial state)?
> 
> And N2 is lost watcher would refresh the subscription when it 
> receives N3. Now

version gets reset to 0 when a SUBSCRIBE refresh is received.

/Hisham

---

From: [email-masked]
Date: Tue, 27 Apr 2004 13:04:57 +0300

/Hisham

---

From: [email-masked]
Date: Tue, 27 Apr 2004 13:29:46 +0300

Correct. Your proposal for "version" handling seems quite nice and it
also solves this problem.

- Mikko

> From: Khartabil Hisham (Nokia-TP-MSW/Helsinki) 
> Sent: Tuesday, April 27, 2004 12:37 PM
> To: 'ext Robert Sparks'; Lonnfors Mikko (Nokia-NRC/Helsinki); 
> [email-masked]
> If the version handling goes as I described in my other 
> email, then it should solve this problem.
> 
> N1(full, v=0), N4(partial, v=4). The subscriber realises that 
> there are 2 notifications missing and does not accept N4.
> 
> /Hisham
> 
> > > > see http://bugs.sipit.net/sipwg/show_bug.cgi?id=686). 
> Neither 3265 
> > > > or simple-presence prohibit overlapping NOTIFYs. For full state 
> > > > documents, having multiple outstanding NOTIFYs is probably 
> > > > manageable. For partial state documents, at least as they are 
> > > > specified here, it could be disastrous. Consider four notifies 
> > > > N1(full), N2(partial), N3(full), N4(partial). If the recipient 
> > > > receives only N1 and N4 (something prevents N2 and N3 
> from being 
> > > > delivered or simply delays them (packetloss over UDP for 
> > > > example)), it will apply the delta in N4 to the wrong 
> full state 
> > > > document (N1 instead of N3).
> > > 
> > How does version help here? The recipient has seen exactly two 
> > documents, the first with version=0 (which happens to be 
> N1) and the 
> > second has version=1 (which happens to be N4). The recipient has no 
> > way to know it missed N2 and N3.
> >

---

From: [email-masked]
Date: Tue, 27 Apr 2004 12:36:42 +0300

/Hisham

---

From: [email-masked]
Date: Tue, 27 Apr 2004 13:29:46 +0300

- Mikko

---

From: [email-masked]
Date: Thu, 29 Apr 2004 15:02:51 +0300

Hi,

I would like to hear what others think about this proposal. Especially,
if you think it will not work in some situations.
If this works and we choose to adopt the proposed solution where are
probably some other consequences. At a moment PA MUST keep tuple ids
consistent between two "full" state documents. Now, if the version cycle
will be tied to the subscription PA/UA must apply a bit different logic
how tuple ids and "version" numbers are generated. My proposal in this
case would be to also keep tuple ids consistent within a subscription.

- Mikko

---

From: [email-masked]
Date: Thu, 29 Apr 2004 15:02:51 +0300

Hi,

- Mikko

---

From: [email-masked]
Date: Thu, 29 Apr 2004 15:33:12 +0300

Why does that matter? If it is full state, the tuple ids can remain the
same or be different. A full state NOTIFY replaces the whole state at
the subscriber side anyway. The only requirement now is that the
subscriber must ensure the next NOTIFY (carrying partial or full state)
only has the version increased by 1. If it is increased by more than 1,
then something was lost.

/Hisham

> Sent: 29.April.2004 15:03
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); [email-masked];
> [email-masked]
> I would like to hear what others think about this proposal. 
> Especially, if you think it will not work in some situations.
> If this works and we choose to adopt the proposed solution 
> where are probably some other consequences. At a moment PA 
> MUST keep tuple ids consistent between two "full" state 
> documents. Now, if the version cycle will be tied to the 
> subscription PA/UA must apply a bit different logic how tuple 
> ids and "version" numbers are generated. My proposal in this

---

From: [email-masked]
Date: Thu, 29 Apr 2004 15:40:11 +0300

<snip>

> Now that I think about this a little more, I think the 
> version should forever increase for the whole duration of the 
> subscription, including refreshes. Imagine this scenario:
> 
> ----> SUBSCRIBE
> <---- 200
> <---- NOTIFY1 (full, version 0)
> ----> 200
>   X-- NOTIFY2 (full, version 1)
> <---- NOTIFY3 (partial, version 3)
> ----> 200
> ----> SUBSCRIBE
> <---- 200
> <---- NOTIFY4 (full, version 0)
> ----> 200
> <--x  NOTIFY2 (full, version 1) Now NOTIFY2 arrives
> 
> How does the subscribe know that the last NOTIFY (NOTIFY2) 
> was sent after the subscribe refresh? If NOTIFY 4 had version 
> 4 instead of 0, then it would.
> 
> /Hisham

If we don't allow new NOTIFY messages if there is a pending NOTIFY is
this still a problem?

- Mikko

---

From: [email-masked]
Date: Thu, 29 Apr 2004 15:46:30 +0300

> 
> 
> Why does that matter? If it is full state, the tuple ids can 
> remain the same or be different. A full state NOTIFY replaces 
> the whole state at the subscriber side anyway. The only 
> requirement now is that the subscriber must ensure the next 
> NOTIFY (carrying partial or full state) only has the version 
> increased by 1. If it is increased by more than 1, then 
> something was lost.
>
> /Hisham

Well, its not that big thing but you end up having two separate
'lifecycles' for different elements within a single document. I was
think that from implementation perspective it might be easier to have
just one. But in any case I think you are right that these are two
separate things.

- Mikko 
 
> [email-masked];
> > > > I believe the original need for the "state" was that 
> the "version" 
> > > > could be initialized to some random value. Now, if "version" is 
> > > > always initialized to 0 there is no need for the "state" 
> > > > attribute. Both solutions should work and if nobody 
> else comments 
> > > > otherwise I will remove the "state" attribute.
> > > > 
> > > > > 3265 or simple-presence prohibit overlapping NOTIFYs. 
> For full 
> > > > > state documents, having multiple outstanding NOTIFYs 
> is probably 
> > > > Actually it wouldn't because of "version" handling. Section 4.5 
> > > > applies here. But in any case this kind of behavior is quite bad
> > as it might
> > > > This is a good point. Your proposed solution should 
> work. This may 
> > > > cause some extra implementation effort for PA but I 
> cannot see any
> > > > way around
> > > > > - if we allow this, then we need to explicitly state 
> this as why 
> > > > > the above is SHOULD, not MUST. However, I think this 
> should be a 
> > > > > MUST.)
> > > > 
> > > > > Just below that, there's a "SHOULD discard the 
> document" if it 
> > > > > gets a partial notification with a lower version 
> number. I don't 
> > > > > see how this is right at all, and suggest that this 
> MUST trigger 
> > > > > a refresh or termination instead. (We wouldn't get to 
> this logic 
> > > > > if a NOTIFY was reordered and arrived late
> > > [email-masked] https://www1.ietf.org/mailman/listinfo/simple
> > 
> >

---

From: [email-masked]
Date: Thu, 29 Apr 2004 15:33:12 +0300

/Hisham

---

From: [email-masked]
Date: Thu, 29 Apr 2004 15:36:54 +0300

> ext [email-masked]
> Sent: 27.April.2004 13:05
> To: Lonnfors Mikko (Nokia-NRC/Helsinki); [email-masked];
> [email-masked]

Now that I think about this a little more, I think the version should forever increase for the whole duration of the subscription, including refreshes. Imagine this scenario:

----> SUBSCRIBE
<---- 200

How does the subscribe know that the last NOTIFY (NOTIFY2) was sent after the subscribe refresh? If NOTIFY 4 had version 4 instead of 0, then it would.

/Hisham

---

From: [email-masked]
Date: Thu, 29 Apr 2004 15:40:11 +0300

<snip>

- Mikko

---

From: [email-masked]
Date: Thu, 29 Apr 2004 15:44:25 +0300

> Sent: 29.April.2004 15:40
> If we don't allow new NOTIFY messages if there is a pending 
> NOTIFY is this still a problem?

This would fix the problem, but I prefer not to disallow it since
RFC3265 does not disallow it nor presence-07.

I believe increasing the version for the duration of the subscription
would fix this.

/Hisham

---

From: [email-masked]
Date: Thu, 29 Apr 2004 15:46:30 +0300

- Mikko

---

From: [email-masked]
Date: Fri, 30 Apr 2004 09:27:19 +0300

Ok, I also agree that overlapping partial NOTIFYs complicate things without benefit. I also would like to propose explicitly disallowing overlapping full state and partial. I.e. A notifier must not issue a partial state NOTIFY without first receiving the 200 for a full state NOTIFY. I believe the converse is also required: the notifier must not issue a full state NOTIFY before it receives a 200 for a partial state NOTIFY.

With all there restrictions, we can do without the version attribute.

Regards,
Hisham

> From: ext Paul Kyzivat [mailto:[email-masked]]
> Sent: 29.April.2004 21:47
> To: Robert Sparks
> Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); Lonnfors Mikko
> (Nokia-NRC/Helsinki); [email-masked]
> Robert Sparks wrote:
> > Aside from that I'd like for you to think through this again
> > from viewpoints besides active attack (use a transient malfunction
> > of the application (above the layer that would screw up basic SIP)),
> > I'm ready to let this go as long as we have _a_ solid solution to
> > dealing with reordered/missing notifies.
> 
> I'm not going to start down the path to speculation about how 
> to recover 
> from arbitrary malfunctions of an application. That is just plain 
> impossible without some characterization of the kinds of malfunctions 
> that are to be recovered from.
> 
> > So, backing out a layer, lets look at my original question of
> > whether or not we allow overlapping ->partial<- NOTIFYs at all
> > in this case.
> 
> I don't see any compelling need to support overlapping 
> partial notifies. 
> It is very difficult to see how to make them work.
> 
> I can imagine a case where there might be some motivation: I sent one 
> notification and have had no response. But I already have a bunch of 
> additional changes that you should know about. It might be 
> advantageous 
> to start sending them as soon as possible. But until you know 
> the prior 
> one has been handled it isn't safe to send the new one.
> 
> > Why would you want to? What value would doing that bring? 
> > 
> > 3261 and even presence-10 left sending full-state presence
> > NOTIFYs open. We wouldn't be changing that. If an application
> > for some reason decided it needed to send a new full-state
> > notify while a partial-state notify was pending, it could.
> > So any of the arguments for allowing it from the 3261/presence-10
> > are still satisfied. Can you see any use case where allowing
> > a server to send overlapping partial NOTIFYs is a good idea?
> > If not, disallowing it seems a powerful simplification.
> >
> 
> I agree.
> 
> 	Paul
> 
>

---

From: Schmidt Christian <[email-masked]>
Date: Fri, 30 Apr 2004 13:27:42 +0200

Hi Hisham,

this proposal would not solve the problem with a missing NOTIFY (full or partial). 

What´s about the following proposal:
The notifier must not issue a NOTIFY (full or partial), before it receives a 200 for the last issued NOTIFY (full or partial). After experation of a timer t, the notifier should send a full NOTIFY.

This would also work without version number and would cover reordering and packet loss cases.

Regards,
Christian

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von [email-masked]
Gesendet: Freitag, 30. April 2004 08:27
An: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Betreff: RE: [Simple] WGLC: partial notification

Regards,
Hisham

---

From: Schmidt Christian <[email-masked]>
Date: Fri, 30 Apr 2004 13:37:56 +0200

Redundancy:

(1) In draft-ietf-simple-partial-pidf-format-01.txt, section 3.3 there is a statement:
"<removed> element MUST NOT be included if "state" attribute has value "full".

(2) In draft-ietf-simple-partial-notify-02.txt, section 4.5, there is a description,
how a watcher has to react on a full NOTIFY with a <removed> element included.

because of (1), case (2) never can happen. For simplicity, I propose to delete (2).

Regards,
Christian Schmidt

---

From: Schmidt Christian <[email-masked]>
Date: Fri, 30 Apr 2004 13:37:56 +0200

Redundancy:

Regards,
Christian Schmidt

---

From: Schmidt Christian <[email-masked]>
Date: Fri, 30 Apr 2004 14:58:22 +0200

Hi Paul,

thank you for the comment. Concerning the tunnel case, it is a question, how often this would
happen. If it is a rare case, perhaps we can ignore it. If not, we can add a repetition option.

Modified proposal:
The notifier must not issue a NOTIFY (full or partial), before it receives a 200 for the last issued NOTIFY (full or partial). After experation of a timer t, the notifier should repeat the last message and if the timer t expires a second time, send a full NOTIFY.

Regards,
Christian

-----Ursprüngliche Nachricht-----
Von: Paul Kyzivat [mailto:[email-masked]] 
Gesendet: Freitag, 30. April 2004 14:48
An: Schmidt Christian
Cc: [email-masked]'; [email-masked]; [email-masked]; [email-masked]
Betreff: Re: AW: [Simple] WGLC: partial notification

> This would also work without version number and would cover reordering and packet loss cases.

This would work. I guess it is obvious that if the full notify also 
times out then further retries, if any, should also send full state. And 
that this should continue until there is success. A notify with partial 
state could only happen after receiving a 2xx for the prior notify.

OTOH, this might be a bad choice for a bandwidth constrained device, 
like a cell phone. If you are driving thru a tunnel and can't receive 
for a few minutes, are going to be happy to get a full update when you 
emerge?

	Paul

---

From: Schmidt Christian <[email-masked]>
Date: Fri, 30 Apr 2004 15:41:38 +0200

Hi Paul,

I´m working on mobile networks and contacted some of our radio experts. Traffic models in this area are quite difficult to get. But here some ideas:
- Situations, where connections are lost for several minutes are very rare (Some tunnels in Austria).
- Tunnel situations are usually more in a few 10s of seconds.
- For a lost INVITE, INVITE and connection lost situation have to be in the same period and seams to be at least rare.
Perhaps that could help.

Regards,
Christian

-----Ursprüngliche Nachricht-----
Von: Paul Kyzivat [mailto:[email-masked]] 
Gesendet: Freitag, 30. April 2004 15:25
An: Schmidt Christian
Cc: [email-masked]'; [email-masked]; [email-masked]; [email-masked]
Betreff: Re: AW: AW: [Simple] WGLC: partial notification

I'd like to hear what the cellular guys think of this. (Are you one of 
them?)

	Paul

---

From: Schmidt Christian <[email-masked]>
Date: Fri, 30 Apr 2004 15:41:38 +0200

Hi Paul,

Regards,
Christian

-----Ursprüngliche Nachricht-----
Von: Paul Kyzivat [mailto:[email-masked]] 
Gesendet: Freitag, 30. April 2004 15:25
An: Schmidt Christian
Cc: [email-masked]'; [email-masked]; [email-masked]; [email-masked]
Betreff: Re: AW: AW: [Simple] WGLC: partial notification

	Paul