Subject: [apps-discuss] "organization's top level domain"

From: Dave CROCKER <[email-masked]>
Date: Sun, 05 Sep 2010 08:58:04 -0700

Folks,

Howdy.

I'm looking for a nomenclature suggestion...

RFC 2142 user the phrase "organization's top level domain".  This refers to the 
string that is delegated to the organization and provides the root of any 
sub-tree to the DNS that they create.  Around the world and around the DNS, this 
'root' will have two or more fields, such as bbiw.net or ucl.ac.uk.

An erratum has been filed on the phrase.  I take it as being a result of "top 
level domain" becoming entrenched to mean only the right-most field of a domain 
name. The stuff that is delegated from the root of the DNS.

The problem is that I do not know of an alternative name to use, when referring 
to the string that is delegated to an organization.  (And, no, I don not 
consider "string that is delegated to a domain" to be a candidate.)

I can't even think of one to suggest.

So I'm asking you folks what you recommend.

Thanks.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: John C Klensin <[email-masked]>
Date: Sun, 05 Sep 2010 12:43:39 -0400

Dave,

I've occasionally used "enterprise primary domain" or
"organizational primary domain" in my writing, just to avoid the
use of "top-level".  I've also used some convolutions to
distinguish enterprise-managed domains from domains managed by
registries that serve many enterprises and that consist primary
or exclusively of delegation records and records needed to
support them, but that isn't quite the same thing and I've never
found crisp wording.  My recollection is that some folks in the
DNS community have used something like "all-delegation domains"
to refer to the next level up from what you are talking about,
but the term is not precisely accurate (given SOA records, glue,
etc.).

Also note that, if current ICANN plans continue, your "two or
more fields" requirement may soon be incorrect.  Under their
proposed model, nothing would prevent an organization that has
the needed operational capability and that is willing to spend
the money from acquiring a TLD and trying to put, e.g., MX
records in it.   The SMTP spec isn't happy about that idea, but
that is not a DNS issue and various specs that depend on SRV or
NAPTR records impose no such restrictions.   And, fwiw, one of
the few clear bits of DNS terminology (see below) is that what
you are referring to as a "field" is called a "label" and, as
far as I know, nothing else. 

I'd suggest raising this with the DNS Directorate (assuming it
is still functional) and/or the DNSOPS and DNSEXT WGs.  As you
probably know, there are periodic discussions about putting
together a document to specify and clarify all of the sloppy
terminology that surrounds the DNS --the question you ask is by
no measure the worse case.  I don't think the effort is going
anywhere, but perhaps someone is keeping a list of concepts that
need standard terminology and rigorous definitions some day. 

      john

--On Sunday, September 05, 2010 8:58 AM -0700 Dave CROCKER
<[email-masked]> wrote:

