2010/5/18 Niklas Lindström <[email protected]>: > Hi James, > > On Mon, May 17, 2010 at 9:47 PM, James Snell <[email protected]> wrote: >> >> Ok, draft is updated with the new syntax for the hash attribute. >> >> 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. >
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. > >> 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)" /> > > 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. > 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] > 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.) > 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. > > Thanks again for revitalising this! > > Best regards, > Niklas > -- - James Snell http://www.snellspace.com [email protected]
