headers
Charles Lindsey | 1 Nov 1999 10:38
Picon
Picon

Re: Signatures (was: Issues remaining in Section 6)

In <199910302324.BAA20369 <at> vals.intramed.rito.no> Terje Bless <link <at> tss.no> writes:

>On 27.10.99 at 21:04, Jonathan Grobe <grobe <at> worf.netins.net> wrote:

>>On Wed, 27 Oct 1999, Charles Lindsey wrote:
>>
>>>Posting agents SHOULD discourage (at least with a warning) signatures of
>>>excessive length (4 lines is a commonly accepted limit).
>>> 
>>I don't think this should be in the draft. This is a netiquette issue.

>Well, if it's left in it should be expressed as a technical-ish limit along
>the lines of the 998 octet limit or the 21 Message-ID limit. Since I'm of
>the opinion that both those limits are artificial and counter-productive,
>I'd suggest leaving out any mention of a limit for signatures. While you
>could make the same kinds of arguments for that limit as the other two, I
>feel the intent would be much better served by requiring the use of the
>signature separator and enforcing stripping of signatures in replies.

Yes, but we already do the last two things. Not that we can "enforce"
either of these things, because the poster can always post any text he
wants. So what we do is to say that posting/followup agents SHOULD make
things easy for the guy who plays by the rules, and difficult for the guy
who wants to be awkward.

So we say that a signature MUST be preceded by "-- " (but that only means
that if the "-- " is missing, then it isn't a signature :-( ). And we say
followup agents SHOULD NOT include a quoted signature.

So if you accept both of those things, what is wrong with saying that
(Continue reading)

Permalink | Reply | 3 comments |
headers
Terje Bless | 1 Nov 1999 22:23
Picon

Re: Signatures (was: Issues remaining in Section 6)

On 01.11.99 at 09:38, Charles Lindsey <chl <at> clw.cs.man.ac.uk> wrote:

>Yes, but we already do the last two things.

And as I said, I find both to be "artificial and counter-productive". BTW,
I'm aware that this issue has been settled and I'm not trying to bring it
back to life!

>Not that we can "enforce" either of these things, because the poster can
>always post any text he wants.

Duh, ya think? :-)

>So what we do is to say that posting/followup agents SHOULD make things
>easy for the guy who plays by the rules, and difficult for the guy who
>wants to be awkward.

I disagree.

Those things belong in the GNKSA requirements. We're in the business of
defining a technical standard with a main focus on interoperability.
Stylistic issues are not relevant.

What we should say on the subject is that a signature is whatever follows
the last signature separator in the body of the message and nothing else.
We also say that a signature is not to be considered part of the body for
purposes of a followup or a reply and so should be stripped.

We don't talk about "valid" or "proper" signatures because there is no
other kind. If it's isn't delimited by the defined signature delimiter it
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matt Curtin | 2 Nov 1999 14:43
X-Face

Re: Signatures (was: Issues remaining in Section 6)

>>>>> On Mon, 1 Nov 1999 09:38:19 GMT,
    chl <at> clw.cs.man.ac.uk (Charles Lindsey) said:

Charles> So if you accept both of those things, what is wrong with
Charles> saying that posting agents SHOULD give a warning about
Charles> excessively long signatures? It seems just more of the same
Charles> sort of thing to me.

Though nice agents can do this sort of thing, part of it is out of our
control, since it has become quite the fashion for news services to
attach their ad to the bottom of the article (i.e., in the signature).
Sigh.

I say leave the draft as-is.  Should we reach a time when four lines
isn't any sort of reasonable signature limit, we can work on
great-grandson-of-1036. ;-)

--

-- 
Matt Curtin cmcurtin <at> interhack.net http://www.interhack.net/people/cmcurtin/
Permalink | Reply | 1 comment |
headers
Terje Bless | 2 Nov 1999 18:24
Picon

Re: Signatures (was: Issues remaining in Section 6)

On 02.11.99 at 08:43, Matt Curtin <cmcurtin <at> interhack.net> wrote:

>I say leave the draft as-is.  Should we reach a time when four lines isn't
>any sort of reasonable signature limit, we can work on
>great-grandson-of-1036. ;-)

Ah, but the numer 7 has so much improved carmic properties. And 3 is my
lucky number. And 14 is the size of a long on the Abacus. Not to mention
that my birthday is on the 19th. It's no fair that you get to choose 4 just
because that's the number of letters in your first name when mine has 5.
Permalink | Reply | 0 comments |
headers
Charles Lindsey | 3 Nov 1999 15:32
Picon
Picon

Section_7.02.02

Here it is (it will be on the website presently), followed by the diffs.



7.  Control Messages

   The following sections document the control messages.  "Message" is
   used herein as a synonym for "article" unless context indicates
   otherwise.  Group control messages are the sub-class of control
   messages that request some update to the configuration of the
   groups known to a serving agent, namely "newgroup".  "rmgroup",
   "mvgroup" and "checkgroups", plus any others created by extensions
   to this standard.

   All of the group control messages MUST have an Approved header
   (section 6.10). Moreover, in those hierarchies where appropriate
   administrative agencies exist (see 1.1), group control messages
   SHOULD NOT be issued except as authorized by those agencies.
[They SHOULD also use one of the authentication mechanisms which we
shall define when we get a Round Tuit.]

   The descriptions below are generally phrased in terms suggesting
   mandatory actions, but any or all of these MAY be subject to local
   administrative restrictions, and MAY be denied or referred to an
   administrator for approval (either as a class or on a case-by-case
   basis). Analogously, where the description below specifies that a
   message or portion thereof is to be ignored, this action MAY
   include reporting it to an administrator.

   Relaying Agents MUST propagate even control messages that they do
