Kaz Kylheku <433-929-6894@kylheku.com> writes:
> On 2024-01-30, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>> the space before the '<' is also part of the msg-id. I don't know
>> whether that was intended, but I don't think it's relevant to the
>> current discussion.
>
> In the same RFC:
>
> Semantically, the angle bracket characters are not part of the
> msg-id; the msg-id is what is contained between the two angle bracket
> characters. [3.6.4. Identification fields]

Interesting, I missed that. (And I'm disappointed that the text
contradicts the grammar.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 1/30/24 4:44 PM, Keith Thompson wrote:
> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>> On 2024-01-30, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>>> the space before the '<' is also part of the msg-id. I don't know
>>> whether that was intended, but I don't think it's relevant to the
>>> current discussion.
>>
>> In the same RFC:
>>
>> Semantically, the angle bracket characters are not part of the
>> msg-id; the msg-id is what is contained between the two angle bracket
>> characters. [3.6.4. Identification fields]
>
> Interesting, I missed that. (And I'm disappointed that the text
> contradicts the grammar.)
>

Its just a simplification to avoid needing another term in the grammer.

message-id is defined like most top level header definitions, of just
the name of the field, and then a name for the payload.

Thus, the term for the payload needs to define the "optional" parts
([CFWS]), the formatting syntax, ("<", ">") and the semantic pieces.

If msg-id was just defined as 'id-left "@" id-right' to be the actual
definition of a message-id, we would need a middle term something like:

mssage-id = "Message-ID:" msg-id-field CRLF

msg-id-field = [CFWS] "<" msg-id ">" [CFWS]

msg-id = id-left "@: id-right

The Grammer, by its nature defines the grammer, not the semantics.

On 2024-02-03, Richard Damon <richard@damon-family.org> wrote:
> On 1/30/24 4:44 PM, Keith Thompson wrote:
>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>>> On 2024-01-30, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>>>> the space before the '<' is also part of the msg-id. I don't know
>>>> whether that was intended, but I don't think it's relevant to the
>>>> current discussion.
>>>
>>> In the same RFC:
>>>
>>> Semantically, the angle bracket characters are not part of the
>>> msg-id; the msg-id is what is contained between the two angle bracket
>>> characters. [3.6.4. Identification fields]
>>
>> Interesting, I missed that. (And I'm disappointed that the text
>> contradicts the grammar.)
>>
>
> Its just a simplification to avoid needing another term in the grammer.

No, it isn't, because the msg-id child phrase is used only in
on parent, the message-id phrase. The angle bracket and [CWFS]
parts can be freely moved from one to the other without introducing
an unnecessary intermediate rule, like you have done:

> mssage-id = "Message-ID:" msg-id-field CRLF
>
> msg-id-field = [CFWS] "<" msg-id ">" [CFWS]
>
> msg-id = id-left "@: id-right

I.e.:

message-id = "Message-ID:" [CFWS] "<" msg-id ">" [CWFS]

msg-id = id-left "@" id-right

However, this is not the right solution. The right solution is:

message-id-header = "Message-ID:" [CWFS] msg-id-literal [CWFS]

msg-id-literal = "<" id-left "@" id-right ">"

and then in the text:

Semantically, the angle bracket characters of the msg-id-literal
are not part of the message ID denoted by that literal.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> On 1/28/24 16:17, Spiros Bousbouras wrote:
>
>> On Sun, 28 Jan 2024 12:13:47 -0800
>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
> ...
>
>>> Second item: I have the impression that in the last month or so
>>> there have been a handful of postings from James Kuyper, in each
>>> case intended as a direct response to a posting of mine, but not
>>> threaded as a followup posting in the usual newsgroup way. Do
>>> other people also see this? Or more directly, is there someone
>>> who can offer an independent verification of such postings? If
>>> it is happening, does anyone have an idea what might be causing
>>> it?
>>
>> James himself explains it in <uop3fd$1d8ao$1@dont-email.me> .And it
>> is an example of an incorrectly threaded message : his quotations
>> show that it is meant as a direct response to you but the last item
>> in References: is <uje6vv$gei$1@dont-email.me> which is another
>> post by James.
>
> Those links don't work for me. They are interpreted as mailto://
> links, and the link itself says not to mail them. I don't know what
> to do with them, and neither do Thunderbird or (when I'm using
> Google Groups) Firefox or Chrome.
>
> For Tim's benefit, the explanation he's referring to is at the
> beginning of what is (currently) the very last message on the "Call
> to a function" thread, posted by me with a Date: header of Tue, 23
> Jan 2024 14:19:09 -0500.

Thank you. That message is in my input queue but I haven't
yet gotten to it.