Discussion of matters related to the applications area of IETF

headers Lisa Dusseault | 2 Feb 00:17

_______________________________________________
Apps-Discuss mailing list
Apps-Discuss <at> ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

My comment, Eran, was editorial.

I've had this in my mailbox and not replied because I keep on
stumbling over:

> "Metadata is a word or phrase, not a technical term."

This is a technical document. It defines a mechanism, and says
it is good for "metadata". It doesn't define the term
"metadata", although that's the use case....

"a method for locating host metadata".

> In the context of this draft, it generally means "information about".

The document doesn't say that. That wouldn't be
so bad if the use of the term corresponded to the common
use of the term "metadata", but it doesn't match.

> I don't see the need for the document to say anything
>  more than it currently does.

Effective human communication means that a document
that uses terms should 

* attempt to use terms with their conventional meaning
* in the case of possible confusion (conventional meaning
  is ambiguous, or the document's usage doesn't match
  the conventional meaning), the document should define
  the term.

> It would be a waste of everyone's time if the
> process of reviewing and approving 
> registrations will involve a discussion 
> of the metadata-ness of the proposed document.

What a bizarre idea. How about something simple, like
changing the Abstract to say:

   This memo describes a method for locating host
   metadata for Web-based protocols. In this document,
   the word "metadata" is used in the general sense
   of "information about".

 [1] http://tools.ietf.org/html/draft-hammer-hostmeta

