Subject: Link Extensions. Need "md5" or some kind of hash.

From: Bob Wyman <[email-masked]>
Date: Tue, 4 May 2010 13:54:59 -0400

I find that I have a real need for the "md5" Link rel mechanism defined in
James Snell's old Atom Link
Extensions<http://tools.ietf.org/html/draft-snell-atompub-link-extensions-02>draft
or something functionally equivalent. Basically, what I need to do is
ensure that the "src" attribute on an atom.content element is pointing to a
known version of a resource rather than simply to any resource that has the
same URL as in the src attribute. I'm then going to sign the Atom entry that
contains this "by ref" content element.

I've looked at the HTML5 RelExtentions
Wiki<http://wiki.whatwg.org/wiki/RelExtensions> but
don't see anything there that looks like it does the job.

Has anyone else needed hashed links in Atom? If so, what approach did you
use to provide them? Is anyone aware of plans to introduce an "md5" or
equivalent attribute to the HTML5 list?

bob wyman

---

From: Peter Keane <[email-masked]>
Date: Tue, 4 May 2010 13:57:02 -0500

On Tue, May 4, 2010 at 12:54 PM, Bob Wyman <[email-masked]> wrote:
> James Snell's old Atom Link Extensions draft or something functionally
> equivalent. Basically, what I need to do is ensure that the "src" attribute
> on an atom.content element is pointing to a known version of a resource
> rather than simply to any resource that has the same URL as in the src
> attribute. I'm then going to sign the Atom entry that contains this "by ref"
> content element.

There have been a number of discussion of such in the past on
atom-syntax -- usually focussed on James Snell's link extension draft.
 You might also look at the Atom-Media extensions that came out of
activity streams work [1] -- no md5, but that'd be an obvious
addition.  I think the MediaRSS spec is widely used, and it does have
an md5 as a <media:hash> element w/ @algorithm [2].  When I have had
need for it, I generally used a locally name-spaced attribute on
atom:link, although that's obviously a sub-optimal solution.

The RESTful implications of such a use are (I think) somewhat
interesting.  It creates a tight-binding (early binding) that is
somewhat at odds w/ the late-binding nature of REST.  I think that's
why attributes on atom:link are always "advisory" and overridable (see
RFC4287 sec. 4.2.7.3 and 4.2.7.6) by what's actually at the end of the
wire.  Another (probably impractical) approach is to have the resource
as actual content instead of just a link.

--peter keane

[1] http://martin.atkins.me.uk/specs/atommedia
[2] http://video.search.yahoo.com/mrss

> I've looked at the HTML5 RelExtentions Wiki but don't see anything there
> that looks like it does the job.

---

From: James Snell <[email-masked]>
Date: Tue, 4 May 2010 12:08:40 -0700

I've noticed that Google has actually started using an etag attribute
in their API which has roughly the same concerns about binding, etc.
I'm a big fan of including as much metadata as practical possible
without going overboard and think that a hash attribute (or set of
hash attribute options not limited to md5) would be a good thing in
general. I've been starting to dust off a few of the old I-D's this
week starting with the tombstones draft (again) so perhaps I'll also
pull out that link extensions draft and give it a do-over.

- James

-- 
- James Snell
  http://www.snellspace.com
  [email-masked]

---

From: Niklas Lindström <[email-masked]>
Date: Tue, 4 May 2010 20:59:42 +0200

Hi Bob!

> attribute. I'm then going to sign the Atom entry that contains this "by ref"
[...]
> use to provide them?

I'm actually using the le:md5 just as described in that draft. And
pointing the publishers I want checksums from to it. It was either
that or put up a page myself to link to with basically the same idea,
and I figured the draft is already and will be online for quite some
time, and easier to find than anything I would throw together. (I
figured I could go with something based in RDF-land as well, but
that's just as arbitrary from an Atom perspective.) Of course, the
draft is stale and all, but I've found nothing more "standard". I
asked here a couple of times over the past two years, and there is
some interest, but I haven't heard about any definite alternative.

Note that I don't actually recommend this practise, I just didn't find
anything better, and haven't (yet) attempted to e.g. "adopt" the draft
(which could be a way forward I guess, if such a thing is possible).
Or defined an alternative elsewhere online.

Best regards,
Niklas

---

From: Peter Keane <[email-masked]>
Date: Tue, 4 May 2010 14:12:51 -0500

> pull out that link extensions draft and give it a do-over.

Very much appreciated.  Glad to see you back on atom-syntax.

--peter

---

From: Niklas Lindström <[email-masked]>
Date: Tue, 4 May 2010 21:27:13 +0200

James,

> pull out that link extensions draft and give it a do-over.

that is wonderful! I'm really happy to hear you're doing this. Let me
know if I can help in any way.

Specifically, I think le:md5 is nice to keep since it corresponds to
the HTTP Header. But I agree it would be good with support for more
algorithms. Either as multiple attributes (le:sha1, le:sha2 etc), or
le:checksum + le:algorithm. Or perhaps something akin to the value
space of <http://open.vocab.org/docs/hasChecksum>.

Best regards,
Niklas

---

From: Bob Wyman <[email-masked]>
Date: Tue, 4 May 2010 15:44:47 -0400

James,
Breathing life back into the draft would be greatly appreciated.

At the risk of boring people, I'd like to expand a bit more on what I'm
trying to accomplish. There might be other things that I've missed...

As some are aware, some of us have been working on the
Salmon<http://www.salmon-protocol.org/>protocol and specifically on
Salmon "Magic
Signatures<http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html>"
which are an attempt to provide a *very* simple mechanism for signing
content without losing too many of the benefits of the older, more complex
methods. The Magic Signature draft specifically addresses the signing of
Atom Entries used with Salmon and, in most cases, there is an implicit
assumption that the "content" of the entries will be essentially "pass by
value" or, in other words, included within the Magic Signature itself. The
problem I've got is that there are times when "pass by ref" makes a great
deal more sense. The signed object might be very large, might have security
or copyright constraints that make copying difficult, etc. So, I'd like to
use the "src" attribute to point to a remote resource and then to use a hash
function to essentially pull the remote data into the scope of the
signature. For this, I need to be able to specify the specific version of
the resource pointed to. (The version is, of course, implicit when I pass by
value -- by embedding the signed data in the Magic Signature.)

What I'm looking for is something that I might use in much the same way that
I would use an "artifact<http://en.wikipedia.org/wiki/SAML_2.0#Artifact_Format>"
in SAML. I realize that I could just adopt the SAML method, but, I'm
attracted by the idea that an Atom based system may not need to do what SAML
did in inventing a whole different datastructure for use when signing data
by-ref.

bob wyman

---

From: Richard Salz <[email-masked]>
Date: Tue, 4 May 2010 16:40:26 -0400

I have some concerns about hashing XML without doing some kind of 
canonicalization first -- namely, will it work in practice?  I don't know. 
 If it does, great, c14n is generally expensive.

We wrote a draft I-D on security processing for Atom nearly a year ago. 
Not much interest anywhere, but I still think it's pretty good. :)

        https://datatracker.ietf.org/idst/status.cgi?submission_id=17333

        /r$

--
STSM, WebSphere Appliance Architect
https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/

---

From: Bob Wyman <[email-masked]>
Date: Tue, 4 May 2010 16:50:27 -0400

Richard Salz <[email-masked]> wrote:
> I have some concerns about hashing XML without
> doing some kind of canonicalization first
Right. That's one of the sweet things about Salmon's Magic
Signature<http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html>stuff.
The idea is that you punt on canonicalizing the XML by just dumping
it into a base64 blob. You then sign the blob, not the XML. As a result, all
the canonicalization issues disappear and you've got a nice, easy to
implement signature method.

See the draft for details:
http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html

bob wyman

---

From: Richard Salz <[email-masked]>
Date: Tue, 4 May 2010 17:00:16 -0400

Interesting.  The term "magic" is a little to cutesy for me, but maybe I'm 
just getting old.

The draft, and the RFC on base64 it references, aren't specific enough 
about whitespace.  Maybe I read too quickly, but the sample shows indented 
lines -- is the leading whitespace ignored?  Embedded whitespace?  Where 
odes it say that?

I'd propose something similar:  all whitespace is ignored when generating 
the digest.  Then even more issues vanish.

        /r$

---

From: Bob Wyman <[email-masked]>
Date: Tue, 4 May 2010 17:47:33 -0400

Richard Salz <[email-masked]> wrote:
> is the leading whitespace ignored?

Section 7.2 of the draft says: "Normalize the string by removing all
whitespace characters from input."
So, Yes, whitespace is ignored. Simple!

Note: Magic Signature discussions should be on:
http://groups.google.com/group/salmon-protocol

bob wyman

---

From: John Panzer <[email-masked]>
Date: Wed, 5 May 2010 09:43:18 -0700

> So, Yes, whitespace is ignored. Simple!

It also makes generating printable examples much, much easier ;)

> http://groups.google.com/group/salmon-protocol
We'd welcome discussions about both magic signatures and salmon on the
salmon-protocol list; if there is wider interest in magic signatures we can
start a new list.

Aside:  Sorry about the name, we needed something to go out with and
couldn't some up with anything better...

---

From: James Snell <[email-masked]>
Date: Wed, 12 May 2010 09:42:29 -0700

Updated the Link Extensions Draft...

  http://www.snellspace.com/wp/2010/05/atom-link-extensions/
  http://www.ietf.org/internet-drafts/draft-snell-atompub-link-extensions-03.txt

- James

---

From: Bob Wyman <[email-masked]>
Date: Wed, 12 May 2010 15:53:24 -0400

James, thanks for updating and revising this draft!

I would strongly encourage you to make the markup more expressive and
flexible by supporting "a generic hash attribute with an internal structure
for specifying algorithm and value". Actually, I would suggest that you
extend this a bit further to include a specification of the encoding for the
hash value.Thus, I would suggest the following pattern:

hash_algorithm.encoding.hash_value

Alternatively, you could define a single, required hash_value encoding.
(Which wouldn't be too bad a thing to do.) Clearly, there should be a
registry of hash_algorithms as well as encodings (if supported).

In your blog post, you mention that clients might tend to rely on the value
returned by the Content-MD5 header. While this may be reasonable for HEAD
requests, clients should probably not trust the remote server when doing
GETs; they would be well advised to recompute the hash to ensure that the
remote server isn't lying about the hash (there are quite a number of
useful, but often deceitful, reasons why this might happen). Also, please
note that it should be possible to include a hash value which uses a
different hashing algorithm and encoding than is used by the Content-MD5
implementation. Thus, for any particular web resource, we might have quite a
number of possible hash/encoding combinations and, in some cases, even have
two hashes available for a single GET (i.e. The Content-MD5 header value and
perhaps an SHA1/base64 hash specified in the link.) You might make a note
about some of these odd cases in your security considerations section.

bob wyman

---

From: Peter Keane <[email-masked]>
Date: Wed, 12 May 2010 15:24:36 -0500

> hash_algorithm.encoding.hash_value

I certainly understand the value of alternative algorithms, although I
do appreciate the "what's the simplest thing...." approach of this
draft.  I'll note that the MediaRSS extension uses an element to
express hash information:

        <media:hash algo="md5">dfdec888b72151965a34b4b59031290a</media:hash>

Perhaps simply using that element as "content" of the atom:link
element offers the desired added flexibility?

--Peter Keane

---

From: James Snell <[email-masked]>
Date: Wed, 12 May 2010 14:10:28 -0700

> hash_algorithm.encoding.hash_value

Hmm... for me, this immediately starts screaming overkill. I'd almost
prefer to go the route of defining individual attributes for each hash
algorithm... e.g.

  md5="..."
  sha256="..."

Each using the basic hex encoding.

The spec can define a handful of these for the most common hash
algorithms and establish the pattern. New attributes for new
algorithms can be added later.

Just seems simpler.

---

From: Martin Atkins <[email-masked]>
Date: Wed, 12 May 2010 14:22:50 -0700

On 05/12/2010 02:10 PM, James Snell wrote:
>
> On Wed, May 12, 2010 at 12:53 PM, Bob Wyman<[email-masked]>  wrote:

Strongly agreed.

Having one attribute which can represent all hash types would be useful 
only if there were some way for a consumer to dynamically discover how 
to produce a hash of a particular type, which is not practical.

Otherwise, an implementation must already have a fixed set of supported 
hash types, in which case it is beneficial to separate them into 
separate attributes so that publishers can choose to produce more than 
one of them to accomodate the capabilities of different consumers, each 
of which will support only a subset of the set of all existing hash 
algorithms.

---

From: Peter Keane <[email-masked]>
Date: Wed, 12 May 2010 16:41:21 -0500

> algorithms can be added later.

+1

---

From: James Snell <[email-masked]>
Date: Wed, 12 May 2010 17:53:15 -0700

So the key question is: what are the main algorithms we need to
provide attributes for?

- James

---

From: Richard Salz <[email-masked]>
Date: Wed, 12 May 2010 23:50:57 -0400

> So the key question is: what are the main algorithms we need to

This is a hard question to answer -- especially for hash/digest algorithms 
which tend to fall more rapidly than vetted crypto algorithms.

It's more verbose, but I strongly recommend using a pair of attributes to 
represent algorithm/value. Use the URI's defined in the latest XML DSIG 
document, perhaps with the "trick" that relative URI's ar a shorthand for 
the xmldsig namespace.

        /r$

---

From: Peter Krantz <[email-masked]>
Date: Thu, 13 May 2010 07:41:32 +0200

On Thu, May 13, 2010 at 05:50, Richard Salz <[email-masked]> wrote:
> represent algorithm/value.
>

Yahoo has used the following construct in their Media RSS format [1]:

"This is the hash of the binary media file. It can appear multiple
times as long as each instance is a different algo. It has 1 optional
attribute.

algo indicates the algorithm used to create the hash. Possible values
are 'md5' and 'sha-1'. Default value is 'md5'. It is an optional
attribute."

And the Metalink draft [2] is using this:

<hash type="sha-1">a97fcf6ba9358f8a6f62beee4421863d3e52b080</hash>

[1]: http://video.search.yahoo.com/mrss
[2]: http://tools.ietf.org/html/draft-bryan-metalink-28#section-4.2.4

Regards,

Peter Krantz

---

From: James Snell <[email-masked]>
Date: Wed, 12 May 2010 22:39:18 -0700

Updated draft...

http://www.ietf.org/internet-drafts/draft-snell-atompub-link-extensions-04.txt

- James

---

From: Peter Krantz <[email-masked]>
Date: Thu, 13 May 2010 08:19:56 +0200

> Updated draft...

Looks good! If I understand this correctly it enables multiple hashes
for the same file, e.g.

<atom:link rel="enclosure"
       href="http://example.org/media/myfile.mp3"
       md5="9e107d9d372bb6826bd81d3542a419d6"
       sha1="2fd4e1c67a2d28fced849ee1bb76e7391b93eb12" />

This could enable publishers to provide more information about a file.
Does the spec need to say something about how to interpret multiple
hashes in case one of them is wrong? Or maybe that is up to the
individual use case?

Regards,

Peter Krantz

---

From: Dominik Tomaszuk <[email-masked]>
Date: Thu, 13 May 2010 16:35:52 +0200

> http://www.ietf.org/internet-drafts/draft-snell-atompub-link-extensions-04.txt
It is:
sha224 = attribute sha224 { sha1-digest } - section 3.4
sha256 = attribute sha256 { sha1-digest } - section 3.5
sha384 = attribute sha384 { sha1-digest } - section 3.6
sha512 = attribute sha512 { sha1-digest } - section 3.7
I think it should be:
sha224 = attribute sha224 { sha224-digest }
sha256 = attribute sha256 { sha256-digest }
sha384 = attribute sha384 { sha384-digest }
sha512 = attribute sha512 { sha512-digest }

Regards,

Dominik Tomaszuk

---

From: Dominik Tomaszuk <[email-masked]>
Date: Thu, 13 May 2010 16:36:25 +0200

> http://www.ietf.org/internet-drafts/draft-snell-atompub-link-extensions-04.txt
What about other hash functions:
GOST [1]
Whirlpool [2]
MD4 [3]
CRC32

Also to consider:
HAVAL (variant 128/160/192/224/256) [4]
Tiger (variant 128/160/192) [5]

[1] http://tools.ietf.org/html/rfc5831
[2] ISO/IEC 10118-3:2004 - 
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=39876
[3] http://tools.ietf.org/html/rfc1320
[4] http://labs.calyptix.com/haval.php
[5] http://www.cs.technion.ac.il/~biham/Reports/Tiger/tiger/tiger.html

Regards,

Dominik Tomaszuk

---

From: James Snell <[email-masked]>
Date: Fri, 14 May 2010 12:06:29 -0700

Ok, I've been giving this some more thought and I think a hybrid
approach works very well. As has been pointed out a number of times in
this thread, there are existing elements in other namespaces that
provide a algorithm/hash pairing. I think that the Link Extensions
Draft can provide a attributes for the most basic hash algorithms and
applications that require hash algorithms that are not covered can
fall back to the extension elements.

e.g.

<link href="foo" md5="abc...xyz">
  <media:hash algo="GOST">123...456</media:hash>
</link>

This would allow for the most common cases to be easily covered while
allowing for the full range of possible cases to be handled as well.

- James

---

From: Dominik Tomaszuk <[email-masked]>
Date: Fri, 14 May 2010 22:28:03 +0200

> fall back to the extension elements.
Which algorithms will be supported by the elements and which by the 
attributes? Who decides which hash are basic?

My proposals:

1. attributes with URN
e.g.
<link href="foo" algo="urn:hash:md5:abc..xyz" />

2. attributes with CURIE [1]
e.g.
<feed xmlns=".." xmlns:hash="http://purl.org/hash/algo/">
<link href="foo" algo="hash:abc..xyz" />

3. elements with hash and algorithm
e.g.
<link href="foo">
<h:hash algo="md5">abc..xyz</h:hash>
</link>

4. one attribute to one hash
<feed xmlns=".." xmlns:md5="http://purl.org/hash/md5/" 
xmlns:sha1="http://purl.org/hash/sha1/">
<link href="foo" md5:algo="abc...xyz" />

Proposal 1 is short. Proposal 2 is my choice, because it is expandable. 
Proposal 3 and 4 are modification of a hybrid approach (I propose them 
because I think that it should not be two method to represent hashes in 
link).

[1] http://www.w3.org/TR/curie/

Regards,

Dominik Tomaszuk

---

From: Bob Wyman <[email-masked]>
Date: Fri, 14 May 2010 16:26:23 -0400

>  <media:hash algo="GOST">123...456</media:hash>

The alternative approach, which would support both a variety
and multiplicity of hashes would look like this:

<link href="foo" hash="gost:123123..., md5:0928402948...,
sha256:098078097..."/>

This strikes me as "simpler" than the hybrid approach. Just a few of my
concerns with the proposed "hybrid" approach follow:

   - I like binding the algorithm and value together into a single value
   since I know of no compelling case for processing one element in isolation
   of the other. The hash value only makes sense if you know the algorithm and
   the algorithm is only useful when bound to a specific hash value. Thus, it
   strikes me as simply introducing syntactic sugar to specify the algorithm
   using a different XML component than the value.
   - These values are likely to be stored in databases and otherwise
   manipulated. In all cases, for the data to be meaningful, people will need
   to keep the binding between algorithm and hash value. It is likely that
   storing a single string value is going to be easier for folk than dealing
   with a multi-part value. Also, consider the effect of parsers... It is
   likely that in order to transfer a value from an entry into a database
   field, what you'll need to do is extract both algorithm and hash value from
   the parse tree and then construct some string that combines them. This would
   be particularly useful if you want to use the hash value as a database key
   (a very reasonable thing to do...) You could build and store the string
   "algo='GOST'>123...455<" or your database might support concatenated fields,
   or you could build "gost.123...456". I think I would go with the latter.
   - Defining distinct attributes for each hash algorithm pushes unnecessary
   syntactical complexity to the global level and thus increases the complexity
   not only of the specification but also of all applications no matter which
   algorithms they understand or if they understand any at all. It also makes
   extending the list of supported algorithms "expensive" since such extensions
   require modification to the standard rather than just an registry entry.What
   benefit do we get from having these algorithm types defined at the global
   syntax level?
   - The hybrid approach looks very complicated to me. It means that I'll
   have two very different places in which hash values might found and two very
   different syntaxes for expressing them. The result is going to be more
   complex code than would otherwise be the case. What value comes from using
   the hybrid approach?
   - One argument for hybrid is that these elements exist already in other
   specs. I wonder if it isn't possible that those other specs might have
   approached the problem in a non-optimal fashion. Does it really make sense
   to import syntax if there isn't a really good case that demonstrates that
   doing so is the best approach?
   - I am unaware of any hash algorithms that need anything other than the
   specification of the algorithm and the value in order to be useful. If there
   were broadly used algorithms that had more complex meta-data requirements,
   it would be easier to understand the appeal of the hybrid approach.
   - I can't think of any reason why it is *useful* to separate the
   algorithm from the hash value. Can someone enlighten me here? What
   computation, storage or communication task becomes easier if you have these
   two separated?

bob wyman

---

From: Dominik Tomaszuk <[email-masked]>
Date: Fri, 14 May 2010 22:58:59 +0200

> <link href="foo" hash="gost:123123..., md5:0928402948...,
I improve this proposal to 'hash: URI scheme':
<link href="foo" 
algo="hash:gost=123123...&md5=0928402948...&sha256=098078097..."/>

Regards,

Dominik Tomaszuk

---

From: James Snell <[email-masked]>
Date: Fri, 14 May 2010 14:15:28 -0700

Good argument Bob... ok... stewing over this a bit more. I generally
dislike having to do additional parsing of attribute/element values
but there are very good reasons for keeping this as a single "hash"
attribute and you make a compelling case.

On Fri, May 14, 2010 at 1:26 PM, Bob Wyman <[email-masked]> wrote:
> I like binding the algorithm and value together into a single value since I
> know of no compelling case for processing one element in isolation of the
> other. The hash value only makes sense if you know the algorithm and the
> algorithm is only useful when bound to a specific hash value. Thus, it
> These values are likely to be stored in databases and otherwise manipulated.
> In all cases, for the data to be meaningful, people will need to keep the
> binding between algorithm and hash value. It is likely that storing a single
> string value is going to be easier for folk than dealing with a multi-part
> value. Also, consider the effect of parsers... It is likely that in order to
> transfer a value from an entry into a database field, what you'll need to do
> is extract both algorithm and hash value from the parse tree and then
> construct some string that combines them. This would be particularly useful
> if you want to use the hash value as a database key (a very reasonable thing
> to do...) You could build and store the string "algo='GOST'>123...455<" or
> your database might support concatenated fields, or you could build
> "gost.123...456". I think I would go with the latter.
> Defining distinct attributes for each hash algorithm pushes unnecessary
> The hybrid approach looks very complicated to me. It means that I'll have
> two very different places in which hash values might found and two very
> One argument for hybrid is that these elements exist already in other specs.
> I wonder if it isn't possible that those other specs might have approached
> the problem in a non-optimal fashion. Does it really make sense to import
> syntax if there isn't a really good case that demonstrates that doing so is
> the best approach?
> I am unaware of any hash algorithms that need anything other than the
> I can't think of any reason why it is *useful* to separate the algorithm
> from the hash value. Can someone enlighten me here? What computation,
> storage or communication task becomes easier if you have these two
> separated?
>
> bob wyman

---

From: Martin Atkins <[email-masked]>
Date: Fri, 14 May 2010 14:18:35 -0700

On 05/14/2010 01:26 PM, Bob Wyman wrote:
> James Snell <[email-masked] <mailto:[email-masked]>> wrote:

Given that XML already provides a syntax for key-value pairs, it seems 
strange to define a microsyntax for key-value pairs within one of the 
values.

I'd expect that most implementations are going to support only one or 
two hash algorithms, and it is simpler for them (assuming the usual 
approaches for processing XML) to simply look for the one or two 
attributes representing the hash algorithms they understand than to 
implement a parser for this microsyntax for the ones they are interested in.

I'd expect that only debugging tools and validators will ever be 
interested in enumerating *all* of the available hashes, so it's not 
crucial that the hashes be distinguishable from other attributes in the 
sense that you can determine which attributes are hashes and which are 
not without retaining a list of all hash algorithms.

---

From: Richard Salz <[email-masked]>
Date: Sat, 15 May 2010 21:18:59 -0400

Yes, knowing the hash value without knowing the mechanism is useless. Both 
the separation of mechanism/value is the way the crypto world does things 
(e.g., XMLDSig), and URI's are the way the Web identifies things.  Adding 
a special-case attribute value parser to handle this non-standard way of 
doing things doesn't seem to fit.

        /r$

---

From: Sam Johnston <[email-masked]>
Date: Sun, 16 May 2010 10:46:32 +0400

James,

