Subject: PaceDatePublished: meta-question about other namespaces

From: Antone Roundy <[email-masked]>
Date: Fri, 24 Sep 2004 10:15:34 -0600

A meta-question lurking behind this proposal (and PaceDateModified), 
which we've discussed before, but never made a decision on, is what to 
do when we want an element that closely parallels something from 
another well known namespace.  A major reason cited for the rejection 
of PaceDateSubjective (the reason that convinced me) was that a) it 
would be good to have an extension to more comprehensively cover the 
uses addressed by the proposed element, and b) if such an extension is 
built, interoperability will suffer as some people use the core element 
and some use the extension element.

 From PaceDatePublished:

    "Typically, atom:published will be associated with the initial 
creation or first availability of the resource."

This spans the definitions of a few things from dcterms[1]:

    dcterms:created: "Date of creation of the resource"
    dcterms:available: "Date (often a range) that the resource will 
become or did become available"
    dcterms:issued: "Date of formal issuance (e.g., publication) of the 
resource"

If we adopt atom:published, are we going to run into interop issues 
with people who prefer the more tightly defined dates from dcterms?

So, the meta-question: when considering an element defined in a well 
known namespace, shall we:

a) Define a deliberately IDENTICAL element in the atom namespace
b) Define an element in the atom namespace if what we want IS identical 
to what's defined elsewhere, but refer to the other element if not
c) Define an element in the atom namespace if what we want IS NOT 
identical to what's defined elsewhere, but refer to the other element 
if it is
d) Define exactly what WE want in the atom namespace, ignoring the 
existence of the other element (ie. never trouble ourselves to consider 
elements from other namespaces)
e) Put nothing in the atom namespace but (a mention of/recommend use 
of) the other element
	e1) only if the element is to be optional
	e2) and sometimes even make the element required
f) Put nothing in the atom namespace, and don't mention the other 
element
g) Consider the question on a case-by-case basis every time

If we decide to start adopting elements from other namespaces, are we 
going to have to reconsider some elements currently in the spec?  Or 
can we decide that certain elements are so very core to Atom that they 
must be in the atom namespace and/or so entirely sufficient that we 
have no fear of someone going to another namespace for something 
similar because they feel a need for its nuances?

If we choose a policy for attacking these issues, we should be able to 
speed through a number of decisions much more quickly.

[1] http://web.resource.org/rss/1.0/modules/dcterms/

---

From: Sam Ruby <[email-masked]>
Date: Fri, 24 Sep 2004 18:19:12 -0400

Antone Roundy wrote:
> do when we want an element that closely parallels something from another 
> well known namespace.  A major reason cited for the rejection of 
> PaceDateSubjective (the reason that convinced me) was that a) it would 
> be good to have an extension to more comprehensively cover the uses 
> addressed by the proposed element, and b) if such an extension is built, 
> interoperability will suffer as some people use the core element and 
> some use the extension element.

This is a problem common to all optional elements.  In the pace as 
written, <published> is required.

Tim has indicated he would support the pace, if <published> were 
optional instead of being required.

- Sam Ruby

---

From: Tim Bray <[email-masked]>
Date: Fri, 24 Sep 2004 15:46:19 -0700

> optional instead of being required.

Let me put it another way; I am totally -1 on this if it's required.  
There are applications where the "published" date is not available or 
actively misleading.

Also, there's a deeper point.  The required elements in Atom represent 
the minimum contract I have with the world if I, as a publisher, want 
to provide a feed.  I'm willing to accept that I provide an 
<atom:updated> as a price of entry because it has a large positive 
impact on many other pieces of the pipe downstream.  I can't think of 
any other date for which I'm willing to make that promise.

Furthermore: no online publishing application I've ever written or used 
would really need the atom:published date.  If there is an interesting 
class of applications for which it would be beneficial, I'm OK with it 
<em>as long as it's optional</em>.   -Tim

---

From: Graham <[email-masked]>
Date: Sat, 25 Sep 2004 00:01:11 +0100

On 24 Sep 2004, at 11:19 pm, Sam Ruby wrote:

>> which we've discussed before, but never made a decision on, is what 
>> to do when we want an element that closely parallels something from 
>> uses addressed by the proposed element, and b) if such an extension 
>> is built, interoperability will suffer as some people use the core 
>> element and some use the extension element.
>
> This is a problem common to all optional elements.

Sam, the answer is never, ever, to make the element required. Elements 
should only be required if there are real applications that can't work 
properly when an element is absent. Please refrain from this crazy 
talk.

Graham

---