> -----Original Message-----
> From: apps-discuss-bounces <at> ietf.org [mailto:apps-discuss-
> bounces <at> ietf.org] On Behalf Of Larry Masinter
> Sent: Thursday, December 31, 2009 11:18 AM
> To: Lisa Dusseault; Apps Discuss
> Subject: RE: I-D Action:draft-nottingham-site-meta-05.txt
> 
> There's a lot of confusion about the use of the term "metadata". In this case,
> the term is being used for something that might more appropriately be seen
> as "default metadata for resources at a site" rather than "site metadata". I
> know it's not really the job of this document to clear up all of the confusion
> around metadata, but I think it would be better if this document were to
> include at least a sentence or two explaining how its use of "metadata"
> is not a close match, for example, to the the primary definition in:
> http://en.wikipedia.org/wiki/Metadata
> 
> or even
> http://www.w3.org/DesignIssues/Metadata.html
> or
> http://www.w3.org/2001/tag/group/track/issues/63
> 
> Larry
> --
> http://larry.masinter.net
> 
> -----Original Message-----
> From: apps-discuss-bounces <at> ietf.org [mailto:apps-discuss-
> bounces <at> ietf.org] On Behalf Of Lisa Dusseault
> Sent: Thursday, December 31, 2009 8:55 AM
> To: Apps Discuss
> Subject: Fwd: I-D Action:draft-nottingham-site-meta-05.txt
> 
> FYI,
> 
> This document is currently in IESG Evaluation with a few DISCUSS issues to be
> cleared.  One of the ADs asked whether this draft had been widely reviewed
> and I wasn't sure it had been posted here though it has definitely been
> discussed on HTTPBIS and in W3C lists.  This draft proposes a namespace for a
> mechanism that can be useful for HTTP-based applications, e.g. if it were
> available and accepted 5-10 years ago, it would have been an alternative for
> some of the bootstrapping problems of WebDAV and CalDAV.
> 
> See also http://tools.ietf.org/html/draft-hammer-hostmeta-05 for an
> example of use of this namespace.
> 
> Lisa
> 
> ---------- Forwarded message ----------
> From:  <Internet-Drafts <at> ietf.org>
> Date: Tue, Dec 29, 2009 at 2:45 PM
> Subject: I-D Action:draft-nottingham-site-meta-05.txt
> To: i-d-announce <at> ietf.org
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
>        Title           : Defining Well-Known URIs
>        Author(s)       : M. Nottingham, E. Hammer-Lahav
>        Filename        : draft-nottingham-site-meta-05.txt
>        Pages           : 8
>        Date            : 2009-12-29
> 
> This memo defines a path prefix for "well-known locations", "/.well-
> known/" in selected URI schemes.
> 
> Status of this Memo
> 
> This Internet-Draft is submitted to IETF in full conformance with the
> provisions of BCP 78 and BCP 79.
> 
> Internet-Drafts are working documents of the Internet Engineering Task
> Force (IETF), its areas, and its working groups.  Note that other groups may
> also distribute working documents as Internet- Drafts.
> 
> Internet-Drafts are draft documents valid for a maximum of six months and
> may be updated, replaced, or obsoleted by other documents at any time.  It
> is inappropriate to use Internet-Drafts as reference material or to cite them
> other than as "work in progress."
> 
> The list of current Internet-Drafts can be accessed at
> http://www.ietf.org/ietf/1id-abstracts.txt.
> 
> The list of Internet-Draft Shadow Directories can be accessed at
> http://www.ietf.org/shadow.html.
> 
> This Internet-Draft will expire on July 3, 2010.
> 
> Copyright Notice
> 
> Copyright (c) 2009 IETF Trust and the persons identified as the document
> authors.  All rights reserved.
> 
> This document is subject to BCP 78 and the IETF Trust's Legal Provisions
> Relating to IETF Documents
> (http://trustee.ietf.org/license-info) in effect on the date of publication of
> this document.  Please review these documents carefully, as they describe
> your rights and restrictions with respect to this document.  Code
> Components extracted from this document must include Simplified BSD
> License text as described in Section 4.e of the Trust Legal Provisions and are
> provided without warranty as described in the BSD License.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-nottingham-site-meta-05.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the Internet-
> Draft.
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce <at> ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> _______________________________________________
> Apps-Discuss mailing list
> Apps-Discuss <at> ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
> _______________________________________________
> Apps-Discuss mailing list
> Apps-Discuss <at> ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
_______________________________________________
Apps-Discuss mailing list
Apps-Discuss <at> ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

On 22/01/2010, at 1:04 AM, Julian Reschke wrote:
> Section 9.1., paragraph 9:
> OLD:
> 
>   [RFC4646]  Phillips, A. and M. Davis, "Tags for Identifying
>              Languages", RFC 4646, September 2006.
> 
> NEW:
> 
>   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
>              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
>              May 2008.

Did you mean to replace 4646 with 5646 here?

Cheers,

--
Mark Nottingham     http://www.mnot.net/

I think perhaps you need to talk to Roy about that...

At the moment, my intent is to remove 'rev' from the BNF and state how new parameters can be added (either by
updating the document, for parameters common to many relation types, or on a per-type / per-application
basis). 

On 22/01/2010, at 8:09 PM, Julian Reschke wrote:

>>> Later on, in the section about HTML4 we find (<http://tools.ietf.org/html/draft-nottingham-http-link-header-07#appendix-B>):
>>> 
>>>  HTML4 also has a "rev" parameter for links that allows a link's
>>>  relation to be reversed.  The Link header does not define a
>>>  corresponding "rev" parameter to allow the expression of these links
>>>  in HTTP headers, due to the confusion this mechanism causes as well
>>>  as conflicting interpretations (briefly, some hold that rev reverses
>>>  the direction of the link, while others that it reverses the
>>>  semantics of the relation itself).
>>> 
>>> I have to admit that I'm still not sure what *in practice* the difference between reversing the link
direction and reversing the link semantics actually is. (Example?)
>> I can add a brief example for the latter.
> 
> Please.
> 
>>> So my preference would be to actually define the rev parameter consistently with this, and then to
discourage it's use due to the other good reasons we heard about that (such as HTML authors typing "rev"
instead of "rel").
>> As previous discussed (quite a bit), HTML2 defines REV as having reversed *semantics*, while HTML4
talks about it creating a "reverse link" -- which are very different things. This feels like a rat hole to me
(thus my attempts to navigate around it).
> 
> Again, HTML 2 defines it as:
> 
>    REV
>            same as the REL attribute, but the semantics of the
>            relationship are in the reverse direction. A link from A
>            to B with REL="X" expresses the same relationship as a
>            link from B to A with REV="X". An anchor may have both
>            REL and REV attributes.
> 
> (<http://tools.ietf.org/html/rfc1866#section-5.7.3>)
> 
> That totally sounds like "reverse link" to me. So, I really really think there's less confusion than some
people claim.

--
Mark Nottingham     http://www.mnot.net/

On Thu, 04 Feb 2010 07:17:58 +0100, Mark Nottingham <mnot <at> mnot.net> wrote:
> At the moment, my intent is to remove 'rev' from the BNF and state how  
> new parameters can be added (either by updating the document, for  
> parameters common to many relation types, or on a per-type /  
> per-application basis).

+1

--

-- 
Anne van Kesteren
http://annevankesteren.nl/

I'm trying to access
http://mail.apps.ietf.org/ietf/charsets/maillist.html,
but http://mail.apps.ietf.org/ as such seems to be down.

Regards,   Martin.
--

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst <at> it.aoyama.ac.jp
_______________________________________________
Apps-Discuss mailing list
Apps-Discuss <at> ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

Mark Nottingham wrote:
> I think perhaps you need to talk to Roy about that...
> 
> At the moment, my intent is to remove 'rev' from the BNF and state how new parameters can be added (either by
updating the document, for parameters common to many relation types, or on a per-type / per-application
basis). 

-1 / +1

Yes, the extensibility point should be documented.

But no, rev should be documented. RFC 2068 already defines what it is, 
so the only thing an extension could ever do is to re-introduce that 
definition.

There may be good reasons to *discourage* it's use, but that's really 
different from not defining it at all.

I think we should park this issue until we know what happens with the 
anchor parameter; after all, a link relation using rel= can always be 
rewritten into one using anchor=.

Best regards, Julian

On 05/02/2010, at 9:07 AM, Roy T. Fielding wrote:

> On Feb 3, 2010, at 10:17 PM, Mark Nottingham wrote:
> 
>> At the moment, my intent is to remove 'rev' from the BNF and state how new parameters can be added (either by
updating the document, for parameters common to many relation types, or on a per-type / per-application
basis). 
> 
> I think we are going around in circles.

Yes, I've been feeling that way for some time now...

> The normal way to document a
> deprecated protocol feature is to include it in the ABNF and state
> that it is deprecated in the prose.  Just like obs-text in HTTP.
> Otherwise, we'll just keep getting asked "what happened to rev?"  

Please make a proposal with text. 

Cheers,

--
Mark Nottingham     http://www.mnot.net/

On 29/01/2010, at 11:45 PM, Julian Reschke wrote:

> Mark Nottingham wrote:
>> ...
>> If that's the case, you're saying that whether the anchor is allowed is really a property of the relation
type, not the application, aren't you? ...
> 
> First of all, I'd prefer to distinguish between (A) "must be processed" and (B) "may be processed,
otherwise link must be rejected altogether".
> 
> I see two purposes for the anchor parameter:
> 
> 1) Making a statement about a subset of the context resource, by specifying a fragment identifier
> 
> 2) Making a statement about a different resource than the context resource, such as
> 
> 2a) because the context is anonymous (such as the response body for a 204, see
<http://greenbytes.de/tech/webdav/draft-brown-versioning-link-relations-07.html#rfc.section.A.1>), or
> 
> 2b) because a reverse link is exposed (anchor as workaround for missing rev parameter)
> 
> I'm still not sure why we would ever make special cases here, except for the known bugs in current
implementations of the Link header where anchor is ignored (so mainly Mozilla/Opera for stylesheet
links). Optimally, we just work with the vendors to get the bugs fixed.
> 
> If that's not possible, allowing an opt-out per relation type might work, as long as behavior (B) would
still be allowed. Is there any relation != "stylesheet" for which this would be relevant?

I think most of them.

E.g., what happens when my weblog
  http://www.mnot.net/blog/
contains a link header
  Link: </blog-publish>; rel="service"; anchor="http://www.intertwingly.net/blog/"
?
After Sam visits my blog, should his browser (assuming it supports Atompub) use my site for editing next
time he wants to post something?

Likewise, what happens after I put this link header in all of my responses?
  Link: <http://www.yahoo.com/>; rel="self"; anchor="http://www.google.com/"
?

Or better yet:
  Link: <http://www.mybank.com.au/mnot>; rel="payment"; anchor="http://www.amazon.com/"

While it may be that browsers in general won't "remember" this information, that doesn't mean that we
should specify things so that they're encouraged to handle these things, knowing full well that they
won't. Opt-in seems much more sane that opt-out here, at least for different resources.

--
Mark Nottingham     http://www.mnot.net/

Julian Reschke wrote:
> Hi,
> 
> I have updated the draft with feedback I got during the informal "last 
> call" that ended yesterday (I added a statement about the relation RFC 
> 2388, and added information about existing implementations).
> 
> See diffs at 
> <http://tools.ietf.org/rfcdiff?url2=draft-reschke-rfc2231-in-http-08.txt>.
> 
> Next, I'll send a publication request to the Apps Area Directors.
> 
> Best regards, Julian
> ...

In the meantime it was discovered that the allowed characters inside 
RFC2231-encoded parameter values differ from what RFC 2231 specifies.

There are two reasons for that:

1) token in RFC 2616 disallows "{" and "}", while token in MIME (RFC 
2231 and RFC 2045) does not; thus these are disallowed in 
rfc2231-in-http as well, and

2) I was disallowing more characters then I wanted to, and also allowed 
":" which shouldn't have been there.

For 1) I have added an explanation, simply pointing out the difference 
(<http://greenbytes.de/tech/webdav/draft-reschke-rfc2231-in-http-latest.html#rfc.issue.tokengrammar>)

For 2), I have now changed the ABNF so that all characters from 
RFC2616's token, except for the special characters used in 2231 ("*", 
"%", "'"), are allowed. 
(<http://greenbytes.de/tech/webdav/draft-reschke-rfc2231-in-http-latest.html#rfc.issue.attrcharvstoken>)

I'm planning to submit a new draft early next week, and then to get to 
IETF LC soonish.

Best regards, Julian

PS: also I have started work on tools that allow sanity checks on ABNF 
productions, such as "set A is expected to be identical to set (B \ C)", 
so things like that can be checked more easily in the future.

Mon	Tue	Wed	Thu	Fri	Sat	Sun

1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28

67	February 2012
210	January 2012
164	December 2011
403	November 2011
68	October 2011
104	September 2011
145	August 2011
231	July 2011
121	June 2011
182	May 2011
85	April 2011
148	March 2011
60	February 2011
89	January 2011
104	December 2010
54	November 2010
80	October 2010
101	September 2010
9	August 2010
140	July 2010
44	June 2010
35	May 2010
86	April 2010
29	March 2010
50	February 2010
69	January 2010
67	December 2009
38	November 2009
91	October 2009
41	September 2009
96	August 2009
134	July 2009
129	June 2009
58	May 2009
121	April 2009
107	March 2009
41	February 2009
75	January 2009
11	December 2008
21	November 2008
7	October 2008
39	September 2008
5	August 2008
44	July 2008
34	June 2008
10	May 2008
31	April 2008
7	March 2008
67	February 2008
66	January 2008
76	December 2007
76	November 2007
66	October 2007
61	September 2007
24	August 2007
23	July 2007
75	June 2007
168	May 2007
2	April 2007
6	March 2007
37	February 2007
47	January 2007
1	December 2006
32	November 2006
22	October 2006
22	September 2006
34	August 2006
5	July 2006
5	June 2006
5	May 2006
7	March 2006
1	January 2006
1	November 2005
3	October 2005
4	August 2005
1	July 2005
21	June 2005
9	May 2005
2	April 2005
8	March 2005
11	February 2005
1	December 2004
5	October 2004
4	September 2004
28	August 2004
2	July 2004

Lisa's Apps Area Activity Report for Dec 2009 & Jan 2010

RE: I-D Action:draft-nottingham-site-meta-05.txt

Re: editorial LC comments on draft-nottingham-http-link-header-07.txt

Re: rev parameter - LC comment on draft-nottingham-http-link-header-07.txt

Re: rev parameter - LC comment on draft-nottingham-http-link-header-07.txt

Apps mail archive server down?

Re: rev parameter - LC comment on draft-nottingham-http-link-header-07.txt

Re: rev parameter - LC comment on draft-nottingham-http-link-header-07.txt

Re: anchor parameter - LC comment on draft-nottingham-http-link-header-07.txt

rfc2231-in-http: token characters, was: FYI: I-D Action:draft-reschke-rfc2231-in-http-08.txt