(Continue reading)

Permalink | Reply | 162 comments |
headers
G. James Berigan | 3 Nov 1999 18:54

Section 7.3: mvgroup (was: Section_7.02.02)

Charles Lindsey <chl <at> clw.cs.man.ac.uk> wrote:

>7.3.1.  Single group
:
>   Until most serving agents conform to this standard, whenever a
>   mvgroup control message for a single group is issued, a
>   corresponding pair of rmgroup and newgroup control messages SHOULD
>   be issued a few days later.
>[Should that be "a few hours"?]

No, days.  This gives the mvgroup sufficient time to propagate to all
servers (and to preserve the articles) before the less-conservational
rmgroup and newgroup messages are sent.  Two articles sent from the same
server a few hours apart can still arrive in reverse order on another
server, but this is far less likely if a delay of the order of days is used.

It also encourages adoption of mvgroup by serving agents to delay days
rather than hours.

On the omission making mvgroup synonymous with newgroup, would we want to
reject the incomplete mvgroup or instead say that in such cases newgroup
SHOULD be used  instead?

>7.3.2.  Multiple Groups

Same here for the other comment re hours vs. days.
Permalink | Reply | 1 comment |
headers
Brad Templeton | 3 Nov 1999 20:07
Picon

Re: Section_7.02.02

For the cancel message, isn't it the case that older systems might barf
on a cancel with multiple arguments?

What about my proposal that cancels can have a *body*, and that body is a
list of lines, which begin with a message-id, but may have optional
parameters, MIME style?

Or should that be a whole new message "control bulkcancel"?

That is really what spam cancellers want -- an efficient bulk cancel with
the targets in the body, and the ablity to put extra attributes on them
like scores, BIs or reasons fo the cancel.

Should not mvgroup, like all new features, be extensible in the
standard way?  There is no excuse for designing new features that are
not extensible, not in the 90s.

I object again to removing the mapping control messages.  Instead of
removing them, simply write.   "All such messages MUST be digitally
signed by a party authorized by the local site to perform the mapping
function and authorized to use the recipient email address."

We  haven't defined how to sign, so that in effect turns these things
off until we do, which should satisfy those who want them out of the
picture while they can do harm.
Permalink | Reply | 57 comments |
headers
G. James Berigan | 3 Nov 1999 21:40

Re: Section_7.02.02

Brad Templeton <brad <at> main.templetons.com> wrote:

> Should not mvgroup, like all new features, be extensible in the
> standard way?  There is no excuse for designing new features that are
> not extensible, not in the 90s.

What would need to be done to it?  I've been gone for too long I guess.
How are we making things extensible?
Permalink | Reply | 29 comments |
headers
Brad Templeton | 3 Nov 1999 22:07
Picon

Re: Section_7.02.02

On Wed, Nov 03, 1999 at 02:40:22PM -0600, G. James Berigan wrote:
> Brad Templeton <brad <at> main.templetons.com> wrote:
> 
> > Should not mvgroup, like all new features, be extensible in the
> > standard way?  There is no excuse for designing new features that are
> > not extensible, not in the 90s.
> 
> What would need to be done to it?  I've been gone for too long I guess.
> How are we making things extensible?

The whole point of making things extensible is you don't know at the time
what would need to be done to it!  A good fraction of all the upgrading
and interoperability problems in the world come because people didn't
think enough about extensibility when they designed formats and protocols.

It is my position that you need a tremendously good reason to design a
new format or protocol without making it easily extensible.   I hope most
agree with that.

I've gone further than some in a few ways.  I think we should define all
our headers that we can as extensible, in that all new software should
parse and discard any extensions, so that eventually all headers are
extensible in the same fashion.   However, I haven't sold that.

I also happen to think that a good extensible system provides some means
to make extending easier, including:
	a) Classes of extensions, as in:
		1) If you don't understand this, just ignore it
		2) If you don't understand this, give a warning
		3) If you don't understand this, abort
(Continue reading)

Permalink | Reply | 28 comments |
headers
Dirk Nimmich | 3 Nov 1999 22:54
Picon
Favicon

Re: Section_7.02.02

Charles Lindsey wrote:
> 7.1.2.  Application/news-groupinfo
> 
>    The "application/news-groupinfo" body part contains brief
>    information about a newsgroup, i.e. the group's name, it's
>    description and the moderation flag.
> 
>         NOTE: This part has a format that makes the whole newgroup
>         message compatible with [Son-of-1036].

Obviously, the content is text, not application data. So the MIME
type should be text with subtype news-groupinfo -- if at all
needed. text/plain can easily be used here.

> 7.1.4.  Example
[...]
>       --nxtlang
>       Content-Type: text/plain; charset=iso-8859-1
>       Content-Transfer-Encoding: 8bit
>       Content-Language: de
> 
>       Die Gruppe example.admin.info enthoelt regelmoeKig versandte
>       Informationen ber die example.*-Hierarchie.
>       --nxtlang--
>       --nxtprt--
> [Sorry! You can't use non-ascii characters in an RFC :-( .

Hah! How can one include examples in UTF-8, then? (Strange ... you
are enforced to include UTF-8 support in any specification that
handles text but you cannot use it in the RFCs itself?)
(Continue reading)

Permalink | Reply | 2 comments |

Gmane