Discussion of matters related to the applications area of IETF

headers Lisa Dusseault | 2 Feb 19:45

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

FYI.

http://www.ietf.org/internet-drafts/draft-nottingham-site-meta-01.txt

Begin forwarded message:

> From: IETF I-D Submission Tool <idsubmission <at> ietf.org>
> Date: 10 February 2009 11:03:13 PM
> To: mnot <at> mnot.net
> Cc: eran <at> hueniverse.com
> Subject: New Version Notification for draft-nottingham-site-meta-01
>
>
> A new version of I-D, draft-nottingham-site-meta-01.txt has been  
> successfuly submitted by Mark Nottingham and posted to the IETF  
> repository.
>
> Filename:	 draft-nottingham-site-meta
> Revision:	 01
> Title:		 Host Metadata for the Web
> Creation_date:	 2009-02-10
> WG ID:		 Independent Submission
> Number_of_pages: 12
>
> Abstract:
> This memo describes a method for locating host-specific metadata for
> the Web.
>
>
>
> The IETF Secretariat.
>
>

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

Going through draft-nottingham-site-meta-01:
> 3. The host-meta File Format

> As with HTTP headers, field-names are not case-sensitive,  
> unrecognised field-names SHOULD be silently ignored when parsing  
> this format, and ordering of fields SHOULD NOT be considered  
> significant unless specified otherwise. Additionally, although the  
> syntax does not explicitly allow empty lines between fields, parsers  
> SHOULD silently discard them (i.e., be permissive in what they  
> accept). Field content is constrained by the specification indicated  
> by its associated field-name.

What's the cost of just permitting empty lines between fields in the  
sytnax vs having the current "SHOULD parse"?  The current text sounds  
like a gratuitous interop problem to me.
> 5. Minting New meta-fields

> Applications that wish to mint new meta-fields for use in the host-  
> meta format MUST register them in the host-meta field-registry,  
> following the procedures in Section 7.2. Field-names MUST conform to  
> the field-name ABNF Section 3, and field-value syntax MUST be well-  
> defined (e.g., using ABNF, or a reference to the syntax of an  
> existing header field-value). Field-values SHOULD use the ISO-859-1  
> character encoding. If a field-value applies to a scope other than  
> the entire authority, that scope MUST be well-defined.

Editorial nit: ISO-8859-1 is missing an 8 here.
More substantially, is there any particular reason to not just go with  
utf-8 here?  After all, the content type is *appplication*/host-meta  
anyway.

--
Thomas Roessler, W3C  <tlr <at> w3.org>

Reading draft-nottingham-site-meta-01...

> 4. Discovering host-meta Files

> The metadata for a given authority can be discovered by  
> dereferencing the path /host-meta on the same authority. For  
> example, for an HTTP URI [RFC2616], the following request would  
> obtain metadata for the authority "www.example.com:80";

Editorial nit: That semicolon wants to be a colon.

> GET /host-meta HTTP/1.1
> Host: www.example.com

It is somewhat unclear what the scope of the host-meta file is, or  
more precisely, how the URI for the host-meta file is derived from the  
URI of the resource that the metadata apply to.

Section 4 seems to suggest that the URI is maybe generated by  
dereferencing the relative URI reference /host-meta using the  
resource's URI as the base URI, but it doesn't say that clearly; the  
use of "authority" suggests that the choice of the protocol is  
actually up to the implementation.

 From the previous apps-discuss thread, it seems like the main use  
case for permitting metadata to leak across schemes (and therefore,  
typically ports -- though ports and schemes are strictly speaking  
orthogonal) lies with URI schemes that do not have a resource  
retrieval operation readily available, e.g., mailto.

On the other hand, I'm extremely wary about anything near HTTP that  
might tear down origin boundaries without a great deal of care.  E.g.,  
a purely authority-based approach might permit metadata to leak from  
the HTTP part of a site (where no integrity protection is given) into  
its HTTPS part (where integrity protection and authenticity of data is  
deemed important), possibly permitting attacks against web  
applications that are ostensibly protected -- as is alluded to in the  
security considerations.

The obvious solution to that part of the puzzle is to let the  
mechanism default to the same URI scheme, unless there is a specific  
convention to the contrary.  That should cover any URI schemes for  
which a safe retrieval operation is defined (HTTP, HTTPS, FTP come to  
mind).

For other URI schemes, one could either punt on this issue completely,  
define a default fall-back to HTTP (or HTTPS, depending on which of  
the two better matches the security properties of the protocol in  
question), or actually say explicitly what's the correct scheme.

Thoughts?

--
Thomas Roessler, W3C  <tlr <at> w3.org>

On 11 Feb 2009, at 01:31, Mark Nottingham wrote:

> Gentle reminder; the draft asks for discussion on www-talk. Sending  
> followups there (I should have mentioned this in the announcement,  
> sorry)...

(and I should read instructions.... apologies)

>> The obvious solution to that part of the puzzle is to let the  
>> mechanism default to the same URI scheme, unless there is a  
>> specific convention to the contrary.  That should cover any URI  
>> schemes for which a safe retrieval operation is defined (HTTP,  
>> HTTPS, FTP come to mind).
>
> I'm happy to clarify this by either adding scheme/protocol to the  
> (host, port) tuple (although we'll probably have to come up with a  
> different term than "authority"; PLEASE don't say "endpoint" ;),  
> which will affect both the default scoping of application as well as  
> the discovery mechanism, or just limiting it to discovery.

I'd use the (scheme, host, port) triple to identify the endpoints that  
we're dealing with here, both for scope and discovery. Adam Barth's  
draft-abarth-origin gives a canonicalization procedure for these  
tuples.  That will be useful when the tuples derived from different  
URIs need to be compared, to determine whether one is in the same site  
metadata scope as the other.

Calling that kind of triple "an origin" seems fine, and is consistent  
with the usage of that word in draft-abarth-origin and elsewhere.

The benefit of using the triple for both discovery and scope is that  
you don't acquire yet another possible cross-origin channel in the  
browser.

>> For other URI schemes, one could either punt on this issue  
>> completely, define a default fall-back to HTTP (or HTTPS, depending  
>> on which of the two better matches the security properties of the  
>> protocol in question), or actually say explicitly what's the  
>> correct scheme.
>
> I'm inclined to punt on it. Default fall-back to HTTP makes too many  
> assumptions.

Same inclination here, actually.

(diverting to www-talk, too...)

On 11 Feb 2009, at 01:20, Mark Nottingham wrote:

> Yeah, I'm not completely happy with it yet. The thought was that  
> since blank lines don't introduce ambiguity here, they're not  
> harmful. OTOH one of my goals for the format is to allow existing  
> HTTP header and MIME parsers (e.g., in Python) to be used on the  
> format, and they very well may barf on a blank line.

Well, they'll barf on blank lines and declare the header over;  
changing that within the parser (or just restarting it on the rest of  
the file) should be relatively cheap.

BTW, I notice that this draft is silent on the HTTP header syntax's  
combining feature for multiple occurences of the same field (last  
paragraph of 4.2, RFC 2616); I suspect that to be one of the more  
likely causes for surprises if HTTP header parsers are re-used.  (No  
such risk with MIME parsers.)

Finally, why disallow whitespace stuffed folding?  It's pretty useful  
to make long lines editable, and I suspect that we're assuming /host- 
meta to be the product of some human with emacs in their hands.    
Implementing it is easy, and a given if existing parsers are used.

> So, the right thing to do might be to explicitly disallow them, both  
> in BNF and prose. Eran, thoughts?

I'd just prefer to not have the BNF say "no empty lines", and then  
have prose that says the opposite, but with a SHOULD.

>>> 5. Minting New meta-fields
>>
>>> Applications that wish to mint new meta-fields for use in the  
>>> host- meta format MUST register them in the host-meta field- 
>>> registry, following the procedures in Section 7.2. Field-names  
>>> MUST conform to the field-name ABNF Section 3, and field-value  
>>> syntax MUST be well- defined (e.g., using ABNF, or a reference to  
>>> the syntax of an existing header field-value). Field-values SHOULD  
>>> use the ISO-859-1 character encoding. If a field-value applies to  
>>> a scope other than the entire authority, that scope MUST be well- 
>>> defined.
>>
>> Editorial nit: ISO-8859-1 is missing an 8 here.
>
> That one always gets me, thanks.
>
>> More substantially, is there any particular reason to not just go  
>> with utf-8 here?  After all, the content type is *appplication*/ 
>> host-meta anyway.
>
> Same as above; allowing existing parsers and serialisation libraries  
> to be used. That said, there have been many arguments in HTTPbis  
> that existing libraries won't harm non-ASCII characters in transit,  
> but IIRC no one has actually gone out and surveyed what they do...

That suggests that it's a coin toss, unless the mythical "someone"  
does that work.  May I, in that event, suggest that we use a coin  
biased in favor of broader internationalization, i.e., UTF-8?

On 11 Feb 2009, at 02:18, Mark Nottingham wrote:

[ASCII vs UTF-8]

> OTOH we're talking about a SHOULD here. Maybe it just needs more  
> careful guidance; i.e., that you should stick to ASCII unless you're  
> conveying elements for presentation to end users.

Well, one point to consider is how you expect IRIs and IRI references  
to be represented.

There's one school of thought (more common in the IETF crowd) that  
says that these should be convereted to ASCII early, and therefore  
shouldn't occur here.

The other school of thought (more common at W3C) says that they're  
fine in the places where XML and other document formats have always  
accepted URIs, and therefore should be representable in this spot.

There are some properties of the direction that the IDNA update effort  
is going into that suggest that the IETF school of thought is less  
likely to cause interoperability problems.

The other question is what the cost of violating this SHOULD is.   
Assume that some people have a really good reason to violate an ASCII  
or ISO-8859-1 SHOULD, and actually go for UTF-8.  You now get mixed  
character sets in a single metadata file.  I'm not sure that's  
desirable...

(BTW, are we just going down the rathole of defining yet another tag- 
value format that's subtly different?  Maybe the spec should just say  
"use HTTP header format, but with UTF-8", or "use RFC 822, but with  
UTF-8".)

--
Thomas Roessler, W3C  <tlr <at> w3.org>

(not sure how my work email got into this thread... but please replace it with this one)

> From: Mark Nottingham [mailto:mnot <at> yahoo-inc.com]
> Sent: Tuesday, February 10, 2009 4:21 PM
>
> On 11/02/2009, at 12:38 AM, Thomas Roessler wrote:
>
> >> As with HTTP headers, field-names are not case-sensitive,
> >> unrecognised field-names SHOULD be silently ignored when parsing
> >> this format, and ordering of fields SHOULD NOT be considered
> >> significant unless specified otherwise. Additionally, although the
> >> syntax does not explicitly allow empty lines between fields,
> >> parsers SHOULD silently discard them (i.e., be permissive in what
> >> they accept). Field content is constrained by the specification
> >> indicated by its associated field-name.
> >
> > What's the cost of just permitting empty lines between fields in the
> > sytnax vs having the current "SHOULD parse"?  The current text
> > sounds like a gratuitous interop problem to me.
>
> Yeah, I'm not completely happy with it yet. The thought was that since
> blank lines don't introduce ambiguity here, they're not harmful. OTOH
> one of my goals for the format is to allow existing HTTP header and
> MIME parsers (e.g., in Python) to be used on the format, and they very
> well may barf on a blank line.
>
> So, the right thing to do might be to explicitly disallow them, both
> in BNF and prose. Eran, thoughts?

I wanted to either allow in both or explicitly disallow in both. Allowing them has the advantage of
disabling the ability to stick other payload after the line break. But I see the logic in following the HTTP
header structure which was my original inspiration for this general structure. I would say I am neutral
with slight lean towards disallowing.

EHL

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

Wow, this draft is scary.  I haven't seen the prior discussion of this
draft, but we should learn from the mistakes of Flash's
crossdomain.xml policy file.  In particular, you should require that
the host-meta file should be served with a specific mime type (ignore
the response if the mime type is wrong.  This protects servers that
let users upload content from having attackers upload a bogus
host-meta file.

Also, if you want this feature to be useful for Web browsers, you
should align the scope of the host-meta file with the notion or origin
(not authority).  Section 4 seems to imply that the scope is
"www.example.com:80" but Section 6 implies the scope is
"https://www.example.com".  In fact, computing the origin of a URL
correctly is more complex than this draft assumes.  For details, see
my origin draft.

That said, I think host-meta would be super useful if specified correctly.

Adam

On Tue, Feb 10, 2009 at 6:57 AM, Thomas Roessler <tlr <at> w3.org> wrote:
> Reading draft-nottingham-site-meta-01...
>
>> 4. Discovering host-meta Files
>
>> The metadata for a given authority can be discovered by dereferencing the
>> path /host-meta on the same authority. For example, for an HTTP URI
>> [RFC2616], the following request would obtain metadata for the authority
>> "www.example.com:80";
>
> Editorial nit: That semicolon wants to be a colon.
>
>> GET /host-meta HTTP/1.1
>> Host: www.example.com
>
> It is somewhat unclear what the scope of the host-meta file is, or more
> precisely, how the URI for the host-meta file is derived from the URI of the
> resource that the metadata apply to.
>
> Section 4 seems to suggest that the URI is maybe generated by dereferencing
> the relative URI reference /host-meta using the resource's URI as the base
> URI, but it doesn't say that clearly; the use of "authority" suggests that
> the choice of the protocol is actually up to the implementation.
>
> From the previous apps-discuss thread, it seems like the main use case for
> permitting metadata to leak across schemes (and therefore, typically ports
> -- though ports and schemes are strictly speaking orthogonal) lies with URI
> schemes that do not have a resource retrieval operation readily available,
> e.g., mailto.
>
> On the other hand, I'm extremely wary about anything near HTTP that might
> tear down origin boundaries without a great deal of care.  E.g., a purely
> authority-based approach might permit metadata to leak from the HTTP part of
> a site (where no integrity protection is given) into its HTTPS part (where
> integrity protection and authenticity of data is deemed important), possibly
> permitting attacks against web applications that are ostensibly protected --
> as is alluded to in the security considerations.
>
> The obvious solution to that part of the puzzle is to let the mechanism
> default to the same URI scheme, unless there is a specific convention to the
> contrary.  That should cover any URI schemes for which a safe retrieval
> operation is defined (HTTP, HTTPS, FTP come to mind).
>
> For other URI schemes, one could either punt on this issue completely,
> define a default fall-back to HTTP (or HTTPS, depending on which of the two
> better matches the security properties of the protocol in question), or
> actually say explicitly what's the correct scheme.
>
> Thoughts?
>
> --
> Thomas Roessler, W3C  <tlr <at> w3.org>
>
>

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 Jan 2009

Fwd: New Version Notification for draft-nottingham-site-meta-01

host-meta file format comments (draft-nottingham-site-meta-01)

Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)

Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)

Re: host-meta file format comments (draft-nottingham-site-meta-01)

Re: host-meta file format comments (draft-nottingham-site-meta-01)

RE: host-meta file format comments (draft-nottingham-site-meta-01)

FW: I-D Action:draft-hammer-discovery-02.txt

Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)