Subject: Re: Last Call: 'Atom License Extension' to Experimental RFC (draft-snell-atompub-feed-license)

From: Frank Ellermann <[email-masked]>
Date: Tue, 15 Aug 2006 12:29:34 +0200

The IESG wrote:

> - 'Atom License Extension '
>    <draft-snell-atompub-feed-license-06.txt>

| Licenses associated using these mechanisms MAY or MAY not be
| machine readable 

Isn't "MAY" always the same as "maybe not" ?  I'd read a "MAY
or MAY not" as "maybe not or maybe", and in that case I wonder
why you talk about it.

| The IRI specified by the link's 'href' attribute SHOULD be
| dereferencable

Apparently RFC 4287 uses the term <atomUri> wrt href, and it
says that a dereferencable IRI is in fact an URI as specified
in 3987.  In other words, how about s/IRI/URI/ ?

| the presence of a license link relation within an Atom feed
| element does not extend a license over the various contained
| entry elements.

What else is this rel="licencse" about, if it's not about the
contained elements ?  

| Likewise, the presence of a license link within an Atom
| source element does not extend a license over the
| informational content of the containing entry.

Same question, what's its purpose if it's unrelated to the
entry ?  I'd get it if it's some kind of default for anything
below the next containing element.
 
If that's what you want a problem could be an overall feed
default with entries from other sources not providing their
own rel="license".

Maybe you could say that any atom:author or atom:rights not
matching the atom:author or atom:rights of the rel="license"
breaks the relation.  Or maybe it needs an explicit reset to
an unknown state, rel="licence" href="" (ugly, better solve
it in the spec.)

Frank

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: James M Snell <[email-masked]>
Date: Tue, 15 Aug 2006 08:08:00 -0700

> or MAY not" as "maybe not or maybe", and in that case I wonder

Gah, I thought I'd caught all of those.  Thanks.

> in 3987.  In other words, how about s/IRI/URI/ ?

Whenever RFC4287 says "atomUri" it means IRI.  I understand what you're
saying, but the value of the href value may, in fact, be an IRI.

> What else is this rel="licencse" about, if it's not about the

Note that is says contained *entry* elements. It applies to all other
contained elements.  In RFC4287, feeds and entries exist independently
of one another.  A feed produced by one entity can contain entries
produced by a different entity (this is commonly the case in aggregation
feeds such as the one you'll find at
http://planet.intertwingly.net/atom.xml.  It is inappropriate for one
content publisher to extend a license over content produced by another.

An analogous scenario is when I distribute some piece of open source
software under the Apache license.  The zip I distribute contains the
ASF LICENSE file. It also happens to contain jars for a number of
dependencies from other projects, all of which are individually licensed.

> an unknown state, rel="licence" href="" (ugly, better solve

I don't see how this buys us anything other than increased complexity.

- James

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 16 Aug 2006 10:03:26 +0200

James M Snell wrote:

>> how about s/IRI/URI/ ?
 
> Whenever RFC4287 says "atomUri" it means IRI.  I understand
> what you're saying, but the value of the href value may, in
> fact, be an IRI.

The only case where I watched this before were some XMPP RFCs,
and there it always worked in a way that clients never need
to worry about it:  Either it is already an URI, or it's sent
to a server who's supposed to know how to translate IRIs to
URIs.  Clients don't need to know how this works.  Apparently
different for atom, I missed that point in RFC 4287.  You've
of course no reason to be more restrictive for rel="license".

> An analogous scenario is when I distribute some piece of open
> source software under the Apache license.  The zip I
> distribute contains the ASF LICENSE file. It also happens to
> contain jars for a number of dependencies from other
> projects, all of which are individually licensed.

Okay, but your license would cover something "real" in the zip,
files you have created.  It's not only about your arrangement
of content collected from 3rd parties.  Or is that precisely
the idea of the rel="license" for a feed ?

Then folks like me could need a hint that what they really want
is a rel="license" for each of their own entries, because there
is no global default.

Frank

---

From: James M Snell <[email-masked]>
Date: Wed, 16 Aug 2006 08:12:35 -0700

Frank Ellermann wrote:
> [snip]

Yes. I've clarified this in the next draft.  Feed licenses cover the
metadata of the feed including the selection and arrangement of entries.
 For instance, I may put up a service that automatically ranks blog
entries from various sites based on various criteria and produces a feed
that represents the top ten highest ranking entries.

> is a rel="license" for each of their own entries, because there

Yes, hopefully I've clarified this in the new draft that should be
published shortly.

Thank you for taking the time to review the draft and offer comments.

- James

---

From: James M Snell <[email-masked]>
Date: Fri, 18 Aug 2006 09:40:33 -0700

Hello Frank, I've updated the spec with what I hope is clearer language.

http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-license-07.txt

I'd be greatful if you could take another look and let me know if this
is an improvement, at your convenience of course.

- James

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 22 Aug 2006 16:27:00 +0200

James M Snell wrote:

> let me know if this is an improvement

Hard to judge, now that I know what it's supposed to
do it's "obvious"... :-)  I think it's clearer now:

Jane's feed is "by+nc", the example entry is "by", and
so a commercial service can copy this entry as long as
the author (Jane) is credited.

If that's correct I got it.  Unrelated minor point, you
have "MUST NOT contain more than one with the same
combination of href and type attribute values."

Is that the same as "more than one license relation with
the same combination of href and type attribute values
is pointless" ?  If yes you could eliminate the MUST NOT.

...or maybe not, I just see that RFC 4287 has a similar
MUST NOT about rel="alternate" (that's even the default
relation), odd.

RFC 4287 states that the IANA registry should be BELOW
http://www.iana.org/assignments/relation/ , it's now IN
http://www.iana.org/assignments/link-relations.html

I wonder if I should change rel="bookmark" to rel="self"
on ordinary Web pages. 

Frank

---

From: James M Snell <[email-masked]>
Date: Tue, 22 Aug 2006 08:13:26 -0700

> do it's "obvious"... :-)  I think it's clearer now:

;-)

> combination of href and type attribute values."

Yes, that's correct.

> MUST NOT about rel="alternate" (that's even the default

Yeah, a primary goal of mine is to remain consistent with rfc4287.

- James