> RFC 2142 user the phrase "organization's top level domain".
> This refers to the string that is delegated to the
> organization and provides the root of any sub-tree to the DNS
> that they create.  Around the world and around the DNS, this
> An erratum has been filed on the phrase.  I take it as being a
> result of "top level domain" becoming entrenched to mean only
> the right-most field of a domain name. The stuff that is
> delegated from the root of the DNS.
> 
> The problem is that I do not know of an alternative name to
> use, when referring to the string that is delegated to an
> organization.  (And, no, I don not consider "string that is
> delegated to a domain" to be a candidate.)
>

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 5 Sep 2010 10:51:49 -0700

At 12:43 PM -0400 9/5/10, John C Klensin wrote:
>use of "top-level".

Both of those seem good to me, for that very reason.

--Paul Hoffman, Director
--VPN Consortium

---

From: Peter Koch <[email-masked]>
Date: Sun, 5 Sep 2010 20:23:54 +0200

Hi Dave, all,

> The problem is that I do not know of an alternative name to use, when 
> referring to the string that is delegated to an organization.  (And, no, I 

the text in the RFC doesn't meet today's terminology, but it also isn't
(any longer) a good fit for operational reality. There is no 1:1 mapping
between organisation and domain (at whatever level) and the hierarchy
in the domain name space doesn't necessarily meet or imply organisational
hierarchy.  Therefore, I think the best way to deal with the erratum is
to postpone it for an update of the RFC.

That said, there are some recommendations in there that were good ideas at the
time but are out of sync with today's practice or the IETF's scope of
influence (see section 3; also mail addresses at "ra.net" are no longer
deliverable).  I'd suggest to declare this RFC "Historic" and, assuming enough
interest and momentum, work towards a BCP that deals with those remaining
mailboxes which are of importance today.

-Peter

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 6 Sep 2010 12:47:26 +1000

Dave,

Another phrase could be an "organization's domain immediately below a public suffix", where a public suffix is defined by referring to http://publicsuffix.org/. That isn't a short catchy phrase, but at least the "public suffix" portion is well defined.

--
James Manger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave CROCKER
Sent: Monday, 6 September 2010 1:58 AM
To: Apps Discuss
Subject: [apps-discuss] "organization's top level domain"

Folks,

Howdy.

Thanks.

d/
--

   Dave Crocker

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 6 Sep 2010 09:52:08 -0400

> but the term is not precisely accurate (given SOA records, glue,

That's why we use the term "delegation-centric" as opposed to
"all-delegation".  Even a delegation-centric domain will likely have A
records, for glue.

> far as I know, nothing else. 

Yes.

> need standard terminology and rigorous definitions some day. 

We tried to do that, in dnsext, about the time that I was asked to
serve as co-chair.  Indeed, I think part of the reason for appointing
a co-chair and semi-reviving the WG was because of the potential work
represented by such an all-encompassing terminological effort.  The
effort went nowhere: of the various volunteers we had as co-editors,
almost none of them produced any text.  Neither did anyone else.  So I
think it won't happen.

(As an aside, If someone wants to take this on, I think it would be
worthwhile.  But the truth is that I think it can't be done by a
volunteer: it needs to be someone paid for a short while to focus on
this problem and to produce a meaningful set of initial drafts,
because it's an enormous task.)

As for Dave's problem: you could close one can of worms by opening
another.  Call it the "organization's root."  ;-) Seriously, I don't
believe there's a good term for this, and I'd be delighted if someone
offered one.  But keep in mind that you might face abuse of the term.
Peter Koch in particular gets quite annoyed when people talk about a
host being "in" a domain, especially when the search path is what's
used to determine that.  I'd be amazed if people didn't start using
any term for "part of the namespace tree delegated to the
organization" to stand in for "part of the namespace tree in which
organization's hosts live."

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 6 Sep 2010 09:55:04 -0400

> Another phrase could be an "organization's domain immediately below a public suffix", where a public suffix is defined by referring to http://publicsuffix.org/. That isn't a short catchy phrase, bu…

Please, no!  In my (quite ornery, on this topic) opinion, the list at
publicsuffix.org is a miserable hack that is doomed to failure and is
wrong in principle.  I've made that rant before, however, so I won't
repeat it here.  And even if you liked the publicsuffix stuff, it's
completely wrong for these purposes.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: John C Klensin <[email-masked]>
Date: Mon, 06 Sep 2010 12:09:18 -0400

--On Monday, September 06, 2010 9:52 AM -0400 Andrew Sullivan
<[email-masked]> wrote:

>...
> (As an aside, If someone wants to take this on, I think it
> would be worthwhile.  But the truth is that I think it can't
> be done by a volunteer: it needs to be someone paid for a
> short while to focus on this problem and to produce a
> meaningful set of initial drafts, because it's an enormous
> task.)

It seems to me that this is work that ICANN ought to be willing
to support because terminology confusion has the potential (and
some history) of causing their discussions about policy to
deteriorate into total confusion.  I understand that they are
pleading poverty whenever suggestions for work that might
actually improve their ability to make progress comes up, but
perhaps this would be a small enough exception in their
multi-million dollar budget to be possible.  Anyone know a
convenient Board member or two?

> As for Dave's problem: you could close one can of worms by
> opening another.  Call it the "organization's root."  ;-)
> Seriously, I don't believe there's a good term for this, and
> I'd be delighted if someone offered one.  But keep in mind
> that you might face abuse of the term. Peter Koch in
> particular gets quite annoyed when people talk about a host
> being "in" a domain, especially when the search path is what's
> used to determine that.  I'd be amazed if people didn't start
> using any term for "part of the namespace tree delegated to the
> organization" to stand in for "part of the namespace tree in
> which organization's hosts live."

And, of course, even that sort of concept/term is vastly
complicated by the existence of aliases in general and tree or
sub-tree aliases in particular.

While anything can be abused and probably will, any clear set of
definitions would probably be helpful even if they were all
debatable when compared with contemporary practice (which is all
over the map).

    john

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 07 Sep 2010 09:51:53 -0700

Folks,

The main challenge in selecting a term is that it both means what we want it to 
mean AND it is likely to get widely used.

"Organizational primary domain" invites an interpretation that it refers to one 
among a set of aliases, rather than the 'base' of an organization's name tree. 
By using the word 'primary', we have to ask what the average person would assume 
is meant by "secondary domain", and I doubt it would be taken to mean "one level 
down the tree".

On further reflection, I'm inclined to suggest:

     "Organization's delegated domain"

Thoughts?

d/

-- 

   Dave Crocker

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 7 Sep 2010 09:58:19 -0700

At 9:51 AM -0700 9/7/10, Dave CROCKER wrote:
>The main challenge in selecting a term is that it both means what we want it to mean AND it is likely to get widely used.
>
>"Organizational primary domain" invites an interpretation that it refers to one among a set of aliases, rather than the 'base' of an organization's name tree. By using the word 'primary', we have to ask what the average person would assume is meant by "secondary domain", and I doubt it would be taken to mean "one level down the tree".
>

+1

--Paul Hoffman, Director
--VPN Consortium

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 07 Sep 2010 10:00:50 -0700

> (any longer) a good fit for operational reality. There is no 1:1 mapping

My original query concerned a specific bit of nomenclature, to resolve an 
erratum.  I also think it worthwhile to try to establish common language for a 
construct the is important.

A larger discussion about the document is fine, but is quite independent of the 
original question.  Hence the new Subject.

> to postpone it for an update of the RFC.

My current thinking is that a document revision effort should have two parts. 
One is to define an IANA registry, so that incremental change is possible, going 
forward.  The second is to review the document's existing definitions and modify 
them based on community review.

If there is meaningful community interest, I'd be glad to pursue that.

> mailboxes which are of importance today.

I don't understand the reference to "scope of influence". I would have guessed 
it meant that you think we should not recommend best practice, but the end of 
your paragraph makes clear that you don't mean that.

d?

-- 

   Dave Crocker

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 7 Sep 2010 14:13:09 -0400

>     "Organization's delegated domain"

This has the conspicuous advantage that it is technically exactly
correct.  One teeny quibble: the discussion has suggested (at least to
me) that there is one such domain, whereas we know there may be (and
often is) more than one.  Any way to point out that there may well be
more than one, but that each one is effectively separate and managed
independently (modulo aliasing techniques like CNAME, DNAME, and
whatever the wild bunch over in DNSEXT comes up with next)?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: John C Klensin <[email-masked]>
Date: Tue, 07 Sep 2010 14:29:50 -0400

--On Tuesday, September 07, 2010 2:13 PM -0400 Andrew Sullivan
<[email-masked]> wrote:

> This has the conspicuous advantage that it is technically
> exactly correct.  One teeny quibble: the discussion has
> suggested (at least to me) that there is one such domain,
> whereas we know there may be (and often is) more than one.
> Any way to point out that there may well be more than one, but
> that each one is effectively separate and managed
> independently (modulo aliasing techniques like CNAME, DNAME,
> and whatever the wild bunch over in DNSEXT comes up with next)?

As long as you are sure that "delegated" won't run afoul of
assorted "variant" and/or "symmetric" theories.  And I'll let
you explain those to this lucky group.

There is another little trap, which is why I've often used
"enterprise" rather than "organization" and that is having
subsidiary organizations delegated by some primary one.  That
leads one to "primary organization's primary delegated...",
which hurts the head, but nothing is perfect.

    john

---

From: Peter Koch <[email-masked]>
Date: Tue, 7 Sep 2010 20:35:55 +0200

On Tue, Sep 07, 2010 at 02:13:09PM -0400, Andrew Sullivan wrote:

> correct.

except where it isn't, probably depending on the exact meaning of
"delegated".  There is at least one (larger) TLD where registered
domains may or may not be delegated. DNS data for those not delegated will be
maintained within the TLD zone.  In the DNS, delegation is about creating
zone boundaries, but the presence or absence of those boundaries is
no indication of administrative (in the broader, not technical sense)
boundaries.  

-Peter

---

From: Bob Wyman <[email-masked]>
Date: Tue, 7 Sep 2010 14:37:59 -0400

John C Klensin <[email-masked]> wrote:
> I've often used "enterprise" rather than "organization"

Have you considered the even more generic, while still correct, "entity"?
"Enterprise" too often implies too much about economic intent and
"organization" tends to exclude individuals. Entity encompasses all of these
cases.

bob wyman

On Tue, Sep 7, 2010 at 2:29 PM, John C Klensin <[email-masked]> wrote:

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 7 Sep 2010 14:42:12 -0400

> you explain those to this lucky group.

Oh, I am by no means sure of that.  But since we're still dealing with
the DNS and not some mystery-meat variation in which magic happens and
things that are different delegations are "the same" FSVO, I am
willing to leave those dogs to sleep.

> which hurts the head, but nothing is perfect.

Isn't that a different organization, once you have a new delegation?
After all, delegations are by definition administrative boundaries.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 7 Sep 2010 14:44:30 -0400

On Tue, Sep 07, 2010 at 08:35:55PM +0200, Peter Koch wrote:
> "delegated".

You mean that undelegated zones still qualify under this term?  Then
yes, you're right, the proposed term is wrong. 

Ugh.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: John C Klensin <[email-masked]>
Date: Tue, 07 Sep 2010 21:35:43 -0400

--On Tuesday, September 07, 2010 14:44 -0400 Andrew Sullivan
<[email-masked]> wrote:

>> except where it isn't, probably depending on the exact
>> meaning of "delegated".
> 
> You mean that undelegated zones still qualify under this term?
> Then yes, you're right, the proposed term is wrong. 

Sigh.  What I've been after (not necessarily exactly the same
thing Dave has been after) is a way to identify a domain that is
the first (highest-level) one to actually belong to an
organization/ enterprise/ entity, such that the entity can held
responsible for that domain and everything and anything below
it.  The presumption is that the next domain toward the root is
the responsibility of some entity that is in the business (or
service) of allocating names to multiple, mostly unrelated,
organizations/ enterprises/ entities.

In that context at least, "domains" and "subdomains" are defined
by label boundaries, not by delegation records, zone cuts, or
anything else that connects to how particular DNS subtrees are
structured administratively or operationally.  To make things
worse, when an enterprise (organization/ entity) domain exists
in this way, it may be delegated or not but, if it is delegated,
it may be delegated to an admin contact who is not directly
connected with the entity that has actual policy responsibility
for the domain.

It seems to me that we are trying to overlay that idea of policy
responsibility for a domain and its subdomains onto top of the
DNS concepts of delegation and authority wrt zones and zone
administration.  They just aren't going to mesh perfectly, no
matter what we do.  For example...

> Isn't that a different organization, once you have a new
> delegation? After all, delegations are by definition
> administrative boundaries.

But that certainly doesn't create a "different organization", at
least as long as it is possible for one organization to "own"
multiple domains in the same or different parts of the DNS tree.

The abstractions also get us.  For example, Bob Wyman wrote:

> Have you considered the even more generic, while still
> correct, "entity"? "Enterprise" too often implies too much
> about economic intent and "organization" tends to exclude
> individuals. Entity encompasses all of these cases.

But "entity" is so abstract and general that it can include both
subdivisions of "enterprise" or "organization" and much broader
units such as TLD registries or even governments (note, e.g.,
the terminology actually used in ISO 3166-1).

best,
   john

---

From: Tony Finch <[email-masked]>
Date: Wed, 8 Sep 2010 11:39:14 +0100

> This has the conspicuous advantage that it is technically exactly

Yes, it's pretty good.

However there are situations where an organization has a domain name but it is not delegated to them, e.g. departments or affiliated organizations whose DNS is managed by their parent organization but who manage some other services themselves.

So perhaps "organization's principal domain name(s)"?

Tony.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 8 Sep 2010 06:58:13 -0700

>yes, you're right, the proposed term is wrong.

I disagree. It is good enough. Peter's case, while real, is an edge case that is probably not even understood by people who think they control names in that zone.

Saying "we can't come up with a good term because someone has a business model that goes against it" is not productive.

--Paul Hoffman, Director
--VPN Consortium

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 8 Sep 2010 10:11:10 -0400

> I disagree. It is good enough. Peter's case, while real, is an edge case that is probably not even understood by people who think they control names in that zone.

It doesn't matter.  "Delegate" has a technical meaning in the DNS
context.  For a protocol as central to the Internet as DNS is, the
entire area is replete with sloppy terminology and bad definitions;
"delegate" is not one of those, and I am strongly opposed to
formalizing any term that appears to blur that clarity.  If zones that
are not actually delegated across a zone cut are included, then we
can't use the term "delegated".

> Saying "we can't come up with a good term because someone has a business model that goes against it" is not productive.

Using precise terms imprecisely isn't productive, either.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 09 Sep 2010 09:44:45 -0700

On 9/8/2010 3:39 AM, Tony Finch wrote:
> On 7 Sep 2010, at 19:13, Andrew Sullivan<[email-masked]>  wrote:
...
> However there are situations where an organization has a domain name but it
> is not delegated to them, e.g. departments or affiliated organizations whose
> DNS is managed by their parent organization but who manage some other
> services themselves.
>

On reviewing the thread, and noting the possible mismatch between the precise
technical meaning of 'delegate' versus the desire to note an organizational
boundary, I was gravitating toward's "organization's registered domain".
Sub-domains are registered, too, of course but I think the term is nonetheless
pretty clear.

However, 'registered' is another term of art and its use here therefore offers
some plausible chance of misunderstanding and/or mismatch.

I think Tony's suggestion is superior.  It has the multiple benefits of using a
term that is not already taken for DNS use and of having the right focus, IMO.

As for organization versus enterprise, at best the difference is likely to be
too subtle most people and at worst it will not work quite properly. Enterprise
is sometimes use to refer to geography (campus).  That's obscure, but I'd
suggest against inviting it.  It also tends to imply commercial enterprise,
whereas "organization" is fully neutral about business model.

So I vote for "organization's principal domain(s)".

I'd like to get +1/-1 responses from the rest of you, please...

d/

-- 

   Dave Crocker

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 9 Sep 2010 12:52:42 -0400

On Thu, Sep 09, 2010 at 09:44:45AM -0700, Dave CROCKER wrote:
>
> I think Tony's suggestion is superior.

I agree.  Use that.

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Tony Hansen <[email-masked]>
Date: Thu, 09 Sep 2010 12:53:51 -0400

+1

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 9 Sep 2010 09:54:04 -0700

>I'd like to get +1/-1 responses from the rest of you, please...

You're not going to like this, but -1 for a sad reason: the principal domain name for Example Corp. is www.example.com, not example.com.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 9 Sep 2010 10:04:21 -0700

> From: [email-masked] [mailto:apps-discuss-
> [email-masked]] On Behalf Of Tony Hansen
> Sent: Thursday, September 09, 2010 9:54 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [apps-discuss] "organization's top level domain"
> 

Ditto.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 9 Sep 2010 13:17:36 -0400

> You're not going to like this, but -1 for a sad reason: the principal domain name for Example Corp. is www.example.com, not example.com.

Really?

We need to work out exactly what we mean by "domain name", then.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Tony Finch <[email-masked]>
Date: Thu, 9 Sep 2010 18:36:57 +0100

On Thu, 9 Sep 2010, Paul Hoffman wrote:
> You're not going to like this, but -1 for a sad reason: the principal
> domain name for Example Corp. is www.example.com, not example.com.

Spoilsport :-) I did consider this problem, but I think it is dealt
with by the context. Here's the edited RFC 2142 section 2:

   For well known names that are not related to specific protocols, only
   the organization's principal domain(s) is/are required to be valid.
   For example, if an Internet service provider's domain name is
   COMPANY.COM, then the <[email-masked]> address must be valid and
   supported, even though the customers whose activity generates
   complaints use hosts with more specific domain names like
   SHELL1.COMPANY.COM.  Note, however, that it is valid and encouraged
   to support mailbox names for sub-domains, as appropriate.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 09 Sep 2010 10:37:49 -0700

Yeah. I do not see this as negating the definition, even though it makes for a confusing... example.

d/

-- 
Dave Crocker
bbiw.net

(via mobile)

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 9 Sep 2010 11:10:23 -0700

So, let me amend my "-1" to "-1 unless there is an example to make it clear we don't mean www.example.com".

--Paul Hoffman, Director
--VPN Consortium

---

From: Dave Crocker <[email-masked]>
Date: Thu, 09 Sep 2010 11:16:14 -0700

My point was that I do not understand applying "principal doman" and coming up with your example, unless the requirement is to cover every possible misinterpretation.

d/

-- 
Dave Crocker
bbiw.net

(via mobile)

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 15 Sep 2010 20:13:37 -0600

On 9/5/10 9:58 AM, Dave CROCKER wrote:
> RFC 2142 user the phrase "organization's top level domain".  This refers
> to the string that is delegated to the organization and provides the
> root of any sub-tree to the DNS that they create.  Around the world and
> around the DNS, this 'root' will have two or more fields, such as
> bbiw.net or ucl.ac.uk.
> 
> An erratum has been filed on the phrase.  I take it as being a result of
> "top level domain" becoming entrenched to mean only the right-most field
> of a domain name. The stuff that is delegated from the root of the DNS.

Dave, I was just now processing errata and came across the erratum you
referenced in this thread:

http://www.rfc-editor.org/errata_search.php?eid=1764

To close the loop, I'm going to set this erratum to "hold for document
update" with the consensus terminology (i.e., "organization's principal
domain name").

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 15 Sep 2010 22:22:14 -0700

WFM.  tnx.

d/

-- 

   Dave Crocker