Subject: Re: application/xml in ietf-xml-guidelines
From: Keith Moore <[email-masked]>
To: Paul Prescod <[email-masked]>
Cc: Keith Moore <[email-masked]>, "Simon St.Laurent" <[email-masked]>, Mark Baker <[email-masked]>, [email-masked]
Date: Fri, 19 Apr 2002 00:30:19 -0400
List-Id: <ietf-xml-mime.imc.org>

> But if we agree that it is possible to construct URIs that are both
> likely to survive for a long, long time, AND be dereferencable using
> widely deployed software then what are we arguing about? Why not change
> the RFC to say:
> 
> The IETF hereby commits to maintaining a namespace rooted in
> "http://www.ietf/org/xmlns". This should be used as the root for
> IETF-defined namespaces.

I would strongly argue against IETF making such an agreement -
it imposes too many long-term constraints on the operation of 
the IETF web service for what I see as a a very dubious gain.

Keith

Date: Thu, 18 Apr 2002 21:06:47 -0700
From: Paul Prescod <[email-masked]>
To: Keith Moore <[email-masked]>
CC: "Simon St.Laurent" <[email-masked]>, Mark Baker <[email-masked]>, [email-masked]
Subject: Re: application/xml in ietf-xml-guidelines
Sender: [email-masked]

Keith Moore wrote:
> 
> > Why are HTTP URIs unstable over the long term? Why shouldn't the URI
> > "http://www.ietf.org/rfc/rfc0821.txt" last for 100 years?
> 
> That particular URI might last.  The vast majority of URIs will not.

But if we agree that it is possible to construct URIs that are both
likely to survive for a long, long time, AND be dereferencable using
widely deployed software then what are we arguing about? Why not change
the RFC to say:

The IETF hereby commits to maintaining a namespace rooted in
"http://www.ietf/org/xmlns". This should be used as the root for
IETF-defined namespaces.

> So in general it's not a good idea to trust URIs to be a stable
> reference over a long period of time.

In general no. But just as the "IETF URN" subset of the URI space is
going to be stable because the IETF says so, couldn't the "IETF URL"
subset of the URI space be stable for the same reason?

> ... But you still won't be able to assume good stability for http
> URIs in general.

But who cares about HTTP URIs in general? We're talking about the tiny
subset defined in IETF specifications.

 Paul Prescod

From: Keith Moore <[email-masked]>
To: Tim Bray <[email-masked]>
cc: Keith Moore <[email-masked]>, "Simon St.Laurent" <[email-masked]>, Mark Baker <[email-masked]>, [email-masked]
Subject: Re: application/xml in ietf-xml-guidelines 
Date: Thu, 18 Apr 2002 23:30:00 -0400
Sender: [email-masked]

> Indeed.  But I think that what's being said is that where dereferencing
> is a required part of the scenario, URNs are contraindicated. -Tim

and I think that's a reasonable assumption, at least for the time being.

Date: Thu, 18 Apr 2002 18:41:35 -0700
From: Paul Prescod <[email-masked]>
To: Keith Moore <[email-masked]>
CC: "Simon St.Laurent" <[email-masked]>, Mark Baker <[email-masked]>, [email-masked]
Subject: Re: application/xml in ietf-xml-guidelines
Sender: [email-masked]

Keith Moore wrote:
> 
>...
> 
> If you want an identifer that is stable over the long term, then you
> want to avoid burdening the name with any dependencies or associations
> with things that aren't stable over a long term -- such as directory
> structures, domain names, and access protocols.   

I'm sure every argument has been made and remade so I ask only for my
own education:

Why are HTTP URIs unstable over the long term? Why shouldn't the URI
"http://www.ietf.org/rfc/rfc0821.txt" last for 100 years? All it would
take is sane management and about a thousand dollars in domain name
fees. But more to the point, isn't this the exact same situation with
ISBN numbers? If the "International ISBN Agency" and "US ISBN Agency"
were shut down for lack of funding then who whould arbitrate disputes
about ownership of ISBNs? What if those groups started leaking changed
data through their publications. What if I broke in and scrambled their
database to swap the ISBNs for my book and that of Stephen King's latest
book?

