Subject: [Gen-art] Genart LC review of draft-snell-atompub-feed-license-07.txt

From: Robert Sparks <[email-masked]>
Date: Mon, 28 Aug 2006 14:12:32 -0500

I am the assigned Gen-ART reviewer for draft-snell-atompub-feed- 
license-07.txt

For background on Gen-ART, please see the FAQ at <http:// 
www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.

Please resolve these comments along with any other Last Call comments  
you may receive.

Summary:
This is an AD-sponsored individual submission for consideration as an  
Experimental RFC.
The draft has a few open issues (mostly around clarity) that should  
be resolved before publication.

Overall, I found this document confusing. I had to go through it  
several times before I felt like I knew what it was trying to  
accomplish. With that done, I can't figure out why it's trying to do  
what it's doing.

--------
Issue 1:
It's not clear why this is Experimental from the current document  
text (research, limited applicability,...?).
Would an applicability statement make sense?

--------
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).
------
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).

------
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.

(btw - if the text above survives, there is a duplicated "are" in the  
first sentence)
------

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

---

From: James M Snell <[email-masked]>
Date: Mon, 28 Aug 2006 15:51:52 -0700

Robert Sparks wrote:
> [snip]
> --------
> Issue 1:
> It's not clear why this is Experimental from the current document text
> (research, limited applicability,...?).

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.

> paragraph starts to capture the intent (I think), but the document would
> benefit from making this a more immediate and central point:
> 

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.

> 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.

>>    Multiple "license" link relations specifying different href attribute
>>    values are are considered to be mutually exclusive alternatives.  For
> 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

Noted.

- James

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 28 Aug 2006 13:37:19 -0700

> Would an applicability statement make sense?

Perhaps.  There are two reasons why I suggested Experimental:
	1.  I'm not entirely convinced what the right choices for the scope  
of a license are.  There are usability and legality concerns.
	2.  We (James and I) don't know of intended consumer applications of  
license information in feeds.  There are a couple tools that are or  
will soon be capable of putting license info in, but who will go  
looking for it?   (e.g. search engines that can filter out/in certain  
kinds of licenses)

So if we (IETF) publish this as Experimental and it turns out to be  
useful, we'll see consumer applications and then we'll get more  
information on what are the most appropriate choices for the scope of  
the license metadata.

For other Experimental documents, I've seen general statements added  
along the lines of "It's not yet certain what use this will be put  
to, so implementations and feedback are encouraged"... but isn't that  
almost to be assumed for Experimental docs?

>
> --------
> 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:
>
> 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.
>
> 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).

I think I agree with this.

thanks for your comments,
Lisa

---

From: Robert Sparks <[email-masked]>
Date: Mon, 28 Aug 2006 19:40:21 -0500

On Aug 28, 2006, at 3:37 PM, Lisa Dusseault wrote:

> 	1.  I'm not entirely convinced what the right choices for the  
> scope of a license are.  There are usability and legality concerns.
> 	2.  We (James and I) don't know of intended consumer applications  
> of license information in feeds.  There are a couple tools that are  
> or will soon be capable of putting license info in, but who will go  
> looking for it?   (e.g. search engines that can filter out/in  
> certain kinds of licenses)
>
> information on what are the most appropriate choices for the scope  
> of the license metadata.
>
> For other Experimental documents, I've seen general statements  
> added along the lines of "It's not yet certain what use this will  
> be put to, so implementations and feedback are encouraged"... but  
> isn't that almost to be assumed for Experimental docs?
>
>

To make sure I was clear - I wasn't objecting to Experimental - I  
just think it would help to give a little insight into the choice.
James' comment about many publishers including something like this  
already without a common agreement on how it
might be used would be a good thing to capture so when the  
implementor sees the "Experimental" red flag, there's something
providing focus on what they should think about when trying to use  
it. Your comment above on getting more information is also
worthy of including in the document.

RjS

---

From: James M Snell <[email-masked]>
Date: Mon, 28 Aug 2006 20:52:22 -0700

Thank you very much for taking the time to review the draft and to
comment.  I'll be adding these bits to a new draft later this week.

- James

Robert Sparks wrote:
> [snip]
> To make sure I was clear - I wasn't objecting to Experimental - I just
> think it would help to give a little insight into the choice.
> might be used would be a good thing to capture so when the implementor
> sees the "Experimental" red flag, there's something
> providing focus on what they should think about when trying to use it.
> Your comment above on getting more information is also