ietf
[Top] [All Lists]

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

2006-08-18 09:41:59
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

Frank Ellermann wrote:
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



_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf