At 23:05 04/10/26, Bruce Lilly wrote:
>On Mon October 25 2004 00:42, Martin Duerst wrote:
>>
>> I tried to adapt the syntax below to the changes I made.
>> The problem with URIs/URI references is solved by RFC2396bis.
>> I don't think [FWS] and *WSP are needed, the syntax given for
>> similar headers in RFC 2822 doesn't explicitly mention these,
>> either.
>>
>> Regards, Martin.
>
>Actually, RFC 2822 does include [FWS] etc., but they are part of
>the lower-level construct specifications, so aren't readily apparent
>when looking only at the field definitions; they do become visible
>if one expands "domain", "dot-atom", "date-time", etc. That
>does not apply to the constructs used in the proposed field, since
>the ABNF for those constructs does not explicitly include [FWS]
>etc. Incidentally, the successor to RFC 2822 may change in that
>respect; a proposed revised grammar has been discussed on the
>ietf-822 list.
>
>Given the draft ABNF
>
> archived-at = "Archived-At:" '<' URI '>' CRLF ; URI not empty
>
>and the example implicit in the text
>
> As an example, the URI
>
"http://www.w3.org/mid/0I5U00G08DFGCR(_at_)mailsj-v1(_dot_)corp(_dot_)adobe(_dot_)com",
> containing the message id
"0I5U00G08DFGCR(_at_)mailsj-v1(_dot_)corp(_dot_)adobe(_dot_)com",
> is redirected to the URI of this message in the W3C mailing-list
> archive at http://lists.w3.org/Archives/Public/uri/2004Oct/0017.html.
>
>implies that
>
> Archived-At:<http://lists.w3.org/Archives/Public/uri/2004Oct/0017.html>
>
>is legal but
>
> Archived-At: <http://lists.w3.org/Archives/Public/uri/2004Oct/0017.html>
> ^ N.B. SP here
> Archived-At: (w3 list archive)
> <http://lists.w3.org/Archives/Public/uri/2004Oct/0017.html>
>
>etc. are not legal.
Thanks for pointing this out. I changed the definition to:
archived-at = "Archived-At:" *WSP '<' URI '>' CRLF ; URI not empty
(and similar for obs-archived-at), because that's what was intended.
No whitespace after the colon looks really weird, but I don't care
about comments.
>Concerning that example, please note that a message identifier (RFC 2822)
>includes angle brackets; i.e. the message id is presumably
>"<0I5U00G08DFGCR(_at_)mailsj-v1(_dot_)corp(_dot_)adobe(_dot_)com>". When
using mid
>schemes or conversions which implicitly involve msg-id to mid or
>mid-like constructs, it might be advisable to note the difference in
>angle bracket inclusion and/or to refer to the mid RFC (2387) as a
>normative or informative reference. The angle bracket issue has also
>been recently discussed on the ietf-822 list.
I have tweaked the text in a way that I hope will avoid
misunderstandings.
>Note also that RFC 2822 has provisions in the parse (obs-) syntax
>for accommodation of whitespace between the field name and the colon
>delimiter (which was allowed in earlier versions of the text message format).
>You might wish to consider whether to provide for that for parsing,
>particularly in the obs- rule for X-Archived-At.
Considered but left out. There are no X-Archived-At headers
out that have such a space, so we don't need to introduce this.
Regards, Martin.
Regards, Martin.