Longevity seems to me to come down to money, willpower, security and
trust, not to one syntax versus the other.

 Paul Prescod

Date: Thu, 18 Apr 2002 18:05:18 -0700
From: Tim Bray <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: "Simon St.Laurent" <[email-masked]>, Mark Baker <[email-masked]>, [email-masked]
Subject: Re: application/xml in ietf-xml-guidelines
Sender: [email-masked]

Keith Moore wrote:

> it's meaningless to try to define URNs' success by comparing them
> to URLs.  they have different use cases, and different scenarios for
> deployment.

Indeed.  But I think that what's being said is that where dereferencing
is a required part of the scenario, URNs are contraindicated. -Tim

Date: Thu, 18 Apr 2002 18:01:43 -0700
From: Tim Bray <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: "Simon St.Laurent" <[email-masked]>, Mark Baker <[email-masked]>, [email-masked]
Subject: Re: application/xml in ietf-xml-guidelines
Sender: [email-masked]

Keith Moore wrote:
> 
> What I have a really hard time understanding is the belief that everything 
> should run over HTTP, or that everything should be named using HTTP URLs, 
> when it's abundantly clear that HTTP and HTTP URIs are a poor choice for 
> many applications - even if HTTP is only used as a mechanism to negotiate 
> another protocol.  

Neither side in this debate wins by accusing the other of absolutist 
positions.  Having said that, my position is fairly absolutist within 
the context of my own experience.   It turns out that for 100% of the 
applications that I deal with, it is good and useful if names can be 
dereferenced to yield definitive and other related information about 
whatever the name is naming.  Whereas URN dereference is possible in 
theory it is not widely available in practice.  Hence for the stuff I'm 
working on, "http" class URIs are the way to go.  I can understand that 
there are other application classes where the requirement for stability 
trumps the desirability of dereference.  -Tim

Date: Thu, 18 Apr 2002 17:48:57 -0700
From: Tim Bray <[email-masked]>
To: Mark Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: application/xml in ietf-xml-guidelines
Sender: [email-masked]

Mark Baker wrote:

> I just had a look at draft-hollenbeck-ietf-xml-guidelines-01, and
> saw this;
> 
>   "The "application/xml" media type is most appropriate for general
>    XML; [...]"

Thanks Mark for spotting this.  As time goes on, I am having more and
more difficulty believing in the notion of "general XML" - I have not
seen and am less and less able to imagine a scenario in which one
party sends another a message in "general XML".

> Also, I believe that "text/xml" should be explicitly not recommended,

Yes.  I have been arguing in the TAG context that we should take
another whack at RFC 3023 to say that "text/xml" SHOULD NOT or maybe
even MUST NOT be used - the baggage carried by "text/" seems never
useful and often harmful in the case of XML. -Tim

> Lastly, there's no mention of the RFC 3023 "+xml" suffix convention,
> which should at least be mentioned as a possibility for use.  

Yep.

> Plus, FWIW, I'm in the "don't use URNs" camp.

Me too. -Tim

From: Keith Moore <[email-masked]>
To: Tim Bray <[email-masked]>
cc: Keith Moore <[email-masked]>, "Simon St.Laurent" <[email-masked]>, Mark Baker <[email-masked]>, [email-masked]
Subject: Re: application/xml in ietf-xml-guidelines 
Date: Thu, 18 Apr 2002 09:04:29 -0400
Sender: [email-masked]

> If the knowledge has existed for 7 years and implementations are
> still largely absent, I would take this as strong empirical evidence
> that resolution implementations will continue to be absent. -Tim

protocol implementation isn't the issue - several protocols suitable 
for URN resolution were up and running long before URNs were defined.   

it's meaningless to try to define URNs' success by comparing them
to URLs.  they have different use cases, and different scenarios for
deployment.

Keith

Date: Thu, 18 Apr 2002 15:32:42 +0900
To: Mark Baker <[email-masked]>, Keith Moore <[email-masked]>
From: Martin Duerst <[email-masked]>
Subject: Re: application/xml in ietf-xml-guidelines
Cc: Mark Baker <[email-masked]>, [email-masked]
Sender: [email-masked]

At 20:37 02/04/17 -0400, Mark Baker wrote:

> > > Also, I believe that "text/xml" should be explicitly not recommended,
> > > due to the text/plain fallback of all text/* types.
> >
> > if it's just a fallback behavior, why does it matter much?

The other problem with text/xml and text/...+xml is the
charset default of US-ASCII, i.e.

Content-Type: text/xml

is exactly the same as

Content-Type: text/xml; charset=us-ascii

This doesn't work that well in many cases.

Regards,    Martin.

> > actually "display as text" is probably a better fallback for XML
> > than for HTML - XML generally seems to be more readable than HTML :)
>
>When I was first introduced to this issue while writing RFC 3236, it
>was made quite clear to me (on this list, I believe), that text/*
>was for content that anybody could easily read.  The XML prolog would
>scare off most people!  And those that make it past that would surely
>be overwhelmed by xmlns declarations! 8-)
>
>MB
>--
>Mark Baker, Chief Science Officer, Planetfred, Inc.
>Ottawa, Ontario, CANADA.      [email-masked]
>http://www.markbaker.ca   http://www.planetfred.com

Date: Wed, 17 Apr 2002 22:34:14 -0700
From: Tim Bray <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: "Simon St.Laurent" <[email-masked]>, Mark Baker <[email-masked]>, [email-masked]
Subject: Re: application/xml in ietf-xml-guidelines
Sender: [email-masked]

Keith Moore wrote:

> We've known essentially how we were going to resolve URNs since 1 November 
> 1995.  

If the knowledge has existed for 7 years and implementations are
still largely absent, I would take this as strong empirical evidence
that resolution implementations will continue to be absent. -Tim

Subject: Re: application/xml in ietf-xml-guidelines
From: "Simon St.Laurent" <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: [email-masked]
Date: 17 Apr 2002 23:03:51 -0400
Sender: [email-masked]

On Wed, 2002-04-17 at 22:27, Keith Moore wrote:
> opacity of URNs is a design feature - URNs need to be opaque to do their jobs.
> 
> OTOH, I have no fondness for use of URNs to identify vocabularies either.
> 
> We've known essentially how we were going to resolve URNs since 1 November 
> 1995.  The biggest problem we've had in finishing the specifications is that 
> URNs were so widely misunderstood that we were continually having to argue with 
> people who were insisting that they have properties that would make them 
> unusable for their intended purpose.

I suspect there's a level of agreement underneath the apparent
disagreement.  You want URNs to be opaque; I want namespace identifiers
to be transparent (or at least translucent.)

Using URIs as namespace identifiers may have been a bad choice all
round, though I've not heard anyone really admit that, much less shout
it out loud.

The question here seem to come down to whether it's the namespace
identifier-nature that matters or the URI-nature that matters.  Given
that the document section is titled "Namespaces", I'm inclined to vote
for the namespace identifier-nature and focus on what works best for
identifying vocabularies rather than arguing about the value of URN/L/I.

Given current IETF politics/policy, I suspect there's not much room for
such an opinion.

-- 
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com

From: Keith Moore <[email-masked]>
To: "Simon St.Laurent" <[email-masked]>
cc: Keith Moore <[email-masked]>, Mark Baker <[email-masked]>, [email-masked]
Subject: Re: application/xml in ietf-xml-guidelines 
Date: Wed, 17 Apr 2002 22:27:39 -0400
Sender: [email-masked]

> > What I have a really hard time understanding is the belief that everything
> > should run over HTTP, or that everything should be named using HTTP URLs,
> > when it's abundantly clear that HTTP and HTTP URIs are a poor choice for
> > many applications - even if HTTP is only used as a mechanism to negotiate
> > another protocol.
> 
> I have no fondness for HTTP identifiers.  At the same time, I have no
> fondness for opaque identifiers, especially when used to identify
> vocabularies.

opacity of URNs is a design feature - URNs need to be opaque to do their jobs.

OTOH, I have no fondness for use of URNs to identify vocabularies either.

We've known essentially how we were going to resolve URNs since 1 November 
1995.  The biggest problem we've had in finishing the specifications is that 
URNs were so widely misunderstood that we were continually having to argue with 
people who were insisting that they have properties that would make them 
unusable for their intended purpose.

Keith 

Date: Wed, 17 Apr 2002 20:37:56 -0400
From: Mark Baker <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: Mark Baker <[email-masked]>, [email-masked]
Subject: Re: application/xml in ietf-xml-guidelines
Sender: [email-masked]

On Wed, Apr 17, 2002 at 04:28:18PM -0400, Keith Moore wrote:
> depending on what you mean by "dispatch", neither, really, does 
> any other content-type.  in particular, content-types don't specify 
> anything about presentation or processing; these decisions are up 
> to the recipient.  

We could talk about this again (I'm game!), or I could just reference
the same discussion we held on this topic on www-tag.  My position is
very close to Roy's, and I don't have much to add to what he said at
this time.

The posts of his that best reflect my position are;

http://lists.w3.org/Archives/Public/www-tag/2002Jan/0162.html
http://lists.w3.org/Archives/Public/www-tag/2002Jan/0167.html

> > Also, I believe that "text/xml" should be explicitly not recommended,
> > due to the text/plain fallback of all text/* types.  
> 
> if it's just a fallback behavior, why does it matter much?
> actually "display as text" is probably a better fallback for XML 
> than for HTML - XML generally seems to be more readable than HTML :)

When I was first introduced to this issue while writing RFC 3236, it
was made quite clear to me (on this list, I believe), that text/*
was for content that anybody could easily read.  The XML prolog would
scare off most people!  And those that make it past that would surely
be overwhelmed by xmlns declarations! 8-)

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      [email-masked]
http://www.markbaker.ca   http://www.planetfred.com

Subject: Re: application/xml in ietf-xml-guidelines
From: "Simon St.Laurent" <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: Mark Baker <[email-masked]>, [email-masked]
Date: 17 Apr 2002 18:14:17 -0400
Sender: [email-masked]

On Wed, 2002-04-17 at 16:59, Keith Moore wrote:
> What I have a really hard time understanding is the belief that everything 
> should run over HTTP, or that everything should be named using HTTP URLs, 
> when it's abundantly clear that HTTP and HTTP URIs are a poor choice for 
> many applications - even if HTTP is only used as a mechanism to negotiate 
> another protocol.  

I have no fondness for HTTP identifiers.  At the same time, I have no
fondness for opaque identifiers, especially when used to identify
vocabularies.

If the IETF plans to provide some mechanism whereby developers can look
at a namespace URN used in a protocol and find information about it -
preferably something more substantial than a Google search on
RFC+urn:ietf... - I have no objection whatsoever.

I'd love it if the W3C and the IETF could get their act together on
making URIs in general less opaque, but the W3C doesn't seem to get that
and the IETF doesn't presently seem interested in building the
infrastructure it takes to look behind its own URNs.

As the Internet-Draft for IANA URN Namespace states "The namespace is
primarily opaque", I have a very hard time imagining this situation
changing any time soon.
 
-- 
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com

From: Keith Moore <[email-masked]>
To: "Simon St.Laurent" <[email-masked]>
cc: Keith Moore <[email-masked]>, Mark Baker <[email-masked]>, [email-masked]
Subject: Re: application/xml in ietf-xml-guidelines 
Date: Wed, 17 Apr 2002 16:59:33 -0400
Sender: [email-masked]

> I'm having a really hard time understanding why the IETF is so keen on
> inflicting URNs on the world.

What's so hard to understand?  

URNs are useful for the same reason that ISBNs, ISSNs, etc. are useful.
They weren't intended to replace URLs; they were intended to cover a
case for which DNS-based and protocol-based URLs have repeatedly been
demonstrated to work poorly -- specifically, as identifiers which have
a high probability of being stably bound to the same resource over very 
long periods of time (decades or more).  The assumption is that for
some purposes a stable association between the resource name and the 
resource is more important than being able to access that resource 
using that name from anywhere at any time.    

If you want an identifer that is stable over the long term, then you
want to avoid burdening the name with any dependencies or associations
with things that aren't stable over a long term -- such as directory
structures, domain names, and access protocols.   The design of URNs
follows almost directly from that realization, and from the requirement 
for global uniqueness.  Other identifiers that were intended for similar 
purposes (e.g. handles/DOIs) have very similar designs to URNs.

What I have a really hard time understanding is the belief that everything 
should run over HTTP, or that everything should be named using HTTP URLs, 
when it's abundantly clear that HTTP and HTTP URIs are a poor choice for 
many applications - even if HTTP is only used as a mechanism to negotiate 
another protocol.  

Keith

Subject: Re: application/xml in ietf-xml-guidelines
From: "Simon St.Laurent" <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: Mark Baker <[email-masked]>, [email-masked]
Date: 17 Apr 2002 16:41:17 -0400
Sender: [email-masked]

On Wed, 2002-04-17 at 16:28, Keith Moore wrote:
> > Lastly, there's no mention of the RFC 3023 "+xml" suffix convention,
> > which should at least be mentioned as a possibility for use.  
> 
> agreed.

And agreed.

> > I believe
> > that my first point above highlights a large part of the value of
> > specific media types (whether +xml is used or not), as the required
> > dispatch behaviour can be assigned to them.
> 
> we need to be careful about how we use the word "dispatch" -
> it's used to distinguish different types from one another,
> but not to actually specify the processing to be performed.

I agree with Keith on this one.  The types identify "what something is",
not "how you should process that something".  I'd be strongly opposed to
any attempt to impose a particular style of namespace processing on any
of the types described by RFC 3023 or to +xml generically.

I've not yet gotten around to writing POND (Perversely-Oriented
Namespace-based Datatyping), but believe me, it's coming.

> > Plus, FWIW, I'm in the "don't use URNs" camp.
> 
> nobody's perfect :)

I'm having a really hard time understanding why the IETF is so keen on
inflicting URNs on the world.  The best answers I've heard suggest
merely that the IETF isn't to be trusted with URLs, which seems, well,
an extraordinarily weak answer.
 
-- 
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com

From: Keith Moore <[email-masked]>
To: Mark Baker <[email-masked]>
cc: [email-masked]
Subject: Re: application/xml in ietf-xml-guidelines 
Date: Wed, 17 Apr 2002 16:28:18 -0400
Sender: [email-masked]

> I just had a look at draft-hollenbeck-ietf-xml-guidelines-01, and
> saw this;
> 
>   "The "application/xml" media type is most appropriate for general
>    XML; [...]"
> 
> I have three concerns about it.  In descending order of priority;
> 
> "application/xml" (and text/xml for that matter) do not have any
> specified namespace dispatch behaviour.  

depending on what you mean by "dispatch", neither, really, does 
any other content-type.  in particular, content-types don't specify 
anything about presentation or processing; these decisions are up 
to the recipient.  

this wasn't so clear at the time that MIME was designed because
it was assumed to be for interpersonal email - hence there's a 
lot of language in the MIME spec about default presentation 
behaviors.  these days we're using MIME for many other applications
than interpersonal messaging, so we don't assume a priori that
just because a bit of content is encapsulated in MIME that it's
going to be presented to some recipient as if it were an email
message.  (for that matter, we no longer assume that something sent
via SMTP is intended for human consumption either)

we really ought to make this clearer when we update the MIME spec.

> That is, if I send some
> XHTML as application/xml, the recipient agent doesn't know whether I
> want it displayed as XHTML, or in some tree like XML format, nor do
> I have any expectation of what the agent might do with it.  According
> to RFC 3023, both behaviours are fine, and IMO this makes
> "application/xml" less suitable than believed as a generic type.  

it makes application/xml neither more or less suitable - no type 
should be expected to dictate behavior.

> Also, I believe that "text/xml" should be explicitly not recommended,
> due to the text/plain fallback of all text/* types.  

if it's just a fallback behavior, why does it matter much?
actually "display as text" is probably a better fallback for XML 
than for HTML - XML generally seems to be more readable than HTML :)

> Lastly, there's no mention of the RFC 3023 "+xml" suffix convention,
> which should at least be mentioned as a possibility for use.  

agreed.

> I believe
> that my first point above highlights a large part of the value of
> specific media types (whether +xml is used or not), as the required
> dispatch behaviour can be assigned to them.

we need to be careful about how we use the word "dispatch" -
it's used to distinguish different types from one another,
but not to actually specify the processing to be performed.

> Plus, FWIW, I'm in the "don't use URNs" camp.

nobody's perfect :)

Keith

Date: Wed, 17 Apr 2002 14:57:30 -0400
From: Mark Baker <[email-masked]>
To: [email-masked]
Subject: application/xml in ietf-xml-guidelines
Sender: [email-masked]

Hey,

I just had a look at draft-hollenbeck-ietf-xml-guidelines-01, and
saw this;

  "The "application/xml" media type is most appropriate for general
   XML; [...]"

I have three concerns about it.  In descending order of priority;

"application/xml" (and text/xml for that matter) do not have any
specified namespace dispatch behaviour.  That is, if I send some
XHTML as application/xml, the recipient agent doesn't know whether I
want it displayed as XHTML, or in some tree like XML format, nor do
I have any expectation of what the agent might do with it.  According
to RFC 3023, both behaviours are fine, and IMO this makes
"application/xml" less suitable than believed as a generic type.  Here's
the relevant paragraph;

]   An XML document labeled as text/xml or application/xml might contain
]   namespace declarations, stylesheet-linking processing instructions
]   (PIs), schema information, or other declarations that might be used
]   to suggest how the document is to be processed.  For example, a
]   document might have the XHTML namespace and a reference to a CSS
]   stylesheet.  Such a document might be handled by applications that
]   would use this information to dispatch the document for appropriate
]   processing.

(emphasis on "might" in that last sentence)

Also, I believe that "text/xml" should be explicitly not recommended,
due to the text/plain fallback of all text/* types.  It's possible that
text/* has already been abused so badly (text/html being the biggie)
that a text/plain fallback cannot be assumed, but I'll let others
decide if that's actually the case or not.

Lastly, there's no mention of the RFC 3023 "+xml" suffix convention,
which should at least be mentioned as a possibility for use.  I believe
that my first point above highlights a large part of the value of
specific media types (whether +xml is used or not), as the required
dispatch behaviour can be assigned to them.

Plus, FWIW, I'm in the "don't use URNs" camp.

Thanks.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      [email-masked]
http://www.markbaker.ca   http://www.planetfred.com

Reply-To: <[email-masked]>
From: "Larry Masinter" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: "'Paul Hoffman / IMC'" <[email-masked]>, "'Marshall Rose'" <[email-masked]>, "Scott Hollenbeck" <[email-masked]>, <[email-masked]>
Subject: "Guidelines for the Use of XML in IETF Protocols"
Date: Sat, 6 Apr 2002 11:47:48 -0800
Importance: Normal
Sender: [email-masked]

Abstract:
   The eXtensible Markup Language (XML) is a framework for structuring
   data.  While it evolved from SGML -- a markup language primarily
   focused on structuring documents -- XML has evolved to be a widely-
   used mechanism for representing structured data.

   There are a wide variety of Internet protocols; many have need for a
   representation for structured data relevant to their application.
   There has been much interest in the use of XML as a representation
   method.  This document describes basic XML concepts, analyzes various
   alternatives in the use of XML, and provides guidelines for the use
   of XML within IETF standards-track protocols.

Intended Publication Status
   It is the goal of the authors that this draft (when completed and
   then approved by the IESG) be published as a Best Current Practice
   (BCP).

Submitted to the Internet Drafts, but available now at
   http://www.imc.org/ietf-xml-use/draft-hollenbeck-ietf-xml-guide.txt
or
   http://www.imc.org/ietf-xml-use/draft-hollenbeck-ietf-xml-guide.html

with a mailing list [email-masked] , archive at
   http://www.imc.org/ietf-xml-use/index.html

   "To subscribe to the mailing list, send a message to
   [email-masked] with the single word subscribe
   in the body of the message. To unsubscribe from the list, use
   that same address with the single word unsubscribe in the body
   of the message."

Larry
-- 
http://larry.masinter.net