Re: Comments of the site-meta draft

Hi Ashok,

On 13/01/2009, at 8:32 AM, ashok malhotra wrote:

> The TAG asked me to review the site-meta draft: http://tools.ietf.org/html/draft-nottingham-site-meta-00
> Comments below.
>
> These are my personal comments and have not been reviewed by the  
> TAG. So, it is possible that some TAG members may disagree with them  
> and/or have additional comments.
>
> Minor Comments
>
> 1. I think you realize that the use of site-meta as a suffix to the  
> URI steals a portion of the address space available for URIs and may  
> be in conflict with existing URIs that use ‘site-meta’ at the end. I  
> presume you have come to terms with this as a necessary evil.

Yes.


> 2. It takes 2 requests to access a piece of metadata. This, too, I  
> presume you have come to terms with.

Yes. The hope is that the cost will be reduced as such a mechanism is  
used more, because of caching.


> 3. The text says that “Each "meta" element … MUST have a "rel"  
> attribute containing a link relation.”  However, the third meta  
> child in the example does not have a ‘rel’ attribute.  Is this a typo?
>
> <meta type="text/example">
>
> foo = bar
>
> baz = bat
>
> </meta>
>

Yes; thanks.


> 4. In the above example, I presume “foo = bar   baz = bat” is the  
> content of the metadata.  Is this meant to be free text or XML?  A  
> few words of explanation and/or a realistic example would be helpful.

Will do. I expect the format to change pretty radically in the next  
revision (to a header-like textual one), so this may not be relevant  
any more.


> More Serious Comments
>
> 5. The <metadata> element contains <meta> children that contain  
> information about individual pieces of metadata.  But metadata about  
> what?  Is this metadata for the site as a whole or for some URI  
> contained on the site?  Specifically, what is the subject of the  
> “rel” attribute?

There's been some pretty detailed discussion of that recently on the apps-discuss@ietf.org 
  list; the upshot at this point is that the scope is by default  
(host, port), but specific uses of the mechanism can define other  
scopes (e.g., FooPolicy can declare that to find its metadata for an  
email address in example.org, one would look at http://example.org/site-meta 
  and http://www.example.org/site-meta, first match wins).


> 6. Since we are suggesting two mechanisms for accessing metadata:  
> Link Header and site-meta, it seems to me that we need to say  
> something about the relationship between these mechanisms.  Do we  
> need both?  What are the usecases?  Can a website support both  
> mechanisms?  I see no reason why it should not.  If  site-meta is  
> about the site as a whole, how can I get metadata about individual  
> URIs on the site?  Do I use the link header mechanism for this?

I'm very shy of defining a closed world model of metdata on the Web,  
or for that matter anything that claims to be "the" model for metadata  
on the Web. This proposal will co-exist with the Link header in much  
the same way that it will with any other HTTP header, media type, or  
other component of the Web.


> 7. If a website supports both the Link Header and the site-meta  
> mechanisms, then the data obtained from using these two mechanisms  
> must be consistent.  As it stands, the structure of the <meta>  
> element and a Link Header entry are a bit different.  Should these  
> be aligned?

See above.

Cheers,

Received on Wednesday, 4 February 2009 22:58:16 UTC