headers
Charles Lindsey | 3 Jan 2005 17:15
Picon
Picon

Re: msg-id


In <41D5A073.7809 <at> xyzzy.claranet.de> Frank Ellermann <nobody <at> xyzzy.claranet.de> writes:

>Charles Lindsey wrote:

>> the _real_ format, if there is such a thing, is totally
>> irrelevant, provided that it is at least permitted.

>For our discussion about the news URL I read some stuff in
><http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#host>
>2396bis uses this syntax:

>| IP-literal = "[" ( IPv6address / IPvFuture  ) "]"
>| IPvFuture  = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )

>For IPv6 there's a pointer to RfC 3513 and the complete fun.
>There's no pointer for IPv4 (so probably the only existing
>form is 2821, and 2396bis couldn't use it for several reasons).

All the world and his dog are giving a conflicting syntax for
<ipv6address>, and I do not think we want to get involved. Just leave it
as RFC 2822 has it, with only the essentual technical changes. Will lead
to much less aggro when the time for RFC 2822bis comes.

>BTW, you already gave the reason for id-right, you couldn't use
>the right part of addr-spec (= domain) in RfC 2822 because that
>allows CFWS.  Therefore you invented id-left and id-right, only
>a hack to get addr-spec minus any CFWS.

No, I didn't invent id-left and id-right. RFC 2822 did that.
(Continue reading)

Permalink | Reply | 15 comments |
headers
Charles Lindsey | 3 Jan 2005 16:37
Picon
Picon

Re: Archive


In <41D5A71A.118B <at> xyzzy.claranet.de> Frank Ellermann <nobody <at> xyzzy.claranet.de> writes:

>No, I still don't like the filename parameter.  You said that
>the purposes is (quote) "its  possible future use, and also to
>allow future extensions to add further parameters".

>RfC 3834 found a solution for the latter.

RFC 3834 found exactly the same solution that we are proposing for Archive
and Injction-Info. Yes, the present wording in USEFOR is not clear and
needs more work, and maybe RFC 3834 will provide some suitable wording. So
I don't really see what point you are trying to make, or what you find
wrong with my words "future use, and also to allow future extensions to
add further parameters".

>  You could copy its
>opt-parameter-list + explanation to Archive and Injection-Info
>if you like it.  Not the token, and maybe you could manage to
>just forget the phrase "(as amended by [N4.RFC2231])", please ?

But no, I don't think we can drop the mention of RFC 2231 altogether,
though I have no problem with some wording to point out that its use
(well, at least the multi-line bit) within Netnews is neither necessary
nor desirable.

>RfC 2231 is firmly on place three (after RfC 3865 and ISO 3166)
>of my shit list.  MIME was a piece of art, what they did to it
>in RfC 2231 is a crime.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Charles Lindsey | 3 Jan 2005 17:07
Picon
Picon

Re: FWS problem


In <41D593A7.5D5F <at> xyzzy.claranet.de> Frank Ellermann <nobody <at> xyzzy.claranet.de> writes:

>Charles Lindsey wrote:

>> only because of loud protests by the server implementors that
>> we agreed to make exceptions for the Newsgroups and Path
>> headers, etc, but only on account of the performance hits.

>Supersedes: is relevant for news servers, like Control:, where
>you also have only three [FWS] or in the fixed variant two *WSP
>and still one [FWS] in control-message.  No [CFWS] in Control:

No, [CFWS] should appear as normal in the Control header. That is a
mistake in USEFOR (cf draft-13), because the WG never asked for comments
to be disallowed in Control (the performance-hit argument would clearly
not apply).

>IMHO you should get rid of your special USEFOR msg-id, there's
>exactly one line where you use it:

>| message-id  = "Message-ID:" SP msg-id CRLF

>For Lines: you could say that it's now deprecated and the old
>syntax was Lines = "Lines:" SP *WSP 1*DIGIT *WSP CRLF

>That's no lie, and if somebody tries new tricks with deprecated
>headers, then old software might fail for Lines: (huge)9999(!)

>> If there is something you want to forbid in a standard (such
(Continue reading)

Permalink | Reply | 2 comments |
headers
Frank Ellermann | 4 Jan 2005 00:56
Picon
Picon

Re: Archive


Charles Lindsey wrote:

> I don't really see what point you are trying to make, or what
> you find wrong with my words "future use, and also to allow
> future extensions to add further parameters".

You say:  We need filename for further parameters.  I say:  No,
opt-parameter-list could do this trick without a filename.  The
point is that I'm against the filename, and maybe Bruce also
doesn't like it:

<http://article.gmane.org/gmane.ietf.usenet.format/27852> and
<http://article.gmane.org/gmane.ietf.usenet.format/28020> (6.)

>> maybe also the token ?  I could then write
>> Archive: creativecommons.org_licenses_by-nc-sa_2.0_de

> Eh?

A MIME token can't be an URL, therefore I replaced / by _ in
<URL:http://creativecommons.org/licenses/by-nc-sa/2.0/de/> and
(ab)used the result as "copyright notice" instead of the token
"No" in Archive: No

That's what users normally expect if they use X-NoArchive: Yes

                           Bye, Frank
(Continue reading)

Permalink | Reply | 4 comments |
headers
Frank Ellermann | 4 Jan 2005 03:14
Picon
Picon

Re: FWS problem


Charles Lindsey wrote:

> [CFWS] should appear as normal in the Control header. That is
> a mistake in USEFOR (cf draft-13), because the WG never asked
> for comments to be disallowed in Control (the performance-hit
> argument would clearly not apply).

Control: cancel <unique <at> mdomain> / Supersedes; <unique <at> mdomain>
are common cases, and if an implementation has a problem with
[CFWS] in an ordinary Message-ID: <unique <at> mdomain> then why are
Control: cancel / Supersedes: <unique <at> mdomain> less critical ?

BTW, s-o-1036 allows a msg-id-list in Control: cancel, but you
stick to 1036 allowing only one msg-id, is this what you want ? 

 [remove the single instance of "msg-id"]
> You may have a point there, but there is the problem that we
> use <msg-id> all over the place in the semantics, and most of
> those now need to be <msg-id-core>. So probably better to
> s/msg-id-core/msg-id/ throughout, and give the necessary
> [CFWS], CFWS or [FWS] explicitly in the syntax in the
> relevant headers.

Yes, that's a good idea.  Normally I hate it when you redefine
a 2822 term instead of introducing a new term, but in this case
it's a feature:  Your msg-id = msg-id-core is in fact the real
thing, and we want it to replace msg-id also in 2822 (of course
without explicitly saying so ;-)
                                 Bye, Frank
(Continue reading)

Permalink | Reply | 1 comment |
headers
Charles Lindsey | 4 Jan 2005 13:37
Picon
Picon

Re: FWS problem


In <41D9FBED.7C12 <at> xyzzy.claranet.de> Frank Ellermann <nobody <at> xyzzy.claranet.de> writes:

>Charles Lindsey wrote:

>> [CFWS] should appear as normal in the Control header. That is
>> a mistake in USEFOR (cf draft-13), because the WG never asked
>> for comments to be disallowed in Control (the performance-hit
>> argument would clearly not apply).

>Control: cancel <unique <at> mdomain> / Supersedes; <unique <at> mdomain>
>are common cases, and if an implementation has a problem with
>[CFWS] in an ordinary Message-ID: <unique <at> mdomain> then why are
>Control: cancel / Supersedes: <unique <at> mdomain> less critical ?

The problem is not with [CFWS] surrounding a <msg-id> as such, but with
transit servers which need to extract the Message-ID header from _every_
message passing through them, and for which ignoring any comment that
might be present would be a significant performance hit. That just is not
true of the Control and Supersedes headers, which are only of interest to
serving agents and which, when detected, are hived off to a separate piece
of code which can deconstruct them at leisure (since they form only a
small proportion of the overall article count).

Note that there is still a generic "SHOULD NOT generate yet" for all
comments in News headers that were not known in the days of 1036, but to
be fully compliant software MUST eventually be able to accept and ignore
them, since they are a general property of _all_ headers. The only
exceptions are the few that would slow down those transit servers too
much, where we have agreed a permanent ban on them.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charles Lindsey | 4 Jan 2005 13:03
Picon
Picon

Re: Archive


In <41D9DBB6.3F14 <at> xyzzy.claranet.de> Frank Ellermann <nobody <at> xyzzy.claranet.de> writes:

>Charles Lindsey wrote:

>> I don't really see what point you are trying to make, or what
>> you find wrong with my words "future use, and also to allow
>> future extensions to add further parameters".

>You say:  We need filename for further parameters.  I say:  No,
>opt-parameter-list could do this trick without a filename.  The
>point is that I'm against the filename, and maybe Bruce also
>doesn't like it:

Ah! So you want the Archive header to have provision for a list of
MIME-style parameters (just like we originally intended for all the news
headers), but with no specific parameters defined just yet. Then the
filename parameter can be added later if/when there is a specific need for
it.

Anyone else happy with that arrangement? I see no problem.

><http://article.gmane.org/gmane.ietf.usenet.format/27852> and
><http://article.gmane.org/gmane.ietf.usenet.format/28020> (6.)

>>> maybe also the token ?  I could then write
>>> Archive: creativecommons.org_licenses_by-nc-sa_2.0_de

>> Eh?
(Continue reading)

Permalink | Reply | 3 comments |
headers
Frank Ellermann | 4 Jan 2005 19:54
Picon
Picon

Re: msg-id


Charles Lindsey wrote:

> All the world and his dog are giving a conflicting syntax for
> <ipv6address>, and I do not think we want to get involved.

The quoted 2396bis text was about IPvFuture.  That's a superset
of IPv6 and IPv4 address literals.  2396bis also has the "real"
IPv6 address literals, it's the same as in 3513 and 2373.

Of course we don't want to get involved.  We only need the set
of legal characters between "<unique <at> [" and "]>".  And somebody
already solved this problem for us in 2396bis, the solution is
perfect for our purposes, no ambiguous quoted-pairs, no DQUOTE,
no ">", no "]", no "[".  It's much better than 2822, because we
can't use 2822.

> Just leave it as RFC 2822 has it, with only the essentual
> technical changes.

Your rules to get rid of ambiguous quoted-pairs are not simple
enough.  It starts with the wrong terms:  "id-right" is defined
in 2822, if we must have something else, then it should be as
in 1036 and its son a "domain".  But 2822 has its own "domain",
therefore let's take "mdomain".  Dito a 2822 "no-fold-literal"
is not good enough for us, let's use "address-literal", result:

| msg-id-core     =  "<" unique " <at> " mdomain ">"
| mdomain         = dot-atom-text / ("[" address-literal "]")
(Continue reading)

Permalink | Reply | 14 comments |
headers
Frank Ellermann | 4 Jan 2005 20:14
Picon
Picon

Re: Archive


Charles Lindsey wrote:

> Archive: yes; copyright-restriction="<http://creativecommons.org/licenses/by-nc-sa/2.0/de>"

Yes, that's better, or maybe Archive: no; permission=...

I used X-NoArchive: yes when deja.news was really new for some
time, but today I'm lost.  Generally I've no problem with news
archives, quite the contrary.  I hate it if commercial sites
(ab)use newsgroups as support forum.  Bye, Frank
Permalink | Reply | 0 comments |
headers
Charles Lindsey | 5 Jan 2005 16:04
Picon
Picon

Re: msg-id


In <41DAE669.21F3 <at> xyzzy.claranet.de> Frank Ellermann <nobody <at> xyzzy.claranet.de> writes:

>Charles Lindsey wrote:

>| msg-id-core     =  "<" unique " <at> " mdomain ">"
>| mdomain         = dot-atom-text / ("[" address-literal "]")

I am still waiting for a ruling from our Chair as to whether we can make
further changes to the RFC 2822 <msg-id> that are not required by some
absolute technical necessity.

And it would be nice to hear also from other WG members as to whether they
approve of these further changes that you are suggesting.

>If we're unable to agree on a concept for Message-IDs in news,
>then nobody else can do in a hypothetical 2822bis.  It's the
>one thing where net news is the final authority, not RfC 2822.

What you say may be highly desirable, but the practical politics just
does not work like that.

>| Since the msg-id has a similar syntax to angle-addr
>| (identical except that comments and folding white space are
>| not allowed), a good method is to put the  domain name (or a
>| domain literal IP address) of the host on which the message
>| identifier was created on the right hand side of the " <at> "
>[...]
>| Though other algorithms will work, it is RECOMMENDED that the
>| right hand side contain some domain identifier (either of the
(Continue reading)

Permalink | Reply | 13 comments |

Gmane