From: Walter Underwood <[email-masked]>
Date: Fri, 24 Sep 2004 16:06:53 -0700

--On Friday, September 24, 2004 03:46:19 PM -0700 Tim Bray 
<[email-masked]> wrote:
> <em>as long as it's optional</em>.

For a robot, updated is important and published is not.

For a human viewing the feed, updated is maybe useful and published
(or dc.date) is important.

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek

---

From: Robert Sayre <[email-masked]>
Date: Fri, 24 Sep 2004 19:18:49 -0400

Tim Bray wrote:

> the minimum contract I have with the world if I, as a publisher, want to 
> provide a feed.  

The rationale also cites Tim's "No Inventions" piece, and then cites 
precedents that all seem to be optional. I'm assuming there are several 
example interop problems cause by the optional nature of pubDate. My 
question: Which of those would not be remedied by the presence of 
<atom:updated>?

Also, I wonder if <atom:published> constitutes a publication time-bomb. 
What is an <atom:published> element supposed to mean in the context of 
the protocol? Does the server constitute a "consumer choosing not to 
display" an entry when it receives an entry with an atom:published date 
in the future?

Although I recognize the date can be useful, especially to humans (as 
Walter noted), I guess I am a little worried about what happens in 
software terms as a result of the date's presence.

Robert Sayre

---

From: Antone Roundy <[email-masked]>
Date: Fri, 24 Sep 2004 18:16:35 -0600

> There are applications where the "published" date is not available or 
I'd also say -1 if required.  For one thing, I think Atom should have 
one required date, and only one.  Right now, atom:published is filling 
that space.

Back to the meta-question, using atom:published to make the discussion 
more concrete, what do we gain by having atom:published versus 
dcterms:issued?  One answer: the working group keeps control of the 
definition of the element (but are we really afraid that the definition 
of dcterms:issued is going to change?)  Another answer: we get to 
define it a little differently from dcterms:issued et al (but is it 
non-trivially more useful?)

Even if we don't resolve the meta-question now, my opinion is that, 
considering that we already have the one required date that Atom really 
needs, and considering that there is a well known extension with a 
number of reasonably well defined dates[1], there's no need, and very 
little reason to add date elements to the atom namespace which 
substantially duplicate the dcterms dates.

On the meta-question:

+0.9 to all required elements being in the atom namespace, with their 
own definitions (ie. not tied to the definitions of terms from other 
namespaces, even if similar terms exist)

+1 to not duplicating well known elements from other namespaces (unless 
they are to be required elements, as noted above)

+1 to making explicit mention of well known, well defined, 
significantly useful elements which fill purposes not filled by 
elements in the atom namespace (dcterms dates being the only one's I 
can think of right now.  If some of use follow up on our intentions to 
create an extension for events, then those too).

Antone

[1] I say "reasonably" because while I think that I understand what 
each definition means, in some cases, it took a little thought to get 
there.  Unless there are more extensive definitions somewhere that I 
haven't seen, I think the dcterms definitions tend to be a bit too 
terse.

---

From: Dare Obasanjo <[email-masked]>
Date: Fri, 24 Sep 2004 22:07:56 -0700 (PDT)

> any other date for which I'm willing to make that

If <updated> is required and <published> is not, I
guess things would still work but it does seem
bass-ackwards to me. 

> <em>as long as it's optional</em>.   -Tim

*sigh* 

The purpose of an XML syndication format is to meet
the needs of consumers not producers. I have lamented
on the bias of the folks on this list on focusing on
what tools can generate instead of focusing on the
fact that the format is primarily for consumption by
aggregators. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #23
I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks.

__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 25 Sep 2004 14:55:08 +0200

> There are applications where the "published" date is not available or  

Although I definately see its usefulness, I agree that at this point in  
time, it can't be required. This is what I've realised from all the last  
months of debate over the dates; we can't require what's not already  
provided.

If I'm wrong in this, I'd like to hear it from the actual providers. From  
the publishers. From the writers of publishing software. From Six Apart.

I think the way to go about it is to make what we want, but know someone  
can't provide, optional, and then rather in the future, when everyone  
provides it anyway, make it required.

But we should, today, encourage people to use it. We should encourage  
publishing software to not ambiguate and mutate the elements we put into  
the format. We should encourage shared semantics. We should try to make  
them all strive for a better publishing and data model. This can be done  
in notes, in howto's, by evangelists and so on. It may even be noted in  
the specification.

But until people have reached the mark we set, we can't require everyone  
to be on that mark, because they just won't.

Just my two cents.

-- 
Asbjørn Ulsberg    -=|=-     http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»

---

From: Tim Bray <[email-masked]>
Date: Sat, 25 Sep 2004 07:10:39 -0700

On Sep 24, 2004, at 10:07 PM, Dare Obasanjo wrote:

>> would really need the atom:published date....
> *sigh*
>

I state that I'm unaware of the utility of the atom:published date.  
You state that this is evidence of publisher bias (perfectly possible, 
that's what I am mostly) and I think you're arguing that atom:published 
would actually be more useful than atom:updated for aggregators; could 
you please expand on that?  It seems really counter-intuitive to me.  
It seems to me that the most typical default mode of operation is to 
show users the recently-updated stuff in the feed, and that 
atom:updated provides exactly what you need to do that.   What am I 
missing. -Tim

---

From: Walter Underwood <[email-masked]>
Date: Sat, 25 Sep 2004 08:56:54 -0700

> fact that the format is primarily for consumption by

I would put it another way. We seem to be designing for computers
working with the feeds instead of for people. I think we need to
design for both. Without happy customers, Atom will fade away.

It is harder to do that, of course.

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 25 Sep 2004 15:59:59 -0400

>I state that I'm unaware of the utility of the atom:published date.
	One thing to keep in mind while we're discussing these dates is that
in some situations the dates on entries may have legal implications and
weight. For instance, see the following text from the US Patent Office's
Manual of Patent Examination Policy[1]:

"Prior art disclosures on the Internet or on an online database are
considered to be publicly available as of the date the item was publicly
posted. If the publication does not include a publication date (or retrieval
date), it cannot be relied upon as prior art under 35 U.S.C. 102(a) or (b),
although it may be relied upon to provide evidence regarding the state of
the art. ... An electronic publication, like any publication, may be relied
upon for all that it would have reasonably suggested to one having ordinary
skill in the art."

Certainly, one could argue that an "updated" date is sufficient to enable an
item to be considered prior art -- if it contains an "objective" indication
of the date on which the update was published. However, the pity here is
that updates in news aggregation systems typically replace prior versions.
Thus, if the "first published" date isn't available, a searcher is somewhat
limited in the strategies available for finding earlier versions of the
entry that might serve equally as prior art while establishing an earlier
priority date.

Whether or not one accepts this as an argument for "first-published-date" to
be supported in addition to "updated-date," it should be seen that reliance
on subjective dates could have some unfortunate legal consequences.
Subjective dates would not be accepted by legal authorities as "the date the
item was publicly posted" and thus would ensure that Atom entries could
never be considered "printed publications" for use in establishing prior
art.

At least *one* Atom date should be defined such that it MUST be the date
that the item was published (either as an update or as a first publication.)
If there is a desire to support subjective dates, then these should be
supported as extensions or optional elements.

		bob wyman

[1] See Section 2128 "'Printed Publications' as Prior Art"
http://www.uspto.gov/web/offices/pac/mpep/mpep_e8r2_2100_508.pdf

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sat, 25 Sep 2004 15:10:44 -0700

At 3:59 PM -0400 9/25/04, Bob Wyman wrote:
>weight.

Noted. In fact, "in some situations", the <foo> in anything you 
publish or read "may have legal implications and weight" in some 
jurisdictions somewhere in the world.

(Having said that, if you are in fact a lawyer and were offering 
legal advice, my apologies for speaking harshly. I didn't see any 
attribution to that effect, so I assumed you were simply following 
the time-honored habits of the IETF.)

>that the item was published (either as an update or as a first publication.)

If you are saying this for legal reasons as compared to technical 
reasons, then please don't (unless I'm wrong about you being a lawyer 
offering legal advice).

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Graham <[email-masked]>
Date: Sat, 25 Sep 2004 23:29:13 +0100

> guess things would still work but it does seem

Yes. Everything is published initially, not everything is later updated.

Graham

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 25 Sep 2004 19:20:59 -0400

Paul Hoffman wrote:
> (unless I'm wrong about you being a lawyer offering legal advice)
	The "time-honored habit of the IETF" of attacking anyone other than
a lawyer who attempts to contribute by commenting on the law is one of the
most infantile and unproductive traditions of this process. The idea that
only those who belong to a particular group are able to speculate about and
comment on the law is reminiscent of the aristocratic cultures that are
anathema to everything that I, as an American, have been taught to value. In
a democracy, it is expected that all citizens are responsible to know and
comment on the law -- our laws only constrain the ability to practicing the
law, not for commenting on it or interpreting it.
	As far as my credentials are concerned: I have been in the
technology business for thirty years and have, for one reason or another,
needed to study patent office practice and patent law on numerous occasions.
I hold four patents. On numerous occasions, I have been given advice by
lawyers on what constitutes prior art and what constitutes a "printed
publication" in these contexts. I have specifically had the specific
portions of the MPEP that I referenced in my message reviewed by and
commented on by two lawyers in the past. I dare say that I understand this
tiny corner of the law better then most lawyers do or could every wish to.
	Attack *what* I say, if you wish, but this infantile crud of
attacking *who* said something is simply not useful.

		bob wyman

---

From: Graham <[email-masked]>
Date: Sun, 26 Sep 2004 01:04:12 +0100

On 26 Sep 2004, at 12:20 am, Bob Wyman wrote:

> The idea that only those who belong to a particular group are able to 
> speculate about and
> anathema to everything that I, as an American, have been taught to 
> value.

Paul didn't say that. He accepted your general point. The problem is 
that Atom data being admissable as evidence by the US Patent Office is 
not in the slightest bit a goal of this working group. Your choice of 
subject line makes us sound like we're breaking the law in some way. 
The IETF's policy is there to avoid this kind of scaremongering.

Graham

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 25 Sep 2004 20:52:25 -0400

Graham wrote:
>Your choice of subject line makes us sound like we're breaking
> the law in some way. ... avoid this kind of scaremongering.
	You are reading much more into what I wrote then I intended. I
did not say that the law forces us to do anything concerning dates.
Rather, I simply pointed out that *if* we want to have Atom entries
considered as "publications" for the purposes of establishing prior art,
we need to make sure that we've got "objective" dates. It is up to us as
a group to decide if that is or is not important. My personal opinion is
that it should be considered important and that we "should" ensure that
we have an objective date. But, I'm only one person...
	Remember, this was all in response to Tim Bray's statement that
he couldn't see any "utility" in having a "published" date. I was simply
pointing out one very specific bit of utility that could come from such
a date. Perhaps it will be considered to be an "edge case" that need not
be addressed... Nonetheless, it is best that we act in full knowledge of
the consequences of our decisions.

>The IETF's policy is there to avoid..
	What "policy" is this and where is it documented? The last time
a working group chair jumped on me for talking about legal issues
(pointing out a potential patent infringement) that chair was "spoken
to" by folk higher in the IESG and we ended up making extensive
modifications to the IETF IPR RFC's to establish that I (and you...) had
no only the right but also the responsibility to bring up such issues. 
	I am not aware any IETF "policy" that says that we must ignore
*any* of the implications of the protocols we design. Where is this
policy documented? What other implications of our protocols should be
ignored?

		bob wyman

---

From: Mark Pilgrim <[email-masked]>
Date: Sat, 25 Sep 2004 20:58:19 -0400

> anathema to everything that I, as an American, have been taught to value. In

You're either a lawyer or you're not.  They have a test and
everything.  If you've passed it, you are welcome to speculate on
Atom's legal aspects on this list.  If you haven't passed it, you are
welcome to speculate on Atom's legal aspects anywhere except this
list.

> I hold four patents.

I work with people who have ten times this number.  They still go to
lawyers for legal advice.

-- 
Cheers,
-Mark

---

From: Antone Roundy <[email-masked]>
Date: Sat, 25 Sep 2004 19:20:20 -0600

> Yes. Everything is published initially, not everything is later  
Technically true, but it's not much of stretch to think of initial  
publishing as the first "change" that the publisher wishes to bring to  
the attention of subscribers.  We COULD call the element  
atom:last-time-something-happened-to-this-entry-that-the-publisher- 
really-wants-noticed, but it's easier to go with the less technically  
precise, but much shorter atom:updated.

Whether to require published or updated is a decision best based on two  
factors: which would be most useful, and which can be most reliably  
provided by publishers.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 26 Sep 2004 03:35:32 +0200

On Sat, 25 Sep 2004 20:52:25 -0400, Bob Wyman <[email-masked]> wrote:

> I simply pointed out that *if* we want to have Atom entries considered
> as "publications" for the purposes of establishing prior art, we need
> to make sure that we've got "objective" dates. It is up to us as a
> group to decide if that is or is not important. My personal opinion is
> we have an objective date.

I've maintained this view all along, and still do. I agree with you. Atom  
should have a required objective date. But few tools in existance are able  
to provide such a date, so I don't think it's possible to require.

If all tool vendors suddenly came running into this mailing list screaming  
«We'll support the whole load!», that would of course change a couple of  
things, but as it looks and has looked up until now, no vendors are going  
to change their tools drastically to accomodate the Atom specification.  
Too bad, but I believe that's the case, and we just have to deal with it.

I bit and ate the whole sour apple a while ago, and although it was awful  
to have to do it, I now think that's the only way to move forward.  
Requiring things that can't be provided will just pollute Atom with bad  
data, and I don't want that.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sat, 25 Sep 2004 18:22:46 -0700

At 7:20 PM -0400 9/25/04, Bob Wyman wrote:
>most infantile and unproductive traditions of this process.

There is a difference between "attacking anyone" and "pointing out 
when the discussion has gone into realms that none of us understand, 
which is OK because it is irrelevant to the work we are doing".

>	Attack *what* I say, if you wish,

Did that.

>  but this infantile crud of

Didn't do that.

--Paul Hoffman, Director

---

From: "jt" <[email-masked]>
Date: Sat, 25 Sep 2004 21:39:33 -0400

| -----Original Message-----
| From: [email-masked]
| [mailto:[email-masked]]On Behalf Of Bob Wyman
| Sent: Saturday, September 25, 2004 8:52 PM
| To: 'Graham'
| Cc: 'Atom WG'
| Subject: RE: ARMCHAIR LAWYER ALERT (was: Re: Atom's dates may have legal
| implications... At least one "objective date" should be supported.)
|
|
|
| Graham wrote:
| >Your choice of subject line makes us sound like we're breaking
| > the law in some way. ... avoid this kind of scaremongering.
| 	You are reading much more into what I wrote then I intended. I
| did not say that the law forces us to do anything concerning dates.
| Rather, I simply pointed out that *if* we want to have Atom entries
| considered as "publications" for the purposes of establishing prior art,
| we need to make sure that we've got "objective" dates. It is up to us as
| a group to decide if that is or is not important. My personal opinion is
| that it should be considered important and that we "should" ensure that
| we have an objective date. But, I'm only one person...

I'm looking for an argument why this would NOT be considered important, and
not a legal argument, but a well-reasoned one.

---

From: Graham <[email-masked]>
Date: Sun, 26 Sep 2004 02:51:22 +0100

> not a legal argument, but a well-reasoned one.

Pardon? Because there is absolutely nothing in the charter that even 
hints at the legal admissibility of Atom documents being a design 
consideration.

All Atom documents must include pictures of squirrels.

Graham

---

From: "jt" <[email-masked]>
Date: Sat, 25 Sep 2004 21:51:14 -0400

| -----Original Message-----
| From: [email-masked]
| [mailto:[email-masked]]On Behalf Of Mark Pilgrim
| Sent: Saturday, September 25, 2004 8:58 PM
| To: [email-masked]
| Cc: Paul Hoffman / IMC; Atom WG
| Subject: Re: ARMCHAIR LAWYER ALERT (was: Re: Atom's dates may have legal
| implications... At least one "objective date" should be supported.)

| I work with people who have ten times this number.  They still go to
| lawyers for legal advice.
|
| --
| Cheers,
| -Mark

Going to lawyers for legal advice is good advice, but not appropriate for
this list as I'd certainly think it would go without saying.  It's
theoretically possible I way overestimate the intelligence of some-a you
all, but I certainly doubt it.

Leaving lawyers to make tech decisions for tech people is pretty stupid
advice, although an unfortunate necessity at times (for example, when DOJ
has gotten involved).  Basing an opinion strictly on the raw quantity of
patents somebody has is awfully weak reasoning, but I'd expect no more nor
less from an IBM'r working in Software Group or whatever your *nix group
calls itself these days.

~~

Tired, and thaz an excuse for a poorly worded post:  Go ahead and create
your spec without ANY regard for how it might be used if you want.  It's
utility will be what it is, not what you fantasize.  If it CAN'T be used for
common-sense applications, in the legal and otherwise sense, then it won't
be.

No amount of capability to jam a spec down somebody's or everybody's throat
is likely to change these facts and prognostications, afaik.

Yeah, cheers and all that...)-;

---

From: "jt" <[email-masked]>
Date: Sat, 25 Sep 2004 22:03:25 -0400

My recollection of the charter was it was worded rather generally.  You
saying it, the charter, specifically precluded Atom documents from being
legally admissable...?!?  Or was this issue even contemplated when the
charter was drawn up?

I'm guessing, nup.

Listen pal, when more and more lawsuits start popping up revolving around
online publishing and/or (cough) 'blogs', you think YOUR opinion is gonna
matter in court??  Well, in actual fact, the 'facts' will mostly depend on
who has the most money to pay for the 'best' lawyers, but I'd suggest why
not revisit the Charter if that's what it takes.  Or why not leave the
Charter outta the Excuse Dept's discussion, if that's what it is.

I'm not into a long discussion, just offered my view.  Unless I haven't been
clear, I'm bowing out.

Sorry, no picture of squirrels (not that this is an Atom doc), but could
probably get you a link to pic of Ben and Mena, or a link to some funny pics
from BB long ago, if that'll suffice.

| -----Original Message-----
| From: Graham [mailto:[email-masked]]
| Sent: Saturday, September 25, 2004 9:51 PM
| To: jt
| Cc: [email-masked]; 'Atom WG'
| Subject: Re: ARMCHAIR LAWYER ALERT (was: Re: Atom's dates may have legal
| implications... At least one "objective date" should be supported.)
|
|
| On 26 Sep 2004, at 2:39 am, jt wrote:
|
| > I'm looking for an argument why this would NOT be considered
| > important, and
| > not a legal argument, but a well-reasoned one.
|
| Pardon? Because there is absolutely nothing in the charter that even
| hints at the legal admissibility of Atom documents being a design
| consideration.
|
| All Atom documents must include pictures of squirrels.
|
| Graham

---

From: Graham <[email-masked]>
Date: Sun, 26 Sep 2004 03:11:09 +0100

> legally admissable...?!?  Or was this issue even contemplated when the

I'm saying it's not and never has been a consideration. If Bob wants it 
to be a consideration he has to argue for that first before he can 
start discussing changes that need to be made.

My proposed squirrels requirement was entirely serious.

Graham

---

From: "Bill Kearney" <[email-masked]>
Date: Sun, 26 Sep 2004 11:32:14 -0400

> we need to make sure that we've got "objective" dates.

I'd venture that's it's WELL OUTSIDE THE SCOPE of the atom effort to make
decisions about suitability for it's use in legal proceedings.

That said, it's always a good idea to cast an eye toward unexpected impacts
data in one form or another might have on tangentally related use cases.
Evidence presented from otherwise confirmed sources and timelines are
certainly valid tangental use cases.  The key point being 'otherwise
confirmed' as legal status regarding authenticity, dates and the like are
part of the 'well outside' aspect.

> Nonetheless, it is best that we act in full knowledge of

No argument there.  There's always a fine balance between avoiding potential
unintended consequences and scaremongering.  Toss in vague issues regarding
legality and watch the armchair lawyers flail.

If I had linkage regarding efforts to standardize data in legally durable
ways, for archiving or otherwise, I'd post them here.  Do others have such
links they'd care to contribute?  If anything a 'nod toward' the existence
of these efforts would be a fine idea for addition to the spec and/or
implementation guides.

-Bill Kearney

---

From: Tim Bray <[email-masked]>
Date: Sun, 26 Sep 2004 09:15:47 -0700

> item to be considered prior art -- if it contains an "objective" 

All legal issues aside, I have trouble believing that the labels 
"subjective" and "objective" are really very meaningful.  Speaking as 
one who publishes a feed, the *objective* fact is that I put into that 
feed whatever I damn well please, and I don't ask anyone's permission.  
I have regularly futzed with the publication dates, and in fact the 
almost-XHTML language I write 'ongoing' in has an optional header field 
saying "ignore what date the file was created/updated, use this date in 
the feed instead".   Given that this is technically possible, if 
there's anyone (lawyer, geek, or otherwise) who believes that there's 
anything "objective" about a timestamp in a syndication feed, well, I'm 
good buddies with Maryam Abacha and I can set up you with a 
$20.8million bank transfer.... -Tim

---

From: "jt" <[email-masked]>
Date: Sun, 26 Sep 2004 12:26:11 -0400

From the Dept. of Lame Excuses, as I said I wuz tired..  Way past
tarrrrrred, actually.

I knew what I meant, which was more along the lines of:  I respect the
intelligence of you all, mebbe over-estimate it, but certainly not in this
respect.

JES in CASE, if you need medical advice then consult a Doctor...;-D

| -----Original Message-----
| From: [email-masked]
| [mailto:[email-masked]]On Behalf Of jt
| Sent: Saturday, September 25, 2004 9:51 PM
| To: Mark Pilgrim; [email-masked]
| Cc: Paul Hoffman / IMC; Atom WG
| Subject: RE: ARMCHAIR LAWYER ALERT (was: Re: Atom's dates may have legal
| implications... At least one "objective date" should be supported.)

