Subject: New Version Notification for draft-kamp-httpbis-structure-00.txt (fwd)

From: Poul-Henning Kamp <[email-masked]>
Date: Wed, 05 Oct 2016 13:49:36 +0000

I've tried to turn the "Common Structure" idea into an I-D, and
I've probably done it wrong five ways before breakfast.

It's my hope the WG will adopt this, but in the meantime corrections,
comments and pull requests (https://github.com/bsdphk/id_common_structure)
are most welcome.

Poul-Henning

------- Forwarded Message

A new version of I-D, draft-kamp-httpbis-structure-00.txt
has been successfully submitted by Poul-Henning Kamp and posted to the
IETF repository.

Name:           draft-kamp-httpbis-structure
Revision:       00
Title:          HTTP header common structure
Document date:  2016-10-05
Group:          Individual Submission
Pages:          13
URL:            https://www.ietf.org/internet-drafts/draft-kamp-httpbis-structure-00.txt
Status:         https://datatracker.ietf.org/doc/draft-kamp-httpbis-structure/
Htmlized:       https://tools.ietf.org/html/draft-kamp-httpbis-structure-00

Abstract:
   An abstract data model for HTTP headers, "Common Structure", and a
   HTTP/1 serialization of it, generalized from current HTTP headers.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

------- End of Forwarded Message

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

---

From: Kari Hurtta <[email-masked]>
Date: Thu, 13 Oct 2016 06:34:30 +0300 (EEST)

> Htmlized:       https://tools.ietf.org/html/draft-kamp-httpbis-structure-00

3.  HTTP/1 serialization of HTTP header Common Structure
https://tools.ietf.org/html/draft-kamp-httpbis-structure-00#section-3

|       h1_unicode_string = DQUOTE *(
|                       ( "\" DQUOTE )
|                       ( "\" "\" ) /
|                       ( "\" "u" 4*HEXDIG ) /
|                       0x20-21 /
|                       0x23-5B /
|                       0x5D-7E /
|                       0x80-F7
|                       ) DQUOTE
|               # XXX: how to say/import "UTF-8 encoding" ?
|               # HTTP1 unfriendly codepoints (00-1f, 7f) must be
|               # encoded with \uXXXX escapes

How about

RFC 3629: UTF-8, a transformation format of ISO 10646
https://tools.ietf.org/html/rfc3629

4.  Syntax of UTF-8 Byte Sequences
https://tools.ietf.org/html/rfc3629#section-4

|   UTF8-octets = *( UTF8-char )
|   UTF8-char   = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4
|   UTF8-1      = %x00-7F
|   UTF8-2      = %xC2-DF UTF8-tail
|   UTF8-3      = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2( UTF8-tail ) /
|                 %xED %x80-9F UTF8-tail / %xEE-EF 2( UTF8-tail )
|   UTF8-4      = %xF0 %x90-BF 2( UTF8-tail ) / %xF1-F3 3( UTF8-tail ) /
|                 %xF4 %x80-8F 2( UTF8-tail )
|   UTF8-tail   = %x80-BF
|
|   NOTE -- The authoritative definition of UTF-8 is in [UNICODE].  This
|   grammar is believed to describe the same thing Unicode describes, but
|   does not claim to be authoritative.  Implementors are urged to rely
|   on the authoritative source, rather than on this ABNF.

This

|               # HTTP1 unfriendly codepoints (00-1f, 7f) must be
|               # encoded with \uXXXX escapes

means that you can not use UTF8-1 however.

Are uou meaining following:

h1_unicode_utf8 = h1_utf8_1 / UTF8-2 / UTF8-3 / UTF8-4
h1_utf8_1 = ( "\" "\" ) /
            ( "\" "u" 4*HEXDIG ) /
            0x20-21 / 
            0x23-5B / 
            0x5D-7E /
            0x80-F7
UTF8-2 = <UTF8-2, defined in RFC 3629, Section 4>
UTF8-3 = <UTF8-3, defined in RFC 3629, Section 4>
UTF8-4 = <UTF8-4, defined in RFC 3629, Section 4>

/ Kari Hurtta

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 13 Oct 2016 06:27:14 +0000

--------
In message <[email-masked]>, Kari Hurtta wri

>Are you meaining following:
>

Yes, that looks like the a way to do it.

BTW: The ID lives here, pull requests are welcome:

	https://github.com/bsdphk/id_common_structure

---

From: Kari Hurtta <[email-masked]>
Date: Sat, 15 Oct 2016 09:45:23 +0300 (EEST)

|       h1_element = identifier * (";" identifier ["=" h1_value])
|
|       h1_value = identifier /
|               number /
|               h1_ascii_string /
|               h1_unicode_string /
|               h1_blob /
|               h1_timestamp /
|               h1_common-structure
|
|       h1_ascii_string = DQUOTE *(
|                       ( "\" DQUOTE ) /
|                       ( "\" "\" ) /
|                       0x20-21 /
|                       0x23-5B /
|                       0x5D-7E
|                       ) DQUOTE
|               # This is a proper subset of h1_unicode_string
|               # NB only allowed backslash escapes are \" and \\
|
|       h1_unicode_string = DQUOTE *(
|                       ( "\" DQUOTE )
|                       ( "\" "\" ) /
|                       ( "\" "u" 4*HEXDIG ) /
|                       0x20-21 /
|                       0x23-5B /
|                       0x5D-7E /
|                       0x80-F7
|                       ) DQUOTE
|               # XXX: how to say/import "UTF-8 encoding" ?
|               # HTTP1 unfriendly codepoints (00-1f, 7f) must be
|               # encoded with \uXXXX escapes
|
|       h1_blob = "'" base64 "'"
|               # XXX: where to import base64 from ?

Perhaps structure from

Indicating Character Encoding and Language for HTTP Header Field Parameters
https://tools.ietf.org/html/draft-ietf-httpbis-rfc5987bis-03

should also be parseable as common structure ?

That makes:

h1_value  /= <ext-value; defined on [draft-ietf-httpbis-rfc5987bis]>
           ; This MUST NOT be produced expect when relevant
	   ; specification "opt in" syntax, see [draft-ietf-httpbis-rfc5987bis]
	   ; <h1_unicode_string> is preferred instead.

Is this parseable unambiguously?

Anyway common strcture syntax must take account that draft-ietf-httpbis-rfc5987bis-03
syntax is not parsed as some other common structure syntax.

3.2.1.  Definition
https://tools.ietf.org/html/draft-ietf-httpbis-rfc5987bis-03#section-3.2.1

gives

|     ext-value     = charset  "'" [ language ] "'" value-chars
|                   ; like RFC 2231's <extended-initial-value>
|                   ; (see [RFC2231], Section 7)
|
|     charset       = "UTF-8" / mime-charset
|
|     mime-charset  = 1*mime-charsetc
|     mime-charsetc = ALPHA / DIGIT
|                   / "!" / "#" / "$" / "%" / "&"
|                   / "+" / "-" / "^" / "_" / "`"
|                   / "{" / "}" / "~"
|                   ; as <mime-charset> in Section 2.3 of [RFC2978]
|                   ; except that the single quote is not included
|                   ; SHOULD be registered in the IANA charset registry
|
|     language      = <Language-Tag, see [RFC5646], Section 2.1>
|
|     value-chars   = *( pct-encoded / attr-char )
|
|     pct-encoded   = "%" HEXDIG HEXDIG
|                   ; see [RFC3986], Section 2.1
|
|     attr-char     = ALPHA / DIGIT
|                   / "!" / "#" / "$" / "&" / "+" / "-" / "."
|                   / "^" / "_" / "`" / "|" / "~"
|                   ; token except ( "*" / "'" / "%" )

/ Kari Hurtta

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 15 Oct 2016 06:57:10 +0000

--------
In message <[email-masked]>, Kari Hurtta wri

>should also be parseable as common structure ?

It would be an unnecessary complication of Common Structure.

Just add a lang="....." element to your dictionary if you need it.

---

From: Kari Hurtta <[email-masked]>
Date: Sat, 15 Oct 2016 11:20:47 +0300 (EEST)

Poul-Henning Kamp <[email-masked]>: (Sat Oct 15 09:57:10 2016)
> Just add a lang="....." element to your dictionary if you need it.

Headers which may use rfc5987bis are then "uncommon structure".

Appendix B.  Implementation Report
https://tools.ietf.org/html/draft-ietf-httpbis-rfc5987bis-03#appendix-B

|   The encoding defined in this document currently is used for two
|   different HTTP header fields:
|
|   o  "Authorization" (as used in HTTP Digest Authentication, defined in
|      [RFC7616]),
|
|   o  "Content-Disposition", defined in [RFC6266], and
|
|   o  "Link", defined in [RFC5988].

Appendix C.  RFC723x headers with "uncommon structure"
https://tools.ietf.org/html/draft-kamp-httpbis-structure-00#appendix-C

|       Authorization       [RFC7235, Section 4.2]

ok

"Content-Disposition" and "Link" are not mentioned
on draft-kamp-httpbis-structure.

Someone may think that "Content-Disposition"
is "common structure":

Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)
https://tools.ietf.org/html/rfc6266

4.1.  Grammar
https://tools.ietf.org/html/rfc6266#section-4.1

|     content-disposition = "Content-Disposition" ":"
|                            disposition-type *( ";" disposition-parm )
|
|     disposition-type    = "inline" | "attachment" | disp-ext-type
|                         ; case-insensitive
|     disp-ext-type       = token
|
|     disposition-parm    = filename-parm | disp-ext-parm
|
|     filename-parm       = "filename" "=" value
|                         | "filename*" "=" ext-value
|
|     disp-ext-parm       = token "=" value
|                         | ext-token "=" ext-value
|     ext-token           = <the characters in token, followed by "*">

/ Kari Hurtta

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 15 Oct 2016 08:29:24 +0000

--------
In message <[email-masked]>, Kari Hurtta writes

>Headers which may use rfc5987bis are then "uncommon structure".

I think rfc5987 is a bad idea, and it is one of my motivations for
pushing for Common Structure.

>on draft-kamp-httpbis-structure.

No, I only surveyed RFC723x.

>Someone may think that "Content-Disposition"

Which is why I propose to add a field to the IANA registry so there
will be a definitive answer, rather than everybody having to guess.