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 =20
> TAG. So, it is possible that some TAG members may disagree with them =20=

> and/or have additional comments.
>
> Minor Comments
>
> 1. I think you realize that the use of site-meta as a suffix to the =20=

> URI steals a portion of the address space available for URIs and may =20=

> be in conflict with existing URIs that use =91site-meta=92 at the end. =
I =20
> 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 =20
> presume you have come to terms with.

Yes. The hope is that the cost will be reduced as such a mechanism is =20=

used more, because of caching.


> 3. The text says that =93Each "meta" element =85 MUST have a "rel" =20
> attribute containing a link relation.=94  However, the third meta =20
> child in the example does not have a =91rel=92 attribute.  Is this a =
typo?
>
> <meta type=3D"text/example">
>
> foo =3D bar
>
> baz =3D bat
>
> </meta>
>

Yes; thanks.


> 4. In the above example, I presume =93foo =3D bar   baz =3D bat=94 is =
the =20
> content of the metadata.  Is this meant to be free text or XML?  A =20
> 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 =20
revision (to a header-like textual one), so this may not be relevant =20
any more.


> More Serious Comments
>
> 5. The <metadata> element contains <meta> children that contain =20
> information about individual pieces of metadata.  But metadata about =20=

> what?  Is this metadata for the site as a whole or for some URI =20
> contained on the site?  Specifically, what is the subject of the =20
> =93rel=94 attribute?

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


> 6. Since we are suggesting two mechanisms for accessing metadata: =20
> Link Header and site-meta, it seems to me that we need to say =20
> something about the relationship between these mechanisms.  Do we =20
> need both?  What are the usecases?  Can a website support both =20
> mechanisms?  I see no reason why it should not.  If  site-meta is =20
> about the site as a whole, how can I get metadata about individual =20
> 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, =20
or for that matter anything that claims to be "the" model for metadata =20=

on the Web. This proposal will co-exist with the Link header in much =20
the same way that it will with any other HTTP header, media type, or =20
other component of the Web.


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

See above.

Cheers,=