| | -----Original Message-----
| | From: [email-masked]
| | [mailto:[email-masked]]On Behalf Of Mark Pilgrim
| | Sent: Saturday, September 25, 2004 8:58 PM
| | To: [email-masked]
| | Cc: Paul Hoffman / IMC; Atom WG
| | Subject: Re: ARMCHAIR LAWYER ALERT (was: Re: Atom's dates may have legal
| | implications... At least one "objective date" should be supported.)

| It's
| theoretically possible I way overestimate the intelligence of some-a you
| all, but I certainly doubt it.

---

From: "jt" <[email-masked]>
Date: Sun, 26 Sep 2004 12:30:19 -0400

| -----Original Message-----
| From: [email-masked]
| [mailto:[email-masked]]On Behalf Of Graham
| Sent: Saturday, September 25, 2004 10:11 PM
| To: jt
| Cc: [email-masked]; 'Atom WG'
| Subject: Re: ARMCHAIR LAWYER ALERT (was: Re: Atom's dates may have legal
| implications... At least one "objective date" should be supported.)
|
|
| On 26 Sep 2004, at 3:03 am, jt wrote:
|
| > My recollection of the charter was it was worded rather generally.  You
| > saying it, the charter, specifically precluded Atom documents from
| > being
| > legally admissable...?!?  Or was this issue even contemplated when the
| > charter was drawn up?
|
| I'm saying it's not and never has been a consideration. If Bob wants it
| to be a consideration he has to argue for that first before he can
| start discussing changes that need to be made.

Gimme a break.  Talk about aimless quibbling...)-;

You saying it's not being DIRECTLY IMPLIED that something needs considered,
BY the discussing of these proposed changes?!?  The argument that it needs
to be considered MUST PRECEED any further discussion, according to you,
huh..?.  That's gonna be a pretty fallow discussion, is my 'guess', absent
the discussing of what changes would provide what features and whether they
are worth while.

| My proposed squirrels requirement was entirely serious.
|
| Graham

Okay then, -1.

;-D

---

From: "jt" <[email-masked]>
Date: Sun, 26 Sep 2004 12:34:41 -0400

Due to prior brutal back-stabbing, several years ago, by Mr. Kearney..

..Well I have to fight a tendency to want to intellectually rip his
semi-lame discussion apart into shreds and spitting it back to him.  That
said, I find it only mildly irritating that the only thing I could reply was
that the flailing of armchair lawyers has been largely ABSENT, in actual
fact.  At least over the past couple days.. no guarantees where it will go
from here.

I'm outta here, (no time nor "green energy" nor other kinds to do this
well,) having just now clarified some (perhaps) mistaken beliefs (I
believe...;-)!  After one more...;-D

| -----Original Message-----
| From: [email-masked]
| [mailto:[email-masked]]On Behalf Of Bill Kearney
| Sent: Sunday, September 26, 2004 11:32 AM
| To: [email-masked]
| Cc: 'Atom WG'
| Subject: Re: ARMCHAIR LAWYER ALERT (was: Re: Atom's dates may have legal
| implications... At least one "objective date" should be supported.)
|
|
|
| > You are reading much more into what I wrote then I intended. I
| > did not say that the law forces us to do anything concerning dates.
| > Rather, I simply pointed out that *if* we want to have Atom entries
| > considered as "publications" for the purposes of establishing prior art,
| > we need to make sure that we've got "objective" dates.
|
| I'd venture that's it's WELL OUTSIDE THE SCOPE of the atom effort to make
| decisions about suitability for it's use in legal proceedings.
|
| That said, it's always a good idea to cast an eye toward
| unexpected impacts
| data in one form or another might have on tangentally related use cases.
| Evidence presented from otherwise confirmed sources and timelines are
| certainly valid tangental use cases.  The key point being 'otherwise
| confirmed' as legal status regarding authenticity, dates and the like are
| part of the 'well outside' aspect.
|
| > Nonetheless, it is best that we act in full knowledge of
| > the consequences of our decisions.
|
| No argument there.  There's always a fine balance between
| avoiding potential
| unintended consequences and scaremongering.  Toss in vague issues
| regarding
| legality and watch the armchair lawyers flail.
|
| If I had linkage regarding efforts to standardize data in legally durable
| ways, for archiving or otherwise, I'd post them here.  Do others have such
| links they'd care to contribute?  If anything a 'nod toward' the existence
| of these efforts would be a fine idea for addition to the spec and/or
| implementation guides.
|
| -Bill Kearney
|
|

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 26 Sep 2004 16:32:27 -0400

Tim Bray wrote:
> I have trouble believing that the labels "subjective" and 
> "objective" are really very meaningful.
	I realize that these probably aren't the best words. Hopefully, you
have at least a sense of what the intended difference is. If you can suggest
better words, please do. The distinction I'm trying to make is:
	1) A date which one would expect to accurately indicate some moment
such as the actual moment that the publishing software released the item to
readers, and
	2) A date which is associated with the published item by the
publisher as part of the subjective or editorial content generation process.
i.e. a date which is "part of" the content rather than the timestamp of an
instant in the process of publishing.
	The distinction would be something like that which differentiates
dates in email message headers from those in the body of a message.
	Of course, anyone in this business will realize that there are
endless ways in which dates or any of the other content in our messages can
be "futzed with." My desire is, however, to have at least one date in which
one can have confidence, absent chicanery or implementation errors, that the
date indicates the date of publication. i.e. like the dates in mail message
headers. We know that they can be faked, however, we (and apparently at
least some folk at the USPTO) will trust these dates as accurate in the
absence of specific evidence to the contrary.
	Our recent experience with the "feed" instance-manipulation method
for RFC3229 is an interesting example. Imagine that someone attempted to
patent the method! (No, it won't be me.) But, when was the feed IM method
first described? As far as I know, there are no printed-on-paper
publications of the method -- rather it has only been described in blogs and
email messages. Patent office procedure (not the law per se -- just the
printed procedures in the MPEP) seems to indicate that an examiner might
consider the date in the RSS and/or Atom files as indicative of the date of
publication -- as long as they believe that the date on the entry is
actually related to the date of publication and not just some random date
pulled out of the air by the publisher...
	My sense is that more and more of our technical innovations (big and
small) will be documented first and primarily in this new writable web that
we're creating with RSS, Atom, Blogging, etc. Whether or not we think we can
address any legal issues that might exist, it seems to me that we should at
least give some thought to doing things that might allow people to have ways
to judge the timeliness of items they read or the sequence in which items
are published in different feeds and within feeds. For an exotic but
non-legal application of concern for temporal sequence, consider the various
bits of research that focus on "meme-tracking" or "influence" in the
blogosphere. The authors of most of these studies have regularly complained
that they can't rely on the dates in RSS files because of missing timezones,
variations in format, or subjectivity of the dates. Those authors also tell
us that having good dates would have increased the accuracy of their results
and thus the knowledge that we obtain from them... "Published date" would
have utility for these applications. Can these be the only contexts in which
published date would be useful? I don't think so.
	If you have better wording then "objective" and "subjective" to say
what I'm trying to say, please offer the words. I am not in any way wedded
to these two words -- but I think the distinction that I'm trying to
indicate is actually an important and relevant one.

		bob wyman

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 26 Sep 2004 17:21:35 -0400

Bill Kearney wrote:
> If I had linkage regarding efforts to standardize data in legally
> durable ways, for archiving or otherwise, I'd post them here.  Do
> others have such links they'd care to contribute?  If anything a 
> 'nod toward' the existence of these efforts would be a fine idea
> for addition to the spec and/or implementation guides.
	This stuff usually involves digital signatures which can, of course,
be a bit of a nuisance...
	The two time related problems usually addressed in such systems are:
	1. Preventing modification of the sequence of recorded events of
interpolation of new events into an event stream. (Search Google or the
USPTO for "secure logging" to find references)
	2. Certified "timestamping" of events. (i.e. a date of publication)

	Sequence oriented solutions will usually follow a pattern like the
following: Create a first entry and from that entry compute a signature.
Then, create a second entry. Append the signature from the first entry to
the second and then generate a second signature. Create a further entry,
append the previous signature to it and generate another signature... etc.
The "previous signature" carries forward into each subsequent signature a
"summary" of all the previous items and signatures.
	A secure logging system allows you to detect tampering with the
stream (usually a log file but could be any "feed") by ensuring that any
change in the sequence of records or the insertion of new records will break
the chain of signatures.
	Certified timestamp systems usually require there to be a trusted
secure timestamping service to which applications send data objects to be
time stamped. Basically, you send a blob of data to the service and it
returns a signature and a timestamp. The timestamp will have been "appended"
to the blob and thus its influence is recorded in the signature. The
combination of timestamp, blob, and signature allows you to trust statements
made about when the item was timestamped. Lighter weight systems allow you
to avoid sending the actual data blob. What you do is generate a signature
for some data and then get the service to timestamp and sign the signature.
This reduces bandwidth requirements and doesn't make data visible as it
transits the network.
	These are all very basic applications of signature technology. I'm
not suggesting that we require any of this stuff for Atom.

		bob wyman