Subject: No consensus on PaceDateModified

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 29 Oct 2004 16:21:15 -0700

Wearing my co-chair hat, I am going to declare non-consensus on 
PaceDateModified. (Friday afternoon is a good time to state the 
obvious.) There are plenty of different people with different 
technical objections to it.

It's time for the WG to move on to the other items on the current 
work rotation:

At 1:30 PM -0400 10/28/04, Sam Ruby wrote:
>Making link not required (in some circumstances):
>
>   PaceContentOrLink
>   PaceOptionalAlternateLink
>
>Error reporting:
>
>   PaceErrVerb
>   PaceServiceError
>
>Host from mod-wiki:
>
>   PacePersonConstructs
>

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Robert Sayre <[email-masked]>
Date: Sat, 30 Oct 2004 19:22:42 -0400

Hey all,

Let's stop talking about dates.

I'm uncertain that atom:host is appropriate as a property of 
atom:person, but I accept the element has broadly applicable utility and 
is appropriate for inclusion in the core. Couldn't it also be a property 
of atom:entry? Seems like it's just in atom:person to satisfy a 
requirement of atom:person.

Just to throw out a modification out there:

x.x.x "atom:from" Element

The "atom:from" element's content conveys information associated with 
the network origin of an Atom Entry. atom:entry elements MAY contain one 
atom:from element. Its content MUST be a domain name [RFC1035], a 
dotted-decimal IPv4 address, or a colon-delimited IPv6 address.

Robert Sayre

Paul Hoffman / IMC wrote:

> obvious.) There are plenty of different people with different technical 
> objections to it.
> 
> It's time for the WG to move on to the other items on the current work 
> rotation:
>

---

From: Eric Scheid <[email-masked]>
Date: Sun, 31 Oct 2004 10:30:17 +1000

> 3.2.4 "atom:host" Element
> 
> The "atom:host" element's content conveys an IP address associated with the
> Person construct. Person constructs MAY contain an atom:ipaddr element, but
> MUST NOT contain more than one. Its content MUST be a domain name [RFC1035] or
> a dotted-decimal IPv4 address or a colon-delimited IPv6 address.

+1 

simple enough, surely can't be controversial.

also allows for machine generated content without requiring human-style
identity attributes (email address, name)

e.

---

From: Eric Scheid <[email-masked]>
Date: Sun, 31 Oct 2004 10:34:14 +1000

>> Replace the following paragraph in the 5.2 "atom:link" Element in the
>> atom-format-02 draft:
>>       atom:entry elements MUST contain at least one atom:link element
>>       with a rel attribute value of "alternate".
>> 
>> With the following:
>>       atom:entry elements that contain no child atom:content element
>>       MUST contain at least one atom:link element with a rel attribute
>>       value of "alternate".

+1 

I don't forsee any problems with this idea. The wording of the spec text
might need to change if we change how atom:link elements work.

e.

---

From: "Roger B." <[email-masked]>
Date: Sat, 30 Oct 2004 20:07:29 -0500

> x.x.x "atom:from" Element

+1... I think that kind of thing is probably a better fit at the entry level.

--
Roger Benningfield

---

From: Eric Scheid <[email-masked]>
Date: Sun, 31 Oct 2004 12:35:39 +1000

> dotted-decimal IPv4 address, or a colon-delimited IPv6 address.

Sounds interesting ... but what role does that network origin play in the
entry? That is, what role, other than <author> or <contributor>?

e.

ps. +1 on expressing the idea as spec text. If only I was more considerate
to do so more often.

---

From: Joe Gregorio <[email-masked]>
Date: Sat, 30 Oct 2004 21:45:24 -0400

> requirement of atom:person.

I've read and re-read the above paragraph several times and
can't make heads or tails of the point you are trying to make.
Could you try again?

> dotted-decimal IPv4 address, or a colon-delimited IPv6 address.

I don't think atom:host is a great element name, but I don't 
particularly like atom:from either, too reminiscint of email.

Why not atom:client-address?

Either way, I am +1 on the element, it is definitely required by
Wikis, usenet posts and anonymous comments. 

I am, however, opposed to the whole thing being named a 
'Person' construct. I would prefer 'Author' or some other 
name that didn't imply a 1-1 correspondence with a human
being. 

    -joe

-- 
Joe Gregorio        http://bitworking.org

---

From: Robert Sayre <[email-masked]>
Date: Sat, 30 Oct 2004 21:58:47 -0700

>can't make heads or tails of the point you are trying to make.

I wrote "atom:person" but meant "a Person Construct". The Pace defines 
atom:host as component of a Person Construct, and I thought a child of 
atom:entry might be more appropriate, since the network origin of a post 
might have nothing to do with the "person", but is definitely the last 
known intermediary that transmitted the entry.

>particularly like atom:from either, too reminiscint of email.

I chose "from" precisely because of that similarity :),  but I don't 
particularly care what the element is called.

Robert Sayre

---

From: Joe Gregorio <[email-masked]>
Date: Sat, 30 Oct 2004 22:16:00 -0400

> known intermediary that transmitted the entry.

Which is why I think we should change the name from 
Person Construct to Author Construct, i.e. we are recording 
information that, as much as is possible, indicates
the author of the entry.

I do see your point, that someone could 
have atom:name, atom:uri and atom:email
in their entry, which identify the author quite
well, and then on top of that atom:host could
be added but if it only represents the last 
intermediary that transmitted the entry then
it doesn't really add much. In fact it could
detract from the other information given.

I think we need some wording that indicates atom:host
is a Person Construct Element Of Last Resort.

    -joe

---

From: Danny Ayers <[email-masked]>
Date: Sun, 31 Oct 2004 10:30:22 +0100

> name that didn't imply a 1-1 correspondence with a human

I think both comments are pointing in roughly the same direction -
take the element out of the Person Construct and apply it directly to
the entry (or feed).

+1 to such a modification
+ to atom:from or atom:client-address in preference to atom:host,
they're more explicit

I think Joe's right about the correspondence with human beings, the
mapping doesn't seem right, and might lead to incorrect assumptions in
implementations. Separating the person from their role (e.g. 'author')
is a possibility, one which has proved successful in FOAF.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Joe Gregorio <[email-masked]>
Date: Sun, 31 Oct 2004 08:04:30 -0500

> take the element out of the Person Construct and apply it directly to

Personally, I wasn't trying to argue for that, I was arguing 
for just the opposite, that atom:host was just another
piece of information identifying the author of the entry and so belonged
in the 'Person Construct'.

  -joe

---

From: Robert Sayre <[email-masked]>
Date: Sun, 31 Oct 2004 12:04:58 -0800

>in the 'Person Construct'.
OK, we generally agree.

* we both want the element
* we both want to call it something different

but

I think it should be in atom:entry. The fact that wikis sometimes 
display that information in the author field doesn't mean it has 
anything to do with identity. I don't think I will change my position on 
this issue, but I'll go along with whatever the group decides.

Robert Sayre

---

From: Danny Ayers <[email-masked]>
Date: Sun, 31 Oct 2004 20:15:04 +0100

> >in the 'Person Construct'.

Sorry I suggested otherwise.

> * we both want to call it something different

Ditto.

> this issue, but I'll go along with whatever the group decides.

I agree. This isn't information about the the author, the same author
may be associated with different values of client address from one
entry to the next. The primary use will no doubt be to tell if two
entries have come from the same person, but that's a step the other
side of a very loose heuristic.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Bill de hÓra <[email-masked]>
Date: Sun, 31 Oct 2004 22:45:41 +0000

Robert Sayre wrote:

> I think it should be in atom:entry. 

This has been my position.

> The fact that wikis sometimes 

I would really like to see this item kicked out of the Author/Person 
construct. IP addresses identify computers, at best. Putting it in a 
Person construct is sloppy.

cheers
Bill

---

From: Robert Sayre <[email-masked]>
Date: Sun, 31 Oct 2004 18:14:16 -0500

Close PaceErrVerb. It's a nice idea that will never get done in this WG, 
if it's even possible at all.

PaceServiceError could work. However, we have no specified notion of 
Errors or Conformance, so it's tough to tell whether the proposal would 
be helpful. If we come up with a status quo position on conformance, 
then I would definitely want it in 1.0. A Dead Letter Office is better 
than nothing. If we decide on something better, then it could be 
something added later if required.

Robert Sayre

---

From: Eric Scheid <[email-masked]>
Date: Mon, 01 Nov 2004 10:38:23 +1100

> Person construct is sloppy.

for the wiki case, the author/contributor is very likely human ... but we
shouldn't assume that for all authors/contributors are human. It's quite
possible that it could be an actual machine.

e.

---

From: Walter Underwood <[email-masked]>
Date: Sun, 31 Oct 2004 16:53:37 -0800

> possible that it could be an actual machine.

Press releases have organizations for authors, not persons.

Data feeds (a streamflow meter) have machines as authors.

If we want a model for authors, I recommend starting with library practice
and trying to build a schema from that. Note that libraries don't try to
model the relationships between authors, noms de plume, and actual people.
Instead, they have an authoritative list for author names. That is, we
always spell "Shakespeare" the same way, the way it is in this list.

To understand current library practice, I'd probably start with
the Library of Congress pages on MARC (MAchine Readable Cataloging).

  <http://www.loc.gov/marc/umb/>

The MARC format has a real COBOL/magtape feel to it, but it is a solid,
functional standard.

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: Martin Duerst <[email-masked]>
Date: Mon, 01 Nov 2004 09:27:11 +0900

>> a dotted-decimal IPv4 address or a colon-delimited IPv6 address.

- It's weird to have the IP address either in the atom:ipaddr element or in the
   atom:host element. I think it's better to use host for domain names (including
   IDNs!), and ipaddr for IP addresses.

- For IP addresses, we should consider whether we might want to also allow
   the IPvFuture syntax from
   http://www.ietf.org/internet-drafts/draft-fielding-uri-rfc2396bis-07.txt,
   just to be on the safe side.

Regards,   Martin.

---

From: Eric Scheid <[email-masked]>
Date: Mon, 01 Nov 2004 13:01:39 +1100

> Press releases have organizations for authors, not persons.

Depends on what you mean by "persons". Corporations are persons, as per a
legal definition, but that's a bit out there. Meanwhile, I'm sure there are
a few blogs out there where the putative author "person" is not a human:
dogs, cats, Mr Sun, etc.

As it is, while the spec refers to a "person construct", you won't find a
<person> in any atom feed ... they are all <author> or <contributor> ... and
that's the intent there (if I may be so brazen ;-)

I think "person construct" is so much simpler than "source of content
entity"

e.