attachment


<br><font size=2 face="sans-serif">This was supposed to be a straightforward, optional, redirect. It was, at one time, cleanly specified. Why do the only choices seem to be reinvent or remove?<br>
---------------------------------------------- <br>
Harry Lewis <br>
IBM Printing Systems <br>
---------------------------------------------- </font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>&quot;Carl&quot; &lt;carl@manros.com&gt;</b></font>
<br><font size=1 face="sans-serif">Sent by: owner-ipp@pwg.org</font>
<p><font size=1 face="sans-serif">08/27/2002 04:45 PM</font>
<br>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;&quot;Hastings, Tom N&quot; &lt;hastings@cp10.es.xerox.com&gt;, &quot;Robert Herriot&quot; &lt;bob@herriot.com&gt;, Harry Lewis/Boulder/IBM@IBMUS</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;&lt;ipp@pwg.org&gt;, &lt;ifx@pwg.org&gt;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;RE: IPP&gt; Re: IFX&gt; Attempt to close on the two Notification specs at the face to face meetings</font>
<br>
<br><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp;</font></table>
<br>
<br><font size=2 face="Courier New">Tom,<br>
<br>
It looks like we are saying the same thing on my point 1). It doesn't need<br>
to be mentioned at all in the spec. It is a pure implementation matter, but<br>
as Carl Kugler pointed out, it may not be a feasible solution anyway.<br>
<br>
On point 2) I don't think you misunderstood the problem I brought up, viz<br>
what protocol you are using between an IPP Client and a Notification Server.<br>
I don't think we should include a new parameter, which assumes the use of<br>
some non-existent new protocol, even if that happens to be a subset of IPP.<br>
I believe that you are still thinking only about the protocol between an IPP<br>
Client and an IPP Printer in your comment?<br>
<br>
Carl-Uno<br>
<br>
Carl-Uno Manros<br>
10701 S Eastern Ave #1117<br>
Henderson, NV 89052, USA<br>
Tel +1-702-617-9414<br>
Fax +1-702-617-9417<br>
Mob +1-702-525-0727<br>
Email carl@manros.com<br>
<br>
&gt; -----Original Message-----<br>
&gt; From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]<br>
&gt; Sent: Tuesday, August 27, 2002 1:35 PM<br>
&gt; To: Carl; Robert Herriot; Lewis, Harry<br>
&gt; Cc: ipp@pwg.org; ifx@pwg.org<br>
&gt; Subject: RE: IPP&gt; Re: IFX&gt; Attempt to close on the two Notification<br>
&gt; specs at the face to face meetings<br>
&gt;<br>
&gt;<br>
&gt; Carl-Uno,<br>
&gt;<br>
&gt; See my comments below, bracketed with &lt;th&gt; and &lt;/th&gt;<br>
&gt;<br>
&gt; Tom<br>
&gt;<br>
&gt; -----Original Message-----<br>
&gt; From: Carl [mailto:carl@manros.com]<br>
&gt; Sent: Tuesday, August 27, 2002 07:45<br>
&gt; To: Robert Herriot; Hastings, Tom N; ipp@pwg.org; ifx@pwg.org; Lewis,<br>
&gt; Harry<br>
&gt; Subject: RE: IPP&gt; Re: IFX&gt; Attempt to close on the two Notification<br>
&gt; specs at the face to face meetings<br>
&gt;<br>
&gt;<br>
&gt; Hi all,<br>
&gt;<br>
&gt; It seems we are about reinvent a totally new solution again at the stage<br>
&gt; where we are trying to finalize the IPPGET specification.<br>
&gt; &lt;th&gt;<br>
&gt; I disagree that the proposed solutions are a totally new solution. &nbsp;We are<br>
&gt; trying to tweak the specification so that we can get agreement.<br>
&gt; &lt;/th&gt;<br>
&gt;<br>
&gt; Of the proposals so far, I think that Bob's latest version is getting<br>
&gt; closest to a working solution.<br>
&gt;<br>
&gt; However, there are a couple of pitfalls that nobody has brought up yet:<br>
&gt;<br>
&gt; 1) If the notification server returns the notifications via the<br>
&gt; printer, it<br>
&gt; is totally transparent to the IPP protocol and there is no need for<br>
&gt; mentioning that functionalitty in the spec at all.<br>
&gt; &lt;th&gt;<br>
&gt; I don't understand why this is a pitfall. &nbsp;Yes, the client doesn't need to<br>
&gt; be aware of the URI being returned and can ignore it. &nbsp;That is<br>
&gt; the advantage<br>
&gt; of Bob's and my proposals to the client.<br>
&gt; &lt;/th&gt;<br>
&gt;<br>
&gt; 2) If you use the &quot;optimal-target-uri&quot; in Bob's termilogy, what protocol<br>
&gt; will you be using to get the notifications from the notification server?<br>
&gt; Obviously the notification server is unlikely to be a a full IPP<br>
&gt; Printer, so<br>
&gt; what protocol would you use? A new protocol which is subset of the IPP<br>
&gt; protocol, only supporting one or two operations?<br>
&gt; &lt;th&gt;</font>
<br><font size=2 face="Courier New">&gt; Yes, the URI has the scheme 'ipp:'. &nbsp;However, section 5.2.3 of the current<br>
&gt; IPPGET spec says (and we'll change the MUST to SHOULD or MAY):<br>
&gt;<br>
&gt; &quot;5.2.3 redirect-uri (uri)<br>
&gt; The value of this attribute is the uri that the Notification<br>
&gt; Recipient MUST<br>
&gt; use for a subsequent Get-Notifications operation.&quot;<br>
&gt;<br>
&gt; So the URI isn't used for other IPP operations, only for<br>
&gt; Get-Notifications.<br>
&gt; Do you see a problem with using the IPP URL for just the Get-Notifications<br>
&gt; operation?<br>
&gt; &lt;/th&gt;<br>
&gt;<br>
&gt;<br>
&gt; Considering the two issues above, I think that the smart thing to do is to<br>
&gt; drop the redirect aka optimize feature from the spec.<br>
&gt;<br>
&gt; Carl-Uno<br>
&gt;<br>
&gt; Carl-Uno Manros<br>
&gt; 10701 S Eastern Ave #1117<br>
&gt; Henderson, NV 89052, USA<br>
&gt; Tel +1-702-617-9414<br>
&gt; Fax +1-702-617-9417<br>
&gt; Mob +1-702-525-0727<br>
&gt; Email carl@manros.com<br>
&gt;<br>
&gt; &gt; -----Original Message-----<br>
&gt; &gt; From: owner-ipp@pwg.org [mailto:owner-ipp@pwg.org]On Behalf Of Robert<br>
&gt; &gt; Herriot<br>
&gt; &gt; Sent: Tuesday, August 27, 2002 2:15 AM<br>
&gt; &gt; To: Hastings, Tom N; ipp@pwg.org; ifx@pwg.org; Lewis, Harry<br>
&gt; &gt; Cc: pwg@pwg.org<br>
&gt; &gt; Subject: IPP&gt; Re: IFX&gt; Attempt to close on the two Notification specs at<br>
&gt; &gt; the face to face meetings<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; Tom,<br>
&gt; &gt;<br>
&gt; &gt; If we agree that we must keep the redirection notion, then I<br>
&gt; &gt; agree (mostly)<br>
&gt; &gt; with your proposed changes, but not with your reasoning.<br>
&gt; However, I still<br>
&gt; &gt; think that most clients will not implement redirection, so<br>
&gt; &gt; redirection ends<br>
&gt; &gt; up being effectively proprietary and thus not a concept that<br>
&gt; &gt; should be in a<br>
&gt; &gt; standard. &nbsp;Assuming that we will keep redirection, here are my<br>
&gt; thoughts on<br>
&gt; &gt; your proposal.<br>
&gt; &gt;<br>
&gt; &gt; You propose a possible implementation of a printer with a remote<br>
&gt; &gt; notification server and imply that the existence of this<br>
&gt; solution somehow<br>
&gt; &gt; changes the rules. &nbsp;This implementation may have led you to<br>
&gt; this solution,<br>
&gt; &gt; but it is not the essence of your proposal or important to it.<br>
&gt; &gt;<br>
&gt; &gt; The effect of what your proposed change is that a printer must directly<br>
&gt; &gt; support ipp-get if it supports event notification. That is, the cannot<br>
&gt; &gt; return nothing and redirect the client to the real notification<br>
&gt; &gt; server. Your<br>
&gt; &gt; proposal could have stopped there and said that the redirection uri is<br>
&gt; &gt; eliminated.<br>
&gt; &gt;<br>
&gt; &gt; Instead, you added an optional &quot;alternate-target-uri&quot; attribute, which I<br>
&gt; &gt; think should be called &quot;optimal-target-uri&quot; (as that is what it<br>
&gt; &gt; really is).<br>
&gt; &gt; The &quot;redirect-uri&quot; has the flaw that the client gets nothing if<br>
&gt; it doesn't<br>
&gt; &gt; implement &quot;redirect-uri&quot;. With &quot;optimal-target-uri&quot;, the client<br>
&gt; gets event<br>
&gt; &gt; notifications even if it doesn't implement &quot;optimal-target-uri&quot;. Its<br>
&gt; &gt; implementation is an optimization only -- but perhaps not sufficiently<br>
&gt; &gt; optimal to be worth the support of anyone. &nbsp;Once you realize, that<br>
&gt; &gt; &quot;optimal-target-uri&quot; is just an optimal uri, it need not be just<br>
&gt; &gt; some remote<br>
&gt; &gt; notification server. It could also be a different uri in the<br>
&gt; same printer.<br>
&gt; &gt; It doesn't really matter, but the presence of this attribute tells the<br>
&gt; &gt; client that there is a better uri to use. If you keep this attribute, I<br>
&gt; &gt; would leave the language open for the uri to be anywhere a<br>
&gt; &gt; printer wants it<br>
&gt; &gt; to be.<br>
&gt; &gt;<br>
&gt; &gt; I also think that in item 3, client support is a &quot;MAY&quot; rather than a<br>
&gt; &gt; &quot;SHOULD&quot;. &nbsp;It doesn't really matter whether a client supports this<br>
&gt; &gt; attribute, especially almost no one will implement it.<br>
&gt; &gt;<br>
&gt; &gt; I also would ask if the &quot;optimal-target-uri&quot; must be different from the<br>
&gt; &gt; printer-uri. That is, could it always be returned by a printer,<br>
&gt; &gt; even when it<br>
&gt; &gt; would be the same as the printer uri. &nbsp;I think that the intention<br>
&gt; &gt; is that a<br>
&gt; &gt; printer would only return it when there is an optimal uri that is<br>
&gt; &gt; different<br>
&gt; &gt; from the printer, but that it need not be different (i.e. the<br>
&gt; client need<br>
&gt; &gt; not check for this).<br>
&gt; &gt;<br>
&gt; &gt; Bob Herriot<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; ----- Original Message -----<br>
&gt; &gt; From: &quot;Hastings, Tom N&quot; &lt;hastings@cp10.es.xerox.com&gt;<br>
&gt; &gt; To: &lt;ipp@pwg.org&gt;; &lt;ifx@pwg.org&gt;; &quot;Lewis, Harry&quot; &lt;harryl@us.ibm.com&gt;<br>
&gt; &gt; Cc: &lt;pwg@pwg.org&gt;<br>
&gt; &gt; Sent: Monday, August 26, 2002 5:25 PM<br>
&gt; &gt; Subject: RE: IFX&gt; Attempt to close on the two Notification specs<br>
&gt; &gt; at the face<br>
&gt; &gt; to face meetings<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; &gt; Harry et al,<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; In answering Ira's note, a win-win approach occurred to me.<br>
&gt; &gt; This approach<br>
&gt; &gt; &gt; will allow a Printer to use a notification server, but won't put any<br>
&gt; &gt; burden<br>
&gt; &gt; &gt; on clients. &nbsp;I called Ira up and he is enthusiastic as well.<br>
&gt; &gt; He helped me<br>
&gt; &gt; &gt; flesh out the proposal. &nbsp;Here is the idea:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; When a Printer implements Get-Notifications using a<br>
&gt; Notification Server,<br>
&gt; &gt; why<br>
&gt; &gt; &gt; not have the Printer just pass each Get-Notifications request<br>
&gt; &gt; along to the<br>
&gt; &gt; &gt; Notification Server, which returns the response to the Printer which<br>
&gt; &gt; returns<br>
&gt; &gt; &gt; that response to the client. &nbsp;In protocol terminology, the Printer is<br>
&gt; &gt; &gt; &quot;relaying&quot; the Get-Notifications request to the notification<br>
&gt; &gt; server. &nbsp;Yes,<br>
&gt; &gt; &gt; this are 4 hops, instead of 2, but its transparent to the client. &nbsp;The<br>
&gt; &gt; &gt; Notification Server can return to the Printer the<br>
&gt; &gt; &quot;redirect-uri&quot; operation<br>
&gt; &gt; &gt; attribute as an advisory hint to the client (which the Printer<br>
&gt; &gt; passes back<br>
&gt; &gt; &gt; to the client) to improve the performance, but clients not<br>
&gt; knowing about<br>
&gt; &gt; &gt; that &quot;redirect-uri&quot; operation attribute would simply keep doing<br>
&gt; &gt; subsequent<br>
&gt; &gt; &gt; Get-Notifications to the Printer. &nbsp;The down side is that there are 4<br>
&gt; &gt; network<br>
&gt; &gt; &gt; hops, instead of 2, for the client that didn't take the hint and go<br>
&gt; &gt; directly<br>
&gt; &gt; &gt; to the Notification Server for subsequent Get-Notifications. &nbsp;In fact,<br>
&gt; &gt; with<br>
&gt; &gt; &gt; this approach we even eliminate the 'redirection-other-site'<br>
&gt; &gt; status code,<br>
&gt; &gt; &gt; since the Printer is REQUIRED to return an accurate and up to date<br>
&gt; &gt; &gt; Get-Notifications response on the first (and all subsequent)<br>
&gt; &gt; &gt; Get-Notifications returns (by relaying the request to the Notification<br>
&gt; &gt; &gt; Server).<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Is this a way forward for the IPPGET proposed standard?<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; So the changes to the IPPGET document would be as follows:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; 1. Delete the 'redirect-other-site' status code.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; 2. Clarify that the &quot;redirect-uri&quot; operation attribute in the<br>
&gt; &gt; &gt; Get-Notifications response is just a hint that the Printer returns to<br>
&gt; &gt; &gt; improve performance when the Printer is implemented using a<br>
&gt; notification<br>
&gt; &gt; &gt; server.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; 3. The client conformance section will say that the client<br>
&gt; &gt; SHOULD observe<br>
&gt; &gt; &gt; &quot;redirect-uri&quot; and try there (in order to improve performance by<br>
&gt; &gt; eliminating<br>
&gt; &gt; &gt; extra hops), but the client doesn't have to. &nbsp;When going to draft<br>
&gt; &gt; standard,<br>
&gt; &gt; &gt; if no one has implemented &quot;redirect-uri&quot;, we delete it from the<br>
&gt; &gt; standard.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; 4. In order not to get our feature confused with HTTP redirect, lets<br>
&gt; &gt; change<br>
&gt; &gt; &gt; the operation attribute returned from &quot;redirect-uri&quot; to<br>
&gt; &gt; &gt; &quot;alternate-target-uri&quot;, since the client can perform the<br>
&gt; &gt; Get-Notifications<br>
&gt; &gt; &gt; to either the original Printer or the notification server for those<br>
&gt; &gt; Printers<br>
&gt; &gt; &gt; that use a notification server. &nbsp;Our feature is really a<br>
&gt; &quot;relay&quot;, not a<br>
&gt; &gt; &gt; &quot;redirect&quot;.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Could this win-win proposal be discussed briefly during the<br>
&gt; PWG Plenary<br>
&gt; &gt; &gt; tomorrow (Tuesday, August 27) to see if we have consensus<br>
&gt; there (and we<br>
&gt; &gt; will<br>
&gt; &gt; &gt; discuss it on the mailing list to see if we have consensus there too)?<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Comments?<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Tom and Ira<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; P.S. In the future, if we want to generalize the relay<br>
&gt; &gt; mechanism for other<br>
&gt; &gt; &gt; operations, the same operation attribute can be returned in any<br>
&gt; &gt; response.<br>
&gt; &gt; &gt; For job operations, we probably would also need to return<br>
&gt; &gt; &gt; &quot;alternate-job-uri&quot; and &quot;alternate-job-id&quot; operation attributes in<br>
&gt; &gt; addition<br>
&gt; &gt; &gt; to the &quot;alternate-target-uri&quot; operation attribute.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; -----Original Message-----<br>
&gt; &gt; &gt; From: McDonald, Ira [mailto:imcdonald@sharplabs.com]<br>
&gt; &gt; &gt; Sent: Monday, August 26, 2002 14:26<br>
&gt; &gt; &gt; To: 'Hastings, Tom N'; ipp@pwg.org; ifx@pwg.org<br>
&gt; &gt; &gt; Cc: pwg@pwg.org<br>
&gt; &gt; &gt; Subject: RE: IFX&gt; Attempt to close on the two Notification<br>
&gt; specs at the<br>
&gt; &gt; &gt; fa ce to fac e meetings<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Hi Tom,<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; First - I agree that it would still be good to drop redirect<br>
&gt; from IPPGET<br>
&gt; &gt; &gt; and design it IN GENERAL for IPP (any operation response could return<br>
&gt; &gt; &gt; the redirect), including the fact that while it's nice for<br>
&gt; &gt; interoperability<br>
&gt; &gt; &gt; IPP Clients do NOT need to honor and follow redirects (any more than<br>
&gt; &gt; &gt; HTTP Clients need to do so - it's a matter of client policy).<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Second - if we publish IPPGET as a Proposed Std RFC (as you suggest)<br>
&gt; &gt; &gt; and LATER add redirect, we MUST recycle at Proposed Std RFC - it's<br>
&gt; &gt; &gt; illegal to add ANY new features when moving from Proposed Std to<br>
&gt; &gt; &gt; Draft Std status - only dropping existing features is legal.</font>
<br><font size=2 face="Courier New">&gt; &gt; &gt;<br>
&gt; &gt; &gt; Cheers,<br>
&gt; &gt; &gt; - Ira McDonald<br>
&gt; &gt; &gt; &nbsp; High North Inc<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; -----Original Message-----<br>
&gt; &gt; &gt; From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]<br>
&gt; &gt; &gt; Sent: Friday, August 23, 2002 10:54 PM<br>
&gt; &gt; &gt; To: ipp@pwg.org; ifx@pwg.org<br>
&gt; &gt; &gt; Cc: pwg@pwg.org<br>
&gt; &gt; &gt; Subject: IFX&gt; Attempt to close on the two Notification specs<br>
&gt; at the face<br>
&gt; &gt; &gt; to fac e meetings<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; The IPP WG Last Call period closed July 31 on the two IPP Notification<br>
&gt; &gt; specs<br>
&gt; &gt; &gt; that are required for IPP Notification:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; (1) IPP Event Notifications and Subscriptions<br>
&gt; &gt; &gt; &lt;draft-ietf-ipp-not-spec-09.txt&gt;<br>
&gt; &gt; &gt; (2) The 'ippget' Delivery Method for Event Notifications<br>
&gt; &gt; &gt; &lt;draft-ietf-ipp-notify-get-07.txt&gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; and Carl-Uno declared that (1) was approved, since there were<br>
&gt; &gt; no comments<br>
&gt; &gt; &gt; and that (2) achieved consensus to drop the redirection<br>
&gt; &gt; mechanism entirely<br>
&gt; &gt; &gt; from the IPPGET document.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; However, we have continued discussion about the merits and<br>
&gt; &gt; problems of the<br>
&gt; &gt; &gt; redirection mechanism because Harry Lewis has been the main<br>
&gt; objector to<br>
&gt; &gt; &gt; removing the redirection mechanism from IPPGET. &nbsp;As a result<br>
&gt; I have not<br>
&gt; &gt; yet<br>
&gt; &gt; &gt; produced a new version of the document and Carl-Uno has not forwarded<br>
&gt; &gt; either<br>
&gt; &gt; &gt; of the documents to Ned Freed, our Area Director.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &lt;...snip...&gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Process considerations:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Could we delete the redirection mechanism for now from<br>
&gt; IPPGET? &nbsp;Get our<br>
&gt; &gt; RFC<br>
&gt; &gt; &gt; published as a Proposed standard. &nbsp;Implement IPPGET and do<br>
&gt; &gt; interoperability<br>
&gt; &gt; &gt; testing. &nbsp;See if the burden in the Printer of supporting the<br>
&gt; &gt; IPPGET method<br>
&gt; &gt; &gt; justifies offloading it to a Notification Server using the redirect<br>
&gt; &gt; &gt; mechanism. &nbsp;If the implementation experience shows that its not<br>
&gt; &gt; much of a<br>
&gt; &gt; &gt; burden in the Printer we made the right decision to delete<br>
&gt; redirection.<br>
&gt; &gt; If<br>
&gt; &gt; &gt; implementation experience shows that having a Notification Server is<br>
&gt; &gt; &gt; important to off-load the Printer's support of the IPPGET<br>
&gt; &gt; method, then add<br>
&gt; &gt; &gt; the redirection back into the IPPGET spec before progressing<br>
&gt; &gt; the document<br>
&gt; &gt; to<br>
&gt; &gt; &gt; a Draft standard. &nbsp;Perhaps in the meantime, IBM can also implement the<br>
&gt; &gt; &gt; Notification Server and see if it is really a win and that the extra<br>
&gt; &gt; &gt; administrative effort is worth the benefit to simplifying the Printer<br>
&gt; &gt; &gt; implementation.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Comments?<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Tom<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &lt;...snip...&gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt;<br>
&gt;<br>
<br>
<br>
</font>
<br>
<br>