In consideration of former (CRC) and future (AHS) hashing functions I think
it's critical to support extensibility and multiple hashes. I like that XML
digsigs use anyURIs <http://www.w3.org/TR/xmldsig-core/#sec-DigestMethod> to
identify hashes (e.g. <DigestMethod Algorithm="http://www.w3.org
/2000/09/xmldsig#sha1">), but one could argue this unnecessarily complicates
what should be a simple syntax.

I was about to propose an IANA registry for hash functions but one already
exists (Hash Function Textual
Names<http://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xml>
as
specified by RFC4572 <http://tools.ietf.org/html/rfc4572#section-8>) so it
would make sense to use it rather than inventing our own mechanism - even if
we have to update the registry rules to allow for algorithms specified by
URI rather than RFC.

While Atom is an XML format and should arguably follow XML conventions,
there is precedent for prefixing hashes with the name of the hashing
function using e.g. colons or curly
braces<http://users.ameritech.net/mhwood/ldap-sec-setup.html>.
I think it's more important to keep the XML syntax simple and in any case
the hash and hash function should be tightly bound as they are useless
independently.

All that considered, I think the best approach is to allow for a
multi-valued "hash" attribute ala:

<link rel="alternate" href="http://example.com/"
hash="md5:6705f99eccedeac20e969bef954c5fb0
sha-1:bc608e6d3d339d1a7afc406a7ea6a8f07358038b" />

and/or

<link rel="alternate" href="http://example.com/thing.pdf"
hash="md5:6705f99eccedeac20e969bef954c5fb0"
hash="sha-1:bc608e6d3d339d1a7afc406a7ea6a8f07358038b" />

Sam
Google

---

From: Bob Wyman <[email-masked]>
Date: Sun, 16 May 2010 23:36:14 -0400

+1 LGTM

On May 16, 2010 11:29 PM, "James Snell" <[email-masked]> wrote:

Ok, although I seriously dislike having to do additional parsing on
attribute values, the arguments made so far are valid and parsing hex
encoded hash digests is -- fortunately -- quite simple to do. So let's
go with the following syntax...

 hash = attribute hash { hash-list }
 hash-list = # ( token ":" 1*HEX )

The token and HEX productions are defined by RFC2616...

The spec would defer to the existing IANA registry for hash functions
to define the "tokens"

This would result in a syntax of...

 hash="md5:abc...xyz, sha-1:123...567, sha-512:xyz...abc"

This seem acceptable to everyone?

- James

On Sat, May 15, 2010 at 11:46 PM, Sam Johnston <[email-masked]> wrote:
> In consideration o...

---

From: James Snell <[email-masked]>
Date: Sun, 16 May 2010 20:29:18 -0700

- James

On Sat, May 15, 2010 at 11:46 PM, Sam Johnston <[email-masked]> wrote:
> digsigs use anyURIs to identify hashes (e.g. <DigestMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1">), but one could argue
> this unnecessarily complicates what should be a simple syntax.
> exists (Hash Function Textual Names as specified by RFC4572) so it would
> make sense to use it rather than inventing our own mechanism - even if we
> have to update the registry rules to allow for algorithms specified by URI
> rather than RFC.
> function using e.g. colons or curly braces. I think it's more important to
> keep the XML syntax simple and in any case the hash and hash function should
> be tightly bound as they are useless independently.
>> >> > It's more verbose, but I strongly recommend using a pair of
>> >> > attributes
>> >> > to

---

From: Sam Johnston <[email-masked]>
Date: Mon, 17 May 2010 08:00:19 +0400

Are the commas earning their keep? If they're unnecessary then remove them,
otherwise LGTM.

Sam

---

From: Peter Keane <[email-masked]>
Date: Mon, 17 May 2010 00:44:07 -0500

> Are the commas earning their keep? If they're unnecessary then remove them,

I was going to ask the same question. (re: the commas)

--peter

---

From: Richard Salz <[email-masked]>
Date: Mon, 17 May 2010 06:32:48 -0400

> This seem acceptable to everyone?

Oh well, you can't win 'em all.

        /r$

---

From: James Snell <[email-masked]>
Date: Mon, 17 May 2010 12:47:00 -0700

Ok, draft is updated with the new syntax for the hash attribute.

  http://www.ietf.org/staging/draft-snell-atompub-link-extensions-05.txt

There is also one additional 'media' attribute added. I wanted to wait
to add it until after I was sure the other three attributes were fine.
The 'media' attribute serves the same purpose as the 'media' attribute
on HTML5 links... the value is a media query. For example:

  <link href="foo" media="handheld and (min-width = 20cm)" />

The use case is to be able to provide multiple links targeted at
specific types of media... e.g. screen, print, mobile devices, etc.

Another change that I am contemplating making is introducing a new
child element for the atom:link element that would allow it to serve
the same basic purpose as the GData feedLink and entryLink elements
except with greater flexibility... specifically, it would allow a
representation of the linked resource to be dropped directly into the
link element, e.g.

<link rel="alternate" href="foo" type="text/plain">
  <data type="text">this is a representation of the data</data>
</link>

<link rel="alternate" href="foo" type="image/jpeg">
  <data type="encoded">abc...def==</data> <!-- base64 -->
</link>

<link rel="alternate" href="foo" type="application/atom+xml">
  <data type="markup">
    <feed>...</feed>
  </data>
</link>

Or something along those lines.

Thoughts?

- James

---

From: Bob Wyman <[email-masked]>
Date: Mon, 17 May 2010 16:18:59 -0400

I'm curious about the vigor with which you seem to be denying the utility of
hash functions in integrity checking when you write:

hash attribute values MUST be considered to be strictly advisory and
cannot be used reliably as an end-to-end integrity check.

I am, of course, aware of the limitations of both hash functions and
end-to-end links, but it seems to me that the real risk here is limited to
false-negatives. (i.e. If hash values don't match, I can't really be sure
that I haven't linked to the correct resource.) However, it seems like the
risk of false-positives is no greater than in any other hash-based system.
(i.e. if the hash values do match, then I've can be reasonably, but not
completely, assured of integrity.)
I think I understand the standard issues. Is there something more exotic
that I'm missing?

bob wyman

---

From: James Snell <[email-masked]>
Date: Mon, 17 May 2010 13:41:34 -0700

The key challenge is that the digests contained in the atom:link
cannot be viewed as being authoritative and only reflect a
point-in-time value that may only be true for the producer of the Atom
feed. There are many factors which influence whether the same hash
value can be generated for the linked resource. If the hash-value
happens to match... fantastic. If the hash-value doesn't match, then
the feed consumer knows that they need to do more work to figure out
what happened... including performing a more authoritative check of
the resource.

On Mon, May 17, 2010 at 1:18 PM, Bob Wyman <[email-masked]> wrote:
> hash attribute values MUST be considered to be strictly advisory and cannot
> be used reliably as an end-to-end integrity check.
>

---

From: Bob Wyman <[email-masked]>
Date: Mon, 17 May 2010 17:00:06 -0400

On Mon, May 17, 2010 at 4:41 PM, James Snell <[email-masked]> wrote:

> feed.

Actually, for the applications that I'm most interested in at the moment,
such "point-in-time" values are exactly what I want. I want to be able to
point to a specific version of a resource and say that if you read something
that I did not, then you're not looking at the same version of the document
that I saw. The best example would be something like a contract, petition or
poll that I might "sign" by-reference. My signature would only be "valid" if
the resource linked to is exactly the same as it was at the point in time
when I generated the hash value that I later included in a signed Atom
entry.

bob wyman

> There are many factors which influence whether the same hash
> cannot

---

From: Dominik Tomaszuk <[email-masked]>
Date: Mon, 17 May 2010 23:12:41 +0200

On 17.05.2010 21:47, James Snell wrote:
> on HTML5 links... the value is a media query.
I propose 'langhref' attribute (equivalent to HTML5 'langhref'). This 
attribute specifies the primary language of the resource designated by 
href. It is purely advisory. The value must be a valid BCP 47 [1] 
language tag.

[1] http://www.ietf.org/rfc/bcp/bcp47.txt

Regards,

Dominik Tomaszuk

---

From: Dominik Tomaszuk <[email-masked]>
Date: Mon, 17 May 2010 23:11:33 +0200

>    <data type="text">this is a representation of the data</data>
It can be used with XInclude, e.g.
<link rel="alternate" href="foo" type="text/plain">
    <data type="text" 
xmlns:xi="http://www.w3.org/2001/XInclude"><xi:include 
href="something.txt" parse="text"/></data>
</link>
 > <link rel="alternate" href="foo" type="application/atom+xml">
Or
<link rel="alternate" href="foo" type="text/plain">
<data type="markup" 
xmlns:xi="http://www.w3.org/2001/XInclude"><xi:include 
href="something.xml" parse="xml"/></data>
</link>

 >    <data type="encoded">abc...def==</data>  <!-- base64 -->
There are many methods of encoding. It should be declare Base16, Base32, 
or Base64 [1].

[1] http://www.ietf.org/rfc/rfc3548.txt

Regards,

Dominik Tomaszuk

---

From: James Snell <[email-masked]>
Date: Mon, 17 May 2010 15:01:08 -0700

atom:link already has an hreflang attribute for this purpose.

On Mon, May 17, 2010 at 2:12 PM, Dominik Tomaszuk <[email-masked]> wrote:
> attribute specifies the primary language of the resource designated by href.
> It is purely advisory. The value must be a valid BCP 47 [1] language tag.
>

---

From: James Snell <[email-masked]>
Date: Mon, 17 May 2010 16:16:24 -0700

Right, that point-in-time quality is what makes this attribute most
useful... it does not, however, make this a reliable integrity check.
The attribute allows a feed producer to describe the state of the
resource at the time the link was created... which is definitely
something that has been missing to this point. This becomes even more
important when combined with digital signature scenarios. That said
however, it has to be acknowledged that these hash digests simply are
not authoritative enough to be used as a reliable integrity check for
the resource at the time a consumer may retrieve it.

On Mon, May 17, 2010 at 2:00 PM, Bob Wyman <[email-masked]> wrote:
>> >> >> Are the commas earning their keep? If they're unnecessary then
>> >> >> remove
>> >> >> them,
>> >> >> otherwise LGTM.
>> >> >> Sam
>> >> >

---

From: Niklas Lindström <[email-masked]>
Date: Tue, 18 May 2010 10:23:40 +0200

Hi James,

>  http://www.ietf.org/staging/draft-snell-atompub-link-extensions-05.txt

+1. Looks good. (I like the whitespace-separation too, much better
than comma+opt. space.)

Just a thought though. I think using the null-namespace is good, and
that this updating of the Atom syntax seems very reasonable. But does
the informational status of the RFC warrant such an addition to the
syntax? I mean, since it seems like a very authoritative thing to do
to Atom spec.

>  <link href="foo" media="handheld and (min-width = 20cm)" />

Sounds quite good (as long as it is aligned to the HTML5 variant --
and if that one is stable). If this won't slow down the progress to an
RFC I'm all for it.

> Or something along those lines.

I do think that this is a good idea. However, could it perhaps be
better as a separate I-D (link-content-embedding or something)? While
I agree that it's about link extensions, the current scope is around
attributes around which I think we have reached a general consensus. I
suspect that this new element might take longer to iron out and reach
the same level of agreement with? (Since there have been similar
propositions over the years.) Again, I'm mostly just after getting the
link-extensions to an RFC state as soon as possible.

(Especially since we use the older, namespaced md5-attribute in our
system today, and I would prefer to defer support for this new version
(null-namespace, hash) until the I-D becomes an RFC.)

Thanks again for revitalising this!

Best regards,
Niklas

---

From: Colm Divilly <[email-masked]>
Date: Tue, 18 May 2010 13:23:23 +0100

> Or something along those lines.
+1, I think this is really important, Whenever I am designing resources, 
I am always finding myself having to make a choice about whether to 
inline related content in the resource or include a hyper link to the 
related content. Having a consistent pattern for doing this would be 
beneficial.

As an aside, if this approach was possible, then one could re-imagine 
the atom:content element as simply <link rel="content">...</link>.

Nikunj Mehta has an unpublished draft of Atom Inline Extensions that 
proposes the same as what you propose [1] (the last published draft 
restricted the inline content types to atom resources only [2]),  Nikunj 
care to weigh in?

There was some discussion about this a while back: [3]

[1] 
http://atom-ext.googlecode.com/svn-history/r9/trunk/draft-mehta-atom-inline.xml
[2] http://tools.ietf.org/html/draft-mehta-atom-inline-01#section-2.1.1
[3] http://www.imc.org/atom-syntax/mail-archive/threads.html#21203

---

From: James Snell <[email-masked]>
Date: Tue, 18 May 2010 08:20:12 -0700

> syntax? I mean, since it seems like a very authoritative thing to do

Eventually, yes, this should eventually make it into the standards
track... for now, however, informational is appropriate. Once I'm sure
the spec is complete, I'll check overall consensus on moving it to the
standards track.

> and if that one is stable). If this won't slow down the progress to an

Yes, I modeled this directly off the HTML5 media attribute and intend
to track that effort. HTML5 currently defers to the Media Queries
specification which seems to be somewhat stable at the moment.

> [snip]

Yes, I agree that this would be better served by a separate I-D. The
link extensions draft as it currently exists should be just about
complete as it is... at least in terms of technical definition. I need
to fill out additional bits such as the security concerns, etc, but I
think there are enough heads nodding in the right direction to move
forward on the rest.

---

From: James Snell <[email-masked]>
Date: Tue, 18 May 2010 12:50:02 -0700

Non-Atom type support, I think, is definitely important. I also urge
you to consider defining the element so that it is a part of the Atom
namespace. Explosion and management of extension namespaces is going
to become a significant problem as time goes on, we need to establish
good practices for it now.

On Tue, May 18, 2010 at 12:46 PM, Nikunj Mehta <[email-masked]> wrote:
> I can brush up the I-D and add the non-Atom type support, which was contemplated but waiting for more interest to be put in.
>
> Nikunj
> On May 18, 2010, at 5:23 AM, Colm Divilly wrote:
>
>> James Snell wrote:
>> +1, I think this is really important, Whenever I am designing resources, I am always finding myself having to make a choice about whether to inline related content in the resource or include a hyper link to the related content. Having a consistent pattern for doing this would be beneficial.
>>
>> As an aside, if this approach was possible, then one could re-imagine the atom:content element as simply <link rel="content">...</link>.
>>
>> Nikunj Mehta has an unpublished draft of Atom Inline Extensions that proposes the same as what you propose [1] (the last published draft restricted the inline content types to atom resources only [2]),  Nikunj care to weigh in?
>>
>> [1] http://atom-ext.googlecode.com/svn-history/r9/trunk/draft-mehta-atom-inline.xml

---

From: Pablo Castro <[email-masked]>
Date: Wed, 19 May 2010 18:46:10 +0000

+1. We've been doing a very similar thing in OData (Astoria) for a while. We've used as custom element (<inline>) in a custom namespace inside <atom:link> for now because there wasn't anything standard. For example (trimmed down version, full version here: http://odata.netflix.com/catalog/Titles?$top=2&$expand=Cast&$filter=ReleaseYear eq 1980):

  <entry m:etag="W/&quot;datetime'2009-10-07T05%3A06%3A22'&quot;">
    <id>http://odata.netflix.com/catalog/Titles('13WZu')</id>
    <title type="text">Metropolitan Opera: G. Puccini: Manon Lescaut</title>
    <summary type="html">Conducted by James Levine, the Metropolitan Opera presents Puccini's "Manon Lescaut." In this opera, directed by Gian Carlo Menotti, the title character (&lt;a href="http://www.netflix.com/RoleDisplay/Renata_Scotto/83647"&gt;Renata Scotto&lt;/a&gt;) escapes from a French convent and runs away with a poor student, the Chevalier des Grieux (a young &lt;a href="http://www.netflix.com/RoleDisplay/Pl_cido_Domingo/30005475"&gt;Placido Domingo&lt;/a&gt;). Manon eventually leaves des Grieux for a wealthy elderly lover; however, her heart is torn when des Grieux catches up with her.</summary>
    <published>2009-10-07T05:06:22Z</published>
    <updated>2010-05-19T18:42:18Z</updated>
    <author>
      <name />
    </author>
    <link m:etag="&quot;10/7/2009 5:06:22 AM&quot;" rel="edit-media" title="Title" href="Titles('13WZu')/$value" />
    <link rel="edit" title="Title" href="Titles('13WZu')" />
    <link rel="http://schemas.microsoft.com/ado/2007/08/dataservices/related/AudioFormats" type="application/atom+xml;type=feed" title="AudioFormats" href="Titles('13WZu')/AudioFormats" />
    <link rel="http://schemas.microsoft.com/ado/2007/08/dataservices/related/Awards" type="application/atom+xml;type=feed" title="Awards" href="Titles('13WZu')/Awards" />
    <link rel="http://schemas.microsoft.com/ado/2007/08/dataservices/related/Disc" type="application/atom+xml;type=entry" title="Disc" href="Titles('13WZu')/Disc" />
    <link rel="http://schemas.microsoft.com/ado/2007/08/dataservices/related/Movie" type="application/atom+xml;type=entry" title="Movie" href="Titles('13WZu')/Movie" />
    <link rel="http://schemas.microsoft.com/ado/2007/08/dataservices/related/Season" type="application/atom+xml;type=entry" title="Season" href="Titles('13WZu')/Season" />
    <link rel="http://schemas.microsoft.com/ado/2007/08/dataservices/related/Series" type="application/atom+xml;type=entry" title="Series" href="Titles('13WZu')/Series" />
    <link rel="http://schemas.microsoft.com/ado/2007/08/dataservices/related/ScreenFormats" type="application/atom+xml;type=feed" title="ScreenFormats" href="Titles('13WZu')/ScreenFormats" />
    <link rel="http://schemas.microsoft.com/ado/2007/08/dataservices/related/Cast" type="application/atom+xml;type=feed" title="Cast" href="Titles('13WZu')/Cast">
      <m:inline>
        <feed>
          <title type="text">Cast</title>
          <id>http://odata.netflix.com/catalog/Titles('13WZu')/Cast</id>
          <updated>2010-05-19T18:42:18Z</updated>
          <link rel="self" title="Cast" href="Titles('13WZu')/Cast" />
          <entry>
            <id>http://odata.netflix.com/catalog/People(83647)</id>
            <title type="text">Renata Scotto</title>
            <updated>2010-05-19T18:42:18Z</updated>
            <author>
              <name />
            </author>
            <link rel="edit" title="Person" href="People(83647)" />
            <link rel="http://schemas.microsoft.com/ado/2007/08/dataservices/related/Awards" type="application/atom+xml;type=feed" title="Awards" href="People(83647)/Awards" />
            <link rel="http://schemas.microsoft.com/ado/2007/08/dataservices/related/TitlesActedIn" type="application/atom+xml;type=feed" title="TitlesActedIn" href="People(83647)/TitlesActedIn" />
            <link rel="http://schemas.microsoft.com/ado/2007/08/dataservices/related/TitlesDirected" type="application/atom+xml;type=feed" title="TitlesDirected" href="People(83647)/TitlesDirected" />
            <category term="NetflixModel.Person" scheme="http://schemas.microsoft.com/ado/2007/08/dataservices/scheme" />
            <content type="application/xml">
              <m:properties>
                <d:Id m:type="Edm.Int32">83647</d:Id>
                <d:Name>Renata Scotto</d:Name>
              </m:properties>
            </content>
          </entry>
          <entry>
            <id>http://odata.netflix.com/catalog/People(30005475)</id>
            <title type="text">Plácido Domingo</title>
            <updated>2010-05-19T18:42:18Z</updated>
            <author>
              <name />
            </author>
            <link rel="edit" title="Person" href="People(30005475)" />
            <link rel="http://schemas.microsoft.com/ado/2007/08/dataservices/related/Awards" type="application/atom+xml;type=feed" title="Awards" href="People(30005475)/Awards" />
            <link rel="http://schemas.microsoft.com/ado/2007/08/dataservices/related/TitlesActedIn" type="application/atom+xml;type=feed" title="TitlesActedIn" href="People(30005475)/TitlesActedIn" />
            <link rel="http://schemas.microsoft.com/ado/2007/08/dataservices/related/TitlesDirected" type="application/atom+xml;type=feed" title="TitlesDirected" href="People(30005475)/TitlesDirected" />
            <category term="NetflixModel.Person" scheme="http://schemas.microsoft.com/ado/2007/08/dataservices/scheme" />
            <content type="application/xml">
              <m:properties>
                <d:Id m:type="Edm.Int32">30005475</d:Id>
                <d:Name>Plácido Domingo</d:Name>
              </m:properties>
            </content>
          </entry>
        </feed>
      </m:inline>
    </link>
    <link rel="http://schemas.microsoft.com/ado/2007/08/dataservices/related/Languages" type="application/atom+xml;type=feed" title="Languages" href="Titles('13WZu')/Languages" />
    <link rel="http://schemas.microsoft.com/ado/2007/08/dataservices/related/Directors" type="application/atom+xml;type=feed" title="Directors" href="Titles('13WZu')/Directors" />
    <link rel="http://schemas.microsoft.com/ado/2007/08/dataservices/related/Genres" type="application/atom+xml;type=feed" title="Genres" href="Titles('13WZu')/Genres" />
    <category term="NetflixModel.Title" scheme="http://schemas.microsoft.com/ado/2007/08/dataservices/scheme" />
    <content type="image/jpeg" src="http://cdn-4.nflximg.com/us/boxshots/large/5616554.jpg" />
    <m:properties xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata" xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices">
      <d:Id>13WZu</d:Id>
      <d:Synopsis>Conducted by James Levine, the Metropolitan Opera presents Puccini's "Manon Lescaut." In this opera, directed by Gian Carlo Menotti, the title character (&lt;a href="http://www.netflix.com/RoleDisplay/Renata_Scotto/83647"&gt;Renata Scotto&lt;/a&gt;) escapes from a French convent and runs away with a poor student, the Chevalier des Grieux (a young &lt;a href="http://www.netflix.com/RoleDisplay/Pl_cido_Domingo/30005475"&gt;Placido Domingo&lt;/a&gt;). Manon eventually leaves des Grieux for a wealthy elderly lover; however, her heart is torn when des Grieux catches up with her.</d:Synopsis>
      <d:Runtime m:type="Edm.Int32">8040</d:Runtime>
      <d:AverageRating m:type="Edm.Double">3.3</d:AverageRating>
      <d:ReleaseYear m:type="Edm.Int32">1980</d:ReleaseYear>
      <d:Url>http://www.netflix.com/Movie/Metropolitan_Opera_G._Puccini_Manon_Lescaut/5616554</d:Url>
      <d:Rating>NR</d:Rating>
      <d:Type>Movie</d:Type>
      <d:ShortName>Metropolitan Opera: Puccini</d:ShortName>
      <d:Name>Metropolitan Opera: G. Puccini: Manon Lescaut</d:Name>
      <d:TinyUrl>http://movi.es/13WZu</d:TinyUrl>
      <d:WebsiteUrl m:null="true"></d:WebsiteUrl>
      <d:NetflixApiId>http://api.netflix.com/catalog/titles/movies/5616554</d:NetflixApiId>
      <d:BoxArt m:type="NetflixModel.BoxArt">
        <d:SmallUrl>http://cdn-4.nflximg.com/us/boxshots/tiny/5616554.jpg</d:SmallUrl>
        <d:MediumUrl>http://cdn-4.nflximg.com/us/boxshots/small/5616554.jpg</d:MediumUrl>
        <d:LargeUrl>http://cdn-4.nflximg.com/us/boxshots/large/5616554.jpg</d:LargeUrl>
        <d:HighDefinitionUrl m:null="true"></d:HighDefinitionUrl>
      </d:BoxArt>
      <d:Instant m:type="NetflixModel.InstantAvailability">
        <d:Available m:type="Edm.Boolean">false</d:Available>
        <d:AvailableFrom m:type="Edm.DateTime" m:null="true"></d:AvailableFrom>
        <d:AvailableTo m:type="Edm.DateTime" m:null="true"></d:AvailableTo>
        <d:HighDefinitionAvailable m:type="Edm.Boolean">false</d:HighDefinitionAvailable>
      </d:Instant>
      <d:Dvd m:type="NetflixModel.DeliveryFormatAvailability">
        <d:Available m:type="Edm.Boolean">false</d:Available>
        <d:AvailableFrom m:type="Edm.DateTime" m:null="true"></d:AvailableFrom>
        <d:AvailableTo m:type="Edm.DateTime" m:null="true"></d:AvailableTo>
      </d:Dvd>
      <d:BluRay m:type="NetflixModel.DeliveryFormatAvailability">
        <d:Available m:type="Edm.Boolean">false</d:Available>
        <d:AvailableFrom m:type="Edm.DateTime" m:null="true"></d:AvailableFrom>
        <d:AvailableTo m:type="Edm.DateTime" m:null="true"></d:AvailableTo>
      </d:BluRay>
    </m:properties>
  </entry>