Robert Sparks wrote: > [snip] > -------- > Issue 1: > It's not clear why this is Experimental from the current document text > (research, limited applicability,...?). > Would an applicability statement make sense? >
As Lisa indicated, this is experimental largely because it's not clear how this is going to be used long term. Many RSS and Atom feed publishers currently already place licensing information in their feeds; it's just not clear how many folks are actually utilizing that information. > -------- > Issue 2: > > What's covered by the license claim is still hard to pull out of the > document - the paragraphs added for version 07 help. The following > paragraph starts to capture the intent (I think), but the document would > benefit from making this a more immediate and central point: > >> Because entries contained within a feed may originate from other >> sources, "license" link relations appearing within a feed apply to >> the metadata of the containing feed element only and do not extend >> over the metadata or content of the contained entries. > > I read this to say that the license covers only those bits inside the > <feed> element that contains the license link, but no bits inside any > <entry> elements that <feed> element might contain. > > This is the real requirement and should be stated normatively. The > following paragraphs are justification for the requirement. The point > would be better made if they didn't have the normative text they > currently have. (Unless I've missed the point off the document). No, you've got it right. I've tried a variety of different ways to word this and still haven't quite been able to come up with something that Just Works. > ------ > Issue 3: > > It would help a lot to describe (even if that means speculate) what a > person or automaton will do when consuming this new data. I'm having a > hard time guessing what this would be used for (assuming I've understood > the requirement as stated in issue 2 correctly). > Yes. This mechanism is largely intended to support the ability to index and search content based on how it is licensed and to support rich display of license metadata. Automated decision making based on this data (and in particular decisions which may have legal ramifications) should be discouraged due to the questionable legal standing of such licenses. I've already had a couple of discussions with folks on this and will be adding statements discussing all this. > ------ > Issue 4: > > This example is confusing: > >> Multiple "license" link relations specifying different href attribute >> values are are considered to be mutually exclusive alternatives. For >> instance, if an entry specifies both a Creative Commons License and >> the General Public License (GPL), the entry is considered to be >> licensed as either Creative Commons OR GPL as opposed to Creative >> Commons AND GPL. > > I think you're trying to say that the format will allow your <feed> > meta-data to be dual- or multi-licensed and the example is showing how > it can express that. If I'm correct, saying it that way might reach a > wider audience. Finding a concrete example of something you might > dual-license in such a way would help. I'm having a hard time coming up > with something that would appear with the dual-license structure you > show as an example here. > Yeah, this is another one that I've gone back and forth on trying to get the wording right. Your suggestions are helpful, thank you. > (btw - if the text above survives, there is a duplicated "are" in the > first sentence) Noted. - James _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
