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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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

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

> | 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/ ?
> 

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

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.

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

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

- James

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]