Subject: Re: [Sip] GRUU (was Whats wrong with Supported. (was: Alert-Info Idea)

From: "Andrew Allen" <[email-masked]>
Date: Fri, 4 Nov 2005 23:56:00 -0500

While I agree with the sentiments the fact is that pre-GRUU devices will not be able to signal that they don't support GRUU and will not even be aware that their URI is not a GRUU.

Therefore are we not forced to indicate that the URI is a GRUU so we can tell between those URIs that are GRUUs and those that may not be?
--------------------------
Andrew Allen
Manager Standards
Research In Motion Ltd
BlackBerry Mobile  +1 847 809 8636
http://www.rim.com/

Sent from my BlackBerry Wireless Handheld

-----Original Message-----
From: [email-masked]
To: Dean Willis
CC: Sip
Sent: Fri Nov 04 13:15:13 2005
Subject: RE: [Sip] GRUU (was Whats wrong with Supported. (was: Alert-Info Idea)

Very true. You can always try, fail, then take appropriate steps. I'm
just talking about short circuiting the failure. You don't know that a
GRUU will succeed, but you have a fairly high level of confidence that a
non-GRUU will fail. I really hope that this becomes the 1% case with 99%
of URIs are GRUUs. With that long term goal in mind, I'd prefer to
signal that something is not a GRUU rather than always have to signal
that it is one. 

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Friday, November 04, 2005 9:50 AM
To: Sean Olson
Cc: Jeroen van Bemmel; Sip
Subject: Re: [Sip] GRUU (was Whats wrong with Supported. (was:
Alert-Info Idea)

On Nov 3, 2005, at 6:57 PM, Sean Olson wrote:

> Well, if GRUU ==  Globally Routable UA URI, and you treat a URI as a 
> GRUU which does not have one of these properties, things will break. 
> If you care when things break, you would want to know in advance. This

> would apply to UAs, proxies, etc. You could make the argument that all

> URIs should be GRUUs so what you really want is a property that says a

> URI is *not* at a GRUU and assume all others are ;-)

So, exactly what do you do differently if you think something might not
be GRUU?

You've been given this URI. Don't you just have to try it and see if it
works, and if not then back off to some other behavior?

Remember, there's really no such thing as an absolutely universally
reachable URI. It might b a URI on the public internet that your corp
firewall has decided to block. It might just stop working between the
time you get it and the time you try to use it. The Net might partition
in between you. And so on.

--
Dean

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Dean Willis <[email-masked]>
Date: Sat, 05 Nov 2005 16:12:40 -0600

> Therefore are we not forced to indicate that the URI is a GRUU so we can tell between those URIs that are GRUUs and those that may not be?

That's just my argument. We lack a reasonable way to say a URI is a 
GRUU. Even if we absolutely knew it to be a GRUU, it might still fail 
for the usage. Old stuff will also never be able to indicate or know 
that a contact is or is not a GRUU.

So all we can ever do is try the contact, and if it works, it works, and 
if it doesn't, fall back to the AOR or give up.

cc-transfer and Sean indicate that if we know a contact is not a GRUU, 
we should proceed directly to the AOR without trying the contact.

But what if the contact is really reachable and would have worked if we 
had tried it? Aren't we shooting ourselves for no apparent reason?

For example, presume a jillion users in an enterprise.  Their 
contact-space is "gruu like" within their administrative domain, but 
they have a natting firewall between them and the real world. If you 
transfer a call within the domain, it works just fine using the Contact. 
Only when you transfer across the domain boundary does a GRUU become 
useful. Why do we want all of these transfers to proceed back through 
the gruu-routing proxy if they don't need to?

And how would they play in a P2P world? If given a Contact, do I need to 
use the full P2P search algorithm on that contact like I would on a GRUU 
or an AOR? I don't THINK so. Or maybe we do, in which the GRUU is really 
just a "parameter of the AOR", and we really should have been routing 
everything at the AOR instead of the Contact level all along.

Ok, I was just struck by an idea-pair. It'll sound crazier than most of 
my ideas (which says a lot), but I want to get it "out there" before it 
evaporates from my head. Feel free to laugh or ignore it, but there IS 
"something good" in there somewhere.

1) If instead of "proxy retargeting" things, we just pushed the new 
"handler URI" onto the route set ahead of the old target, we can clean 
up a lot of the insanity relating to retargeting. This gets back to the 
fundmental routing error in RFC 2543 that rewrote the request URI on 
every proxy hope. We sortof bandaid fixed this with loose routing, but 
it didn't go QUITE far enough. We can go a step further here: So far 
example, an INVITE may show up on my phone. By looking at the route-set, 
my phone can see that my AOR is the next hop. So, the phone lets me know 
I have a call. But if the next hop were, say, Jonathan's AOR, and my 
phone know's I'm authorized to take calls for Jonathan, my phone tells 
me that Jonathan has a call. On the other hand, say an INVITE lands on 
my proxy, and there's no next-hop on the route. The proxy then just adds 
my phone's URI (note I don't say "contact") to the route-set in front of 
my  AOR, and sends the INVITE on.

Visualizing this, a "minimal" route set on an initial request might look 
like "<domain>,<identity>" where "domain" points to my proxy. The proxy 
applies "contact" routing by transfoirming this to "<phone>,<identity>'. 
See how the TARGET never changes -- just the steps between "here" and 
the "target" change. There is NO RETARGETING, just the insertion of 
additional steps "in between".

2) If something needs to refer to a particular "contact" or "delegate" 
or whatever we want to call it relative to an AOR (what we more or less 
do with GRUU), we invert this logic by having a target that explicitly 
"hangs off of" an AOR. Effectively, a route-triple. My proxy acts on 
this simply by deleting itself from the route-set and passing the 
request on.

So if my phone knows it is hiding behind a "GRUU proxy" and that some 
particular request (for example, a transfer, needs to reach THIS PHONE, 
it doesn't hand you a "<domain>,<identity>" route set, it instead uses a 
"<domain>,<delegate><,<identity>" set. Or, my proxy could perform this 
manipulation on behalf of my phone.

Putting this into practice: Extend "Contact:" and similar fields to take 
a route vector instead of a single URI.

Side effect: This seems to fix the fundamental problem of Service-Route 
(which is currently defined on a per-AOR, rather than per-Contact) basis.

--
Dean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 06 Nov 2005 16:30:05 -0500

I still don't believe its needed.

The reason is, that in places where a GRUU appears along with an 
alternate choice (i.e., a contact), you have the Supported header field 
telling you whether it is or not. In places where a GRUU appears solo 
(like a web page or in a Refer-To header field), you don't really have 
another choice but to just use it, so what is the point in signaling 
that it is or isnt a gruu?

The point is, the contents of Refer-To, Contact and so on are SUPPOSED 
to have the gruu property to begin with; the problem is we never had a 
way for that to be an easily guaranteed property.

-Jonathan R.

Andrew Allen wrote:

> While I agree with the sentiments the fact is that pre-GRUU devices
> will not be able to signal that they don't support GRUU and will not
> even be aware that their URI is not a GRUU.
> 
> Therefore are we not forced to indicate that the URI is a GRUU so we
> can tell between those URIs that are GRUUs and those that may not be?
>  -------------------------- Andrew Allen Manager Standards Research
> In Motion Ltd BlackBerry Mobile  +1 847 809 8636 http://www.rim.com/
> 
> -----Original Message----- From: [email-masked] To: Dean Willis
>  CC: Sip Sent: Fri Nov 04 13:15:13 2005 Subject: RE: [Sip] GRUU (was
> Whats wrong with Supported. (was: Alert-Info Idea)
> 
>  just talking about short circuiting the failure. You don't know that
> a GRUU will succeed, but you have a fairly high level of confidence
> that a non-GRUU will fail. I really hope that this becomes the 1%
> case with 99% of URIs are GRUUs. With that long term goal in mind,
> I'd prefer to signal that something is not a GRUU rather than always
> have to signal that it is one.
> 
> -----Original Message----- From: Dean Willis
> [mailto:[email-masked]] Sent: Friday, November 04, 2005
> 9:50 AM To: Sean Olson Cc: Jeroen van Bemmel; Sip Subject: Re: [Sip]
> GRUU (was Whats wrong with Supported. (was: Alert-Info Idea)
> 
> 
>> Well, if GRUU ==  Globally Routable UA URI, and you treat a URI as
>> a GRUU which does not have one of these properties, things will
>> break. If you care when things break, you would want to know in
>> advance. This
> 
> 
> So, exactly what do you do differently if you think something might
> not be GRUU?
> 
> You've been given this URI. Don't you just have to try it and see if
> it works, and if not then back off to some other behavior?
> 
>  firewall has decided to block. It might just stop working between
> the time you get it and the time you try to use it. The Net might
> partition in between you. And so on.
> 
> -- Dean
> 
> 
> _______________________________________________ Sip mailing list
> https://www1.ietf.org/mailman/listinfo/sip This list is for NEW
> development of the core SIP Protocol Use
> [email-masked] for questions on current sip Use
> [email-masked] for new developments on the application of sip
> 
> 
> 
>  This transmission (including any attachments) may contain
> confidential information, privileged material (including material
> protected by the solicitor-client or other applicable privileges), or
> constitute non-public information. Any use of this information by
> anyone other than the intended recipient is prohibited. If you have
> received this transmission in error, please immediately reply to the
> sender and delete this information from your system. Use,
> dissemination, distribution, or reproduction of this transmission by
> unintended recipients is not authorized and may be unlawful.
> 
> _______________________________________________ Sip mailing list
> https://www1.ietf.org/mailman/listinfo/sip This list is for NEW
> development of the core SIP Protocol Use
> [email-masked] for questions on current sip Use
> [email-masked] for new developments on the application of sip
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 06 Nov 2005 16:38:45 -0500

inline.

> the gruu-routing proxy if they don't need to?

The gruu draft acknowledges that direct signaling is lost with gruu, and 
that this would be revisited at some point in the future.

> it didn't go QUITE far enough.

Wow - shocking timing here - I more or less posted this same idea on the 
plane ride out here, prior to reading your note. I shudder at the 
thought that Dean and I are thinking alike... next thing you know I'll 
want to deprecate forking....

> We can go a step further here: So far 
> my phone can see that my AOR is the next hop.

I think the AOR would be in the requeust-URI.

> So, the phone lets me know 

I think it adds your contact URI as a Route value, but the AOR wouldn't 
be there. The R-URI remains as the identifier of the target. The route 
set tells you how to get there, including the endpoint itself.

> additional steps "in between".

I think the way it works is that an initial request is like:

INVITE AOR

and then every time a next hop needs to be reached, its added as a route 
header field value, including the endpoint contact itself.

> this simply by deleting itself from the route-set and passing the 

No, that I disagree with. One of the things we discussed early on in the 
design of gruu was simulating the effect with embedded Route headers, 
basically what you are describing it. We discarded that, because you 
want to apply service treatment and other logic to the GRUU, and to do 
that you really need it to be a separate resource.

I think the issue of gruu is orthogonal to this idea of putting the 
endpoint hop in a route header. So, if I send a request to a gruu, and 
that gruu is bound to contact sip:ua-contact, the initial INVITE would 
look like:

INVITE sip:gruu

and then this arrives at the proxy, which does this:

INVITE sip:gruu
Route: sip:ua-contact

> (which is currently defined on a per-AOR, rather than per-Contact) basis.

Err, you lost me there. Service route (and Path) remain broken AFAICT...

-Jonathan R.

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sun, 6 Nov 2005 23:12:06 +0100

Jonathan,

What about a PIDF document with one or more contact elements and a pres: 
URI?
Similar to the example in section 6.3 of draft-ietf-sipping-cc-transfer-05 
that Paul mentioned, there is a choice (both amongst contacts and between 
contact / pres: URI if the contact is not a GRUU)

Regards,
Jeroen

----- Original Message ----- 
From: "Jonathan Rosenberg" <[email-masked]>
To: "Andrew Allen" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Sunday, November 06, 2005 10:30 PM
Subject: Re: [Sip] GRUU (was Whats wrong with Supported. (was: Alert-Info 
Idea)

> The reason is, that in places where a GRUU appears along with an alternate 
> choice (i.e., a contact), you have the Supported header field telling you 
> whether it is or not. In places where a GRUU appears solo (like a web page 
> or in a Refer-To header field), you don't really have another choice but 
> to just use it, so what is the point in signaling that it is or isnt a 
> gruu?
>
> The point is, the contents of Refer-To, Contact and so on are SUPPOSED to 
> have the gruu property to begin with; the problem is we never had a way 
> for that to be an easily guaranteed property.
>
> -Jonathan R.
>
> Andrew Allen wrote:
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 07 Nov 2005 09:55:29 -0500

But again, what choice do you have? You can use the <contact> in the 
pidf document to reach that service, and thats it. There isn't going to 
be an alternate URI for that service that you could try.

-Jonathan R.

Jeroen van Bemmel wrote:

> Similar to the example in section 6.3 of 
> draft-ietf-sipping-cc-transfer-05 that Paul mentioned, there is a choice 
> (both amongst contacts and between contact / pres: URI if the contact is 
> not a GRUU)
> 
> Regards,
> Jeroen
> 
> ----- Original Message ----- From: "Jonathan Rosenberg" <[email-masked]>
>> alternate choice (i.e., a contact), you have the Supported header 
>> field telling you whether it is or not. In places where a GRUU appears 
>> solo (like a web page or in a Refer-To header field), you don't really 
>> have another choice but to just use it, so what is the point in 
>> signaling that it is or isnt a gruu?
>>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 07 Nov 2005 09:58:04 -0500

Sorry I replied without having correctly understood your response.

The pres URI is not going to be suitable for reaching the service, since 
its not a service URI at all. Its an identifier for the presentity. You 
might try different services, sure, but those don't represent an 
alternative for reaching the service you have chosen. If you knew that 
the <contact> for some service wasn't a gruu, would that mean you'd give 
up and use a different service entirely? No. You'd try the service you 
want, and if it can't be reached (timeout or whatever), you'd then try 
something else. No need to know whether the <contact> is a gruu or not.

-Jonathan R.

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Mon, 7 Nov 2005 20:51:57 +0100

I was thinking about a PIDF document with 2 contact entries, one for an 
older device that does not support GRUUs (and published a non-GRUU) and one 
for a newer one. Sure, you can always use trial-and-error, which is what 
current implementations will do anyway. Having a GRUU-indication would make 
little - but not 0 - difference

What bothers me is not if GRUUs are recognisable or not, but more the 
inconsistency of doing it in some cases (dialog-creating requests and 
responses) and not in others.

The current Supported: mechanism is mixing two things - support for GRUUs 
and their usage. What if the UAC does not manage to obtain a GRUU, e.g. 
because the registrar does not support it? Then it could not insert a 
Supported header anymore, because that would be interpreted as Contact=GRUU. 
So from the other side the UAC seems to have lost support for GRUUs?

----- Original Message ----- 
From: "Jonathan Rosenberg" <[email-masked]>
To: "Jeroen van Bemmel" <[email-masked]>
Cc: "Andrew Allen" <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Sent: Monday, November 07, 2005 3:58 PM
Subject: Re: [Sip] GRUU (was Whats wrong with Supported.

> alternative for reaching the service you have chosen. If you knew that the 
> <contact> for some service wasn't a gruu, would that mean you'd give up 
> and use a different service entirely? No. You'd try the service you want, 
> and if it can't be reached (timeout or whatever), you'd then try something 
> else. No need to know whether the <contact> is a gruu or not.
>
> -Jonathan R.
>
> Jeroen van Bemmel wrote:
>
>> Jonathan,
>>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 07 Nov 2005 16:38:14 -0500

inline.

Jeroen van Bemmel wrote:

> older device that does not support GRUUs (and published a non-GRUU) and 
> one for a newer one. Sure, you can always use trial-and-error, which is 
> what current implementations will do anyway. Having a GRUU-indication 
> would make little - but not 0 - difference

Well, firstly to be clear, a "device" is not represented in a presence 
document through a SIP URI. If you are talking about a "service" (i.e., 
a <tuple>), I doubt that the element which constructs the presence 
document would do it with something that doesn't at least have the 
property that it works for recipients; typically if a GRUU is not there 
it would be an AOR.

> responses) and not in others.

Well, I tihnk the real problem is that, to date, folks have not included 
URI in Contact with the gruu property, and so implementations have had 
to resort to hacks. The GRUU spec makes the need for the hacks go away - 
things should work as they originally should have. So, it seems wrong to 
me to hard-code into the URI a flag which merely says that you don't 
need to do the hacks that you needed to do before.

> 
> The current Supported: mechanism is mixing two things - support for 
> GRUUs and their usage. What if the UAC does not manage to obtain a GRUU, 
> e.g. because the registrar does not support it? Then it could not insert 
> a Supported header anymore, because that would be interpreted as 
> Contact=GRUU. So from the other side the UAC seems to have lost support 
> for GRUUs?

Ah, now that is a good point.

If this happens, then there is a difference between the presence of the 
Supported header field and whether or not the contact is a gruu.

I would still argue against a specific URI parameter for this, however. 
We want to be moving AWAY from telling people to try various tricks to 
get a URI to work. It ought to just work - thats what gruu allows. As 
such, in the case above, I'd still argue that the right thing is to try 
the contact URI, as it may work anyway...

-Jonathan R.

---

From: Dean Willis <[email-masked]>
Date: Mon, 7 Nov 2005 16:31:53 -0600

> Err, you lost me there. Service route (and Path) remain broken  

1) if the Contact: actually included the entire route from the  
serving proxy to the UA, including the UA's URI, then Contact  
essentially does " Path".

2) If the contact: actually included the entire route from the UA to  
the serving proxy, it essentially does "Service-Route".

So if I register, and the registrar stores both #1 and #2 "Contacts"  
for my AOR, uses #1 contacts to "reach" my UA, and returns #2  
contacts in the 200 OK response for use by my UA, we need neither  
Path nor Service-Route.

--
Dean

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Mon, 7 Nov 2005 23:45:54 +0100

inline
----- Original Message ----- 
From: "Jonathan Rosenberg" <[email-masked]>
To: "Jeroen van Bemmel" <[email-masked]>
Cc: "Andrew Allen" <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Sent: Monday, November 07, 2005 10:38 PM
Subject: Re: [Sip] GRUU (was Whats wrong with Supported.

> document through a SIP URI. If you are talking about a "service" (i.e., a 
> <tuple>), I doubt that the element which constructs the presence document 
> would do it with something that doesn't at least have the property that it 
> works for recipients; typically if a GRUU is not there it would be an AOR.
>
>>
> URI in Contact with the gruu property, and so implementations have had to 
> resort to hacks. The GRUU spec makes the need for the hacks go away - 
> me to hard-code into the URI a flag which merely says that you don't need 
> to do the hacks that you needed to do before.
>
>
>>
>> Supported header anymore, because that would be interpreted as 
> I would still argue against a specific URI parameter for this, however. We 
> want to be moving AWAY from telling people to try various tricks to get a 
> URI to work. It ought to just work - thats what gruu allows. As such, in 
> the case above, I'd still argue that the right thing is to try the contact 
> URI, as it may work anyway...
>

OK, so in that case: what if we just let Supported: gruu mean what it says - 
that the UAC supports GRUUs, in the sense that it knows how to request them 
from a registrar and to use them as Contact when available. Supported would 
not be a guarantee that the Contact is a GRUU (but does make it more 
likely), its absence means that the Contact was not obtained from a 
registrar or provisioned administratively as a GRUU (but may still work).

A UAC MUST use a GRUU as Contact, that is when it is provided with one. It 
MUST insert Supported: gruu in all dialog-creating requests and responses 
(btw, in addition to 2xx responses to INVITE I think it should also be 
included in 1xx responses with a to-tag, in particular 100rel responses)

Implementations SHOULD assume that Contacts are GRUUs (and act accordingly), 
regardless of the presence or absence of a Supported: gruu header. In 
particular, the Refer-To example SHOULD use the Contact URI (this leaves 
some room for implementations to deviate, if they really see a need)

PS I like the suggestion of loose contact routing, as a side effect it would 
obviate the need for special handling of the 'grid' parameter

Jeroen

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 08 Nov 2005 14:15:01 -0500

inline

Jeroen van Bemmel wrote:

>> If this happens, then there is a difference between the presence of 
>> the Supported header field and whether or not the contact is a gruu.
>>
>> I would still argue against a specific URI parameter for this, 
>> however. We want to be moving AWAY from telling people to try various 
>> tricks to get a URI to work. It ought to just work - thats what gruu 
>> allows. As such, in the case above, I'd still argue that the right 
>> thing is to try the contact URI, as it may work anyway...
>>
> 
> OK, so in that case: what if we just let Supported: gruu mean what it 
> says - that the UAC supports GRUUs, in the sense that it knows how to 
> request them from a registrar and to use them as Contact when available. 
> Supported would not be a guarantee that the Contact is a GRUU (but does 
> make it more likely), its absence means that the Contact was not 
> obtained from a registrar or provisioned administratively as a GRUU (but 
> may still work).

Yes.

> 
> A UAC MUST use a GRUU as Contact, that is when it is provided with one. 
> It MUST insert Supported: gruu in all dialog-creating requests and 
> responses (btw, in addition to 2xx responses to INVITE I think it should 
> also be included in 1xx responses with a to-tag, in particular 100rel 
> responses)

Yes.

> 
> Implementations SHOULD assume that Contacts are GRUUs (and act 
> accordingly), regardless of the presence or absence of a Supported: gruu 
> header.

Well, here I would rather have the draft say that presence of Supported: 
gruu is a strong hint that the contact is a gruu, and that endpoints 
using such cotnacs for new requests will have a high likelihood of those 
working, and then leave it at that.

  In particular, the Refer-To example SHOULD use the Contact URI
> (this leaves some room for implementations to deviate, if they really 
> see a need)

I am thinking now that usage of the Contact for other things, like 
REFER, should not be the problem of the gruu spec..

> 
> PS I like the suggestion of loose contact routing, as a side effect it 
> would obviate the need for special handling of the 'grid' parameter

Yes, I realized that as well.

-Jonathan R.

---

From: "Dale R. Worley" <[email-masked]>
Date: Wed, 09 Nov 2005 14:31:14 -0500

> working, and then leave it at that.

Perhaps you could say something like this:

"The presence of Supported: gruu suggests a high likelihood that the
Contact is a GRUU, and so a UA using that Contact SHOULD proceed on the
assumption that it is a GRUU, until it has positive information that it
is not.  In particular, the UA should not utilize any mechanisms to work
around that the Contact is not a GRUU until it has determined that
utilizing it as a GRUU does not work."

That language:

1) makes all current networks conforming, regardless of "proprietary
hacks", because no element sends  Supported: gruu yet.

2) when "Supported: gruu" is present, bans proprietary hacks except as a
fall-back mechanism.

which seems to me to be a good combination.

Dale

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 10 Nov 2005 09:28:13 -0500

The text below seems fine to me. Hopefully we are concluded on this topic...

-Jonathan R.