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@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf