headers
Frank Ellermann | 3 Jun 2002 05:32
Picon
Favicon

Re: USEFOR draft 7 last call: typos

Charles Lindsey wrote:

  [5.4.1 Re: new subject (was: old subject)] 
> It is not usual for followup agents to strip (was: ...) from
> the Subject line AFAIAA, though I have no objection if some
> agent chooses to do it.

You could simply add another example line to document this...

      Subject: Re: Godwin's law

...then it's obvious for anybody, that stripping (was: ...) is
at least not incorrect.  Even minor details in RfC 1036 and
1036bis caused endless threads in some newsgroups, it's better
to avoid any ambiguity now.  (Of course it's not "ambiguous"
and only an example, but these endless debates ignore simple
facts whenever possible. ;-)

   [5.6.2 #3 "downstream"]
>| An arbitrary name believed to be unique and registered at 
>| least with all sites immediately downstream from the given
>| site. 

> No, "peering with" implies a symetrical relationship. It is 
> definitely the downstream and not the upstream that is meant
> here. But I think the term "downstream" is sufficiently well
> understood to stand on its own.

Topologies can be very strange (that's the point of "above all,
prevent loops" in 8.8).  Apparently nobody here has problems
(Continue reading)

Permalink | Reply | 501 comments |
headers
Frank Ellermann | 3 Jun 2002 06:03
Picon
Favicon

Re: UseFor draft 7

Charles Lindsey wrote:

> Not having seen the discussion in de.admin.net-abuse.mail,
> perhaps you could summarize it for us.

Most participants don't like invalid addresses, but accept the
idea of (ab)using TLD .invalid as smallest damage in comparison
with me <at> privacy.net, "modified" addresses, or other constructs
to avoid spam.

> It may well be the case that a person who uses the TLD 
> .invalid may find his own cancels of his own articles not 
> honoured at many sites, but that is his problem.

Indeed.  And for the same reasons he might be unable to cancel
faked articles with "his" invalid From: address.  Or more
precisely, there's no obvious technical definition of a "fake"
in conjunction with invalid addresses.  Maybe you could add a
warning to 7.3 or better 5.2 about these side-effects.

                         Bye, Frank
Permalink | Reply | 668 comments |
headers
Unknown | 20 Jun 2002 19:12

Re: Encapsulation Experiment - please Approve and Post

# In <ylofe7t21s.fsf <at> windlord.stanford.edu> Russ Allbery <rra <at> stanford.edu> writes:
# 
# >> -- Binary/unsupported file stripped by Ecartis --
# >> -- Type: application/news-transmission
# >> -- Desc: encapsulated
# 
# >*ROTF,L*
# 
# >I rest my case.
# 
# Yes, it seems to have caused a certain amount of mirth.
# 
# More worrying is the fact that the copy sent to this list seems to have
# disappeared without trace. Would Kent care to comment?

What copy disappeared ?  The test message you posted ?

It is in the archives. http://www.landfield.com/usefor/2002/Jun/0325.html 
is what you posted. The hypermail software used for archiving stored 
the attachment separately. It is linked into the page listed above as

  * application/news-transmission attachment: encapsulated 

Click on 'encapsulated' to get the attachment.  It is also in its 
original mailbox format as you posted it. It is available in the 
mailbox at

 http://www.landfield.com/usefor/mailbox/usenet-format.200206

I must be misunderstanding your question...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Henry Spencer | 3 Jun 2002 16:17

Re: UseFor draft 7

On Mon, 3 Jun 2002, Frank Ellermann wrote:
> Most participants don't like invalid addresses, but accept the
> idea of (ab)using TLD .invalid as smallest damage in comparison
> with me <at> privacy.net, "modified" addresses, or other constructs
> to avoid spam.

Then they've completely misunderstood the issue.

Nobody is proposing that spam avoidance be done by simply appending
".invalid" to a valid domain name.  That would fool the spammers for
about five minutes.  (Okay, maybe ten -- they're not very bright.)

The notion is that ".invalid" is used to *mark* mangled addresses as
such, so that people and software will know they are unusable for replies. 
Instead of me <at> nospam.please, you'd write me <at> nospam.please.invalid -- just
as mangled, but clearly labeled as such (and guaranteed not to conflict
with a possible future ".please" TLD).

This fully conforms to RFC 2606's definition of ".invalid":  "for use in
online construction of domain names that are sure to be invalid and which
it is obvious at a glance are invalid". 

                                                          Henry Spencer
                                                       henry <at> spsystems.net
Permalink | Reply | 0 comments |
headers
Charles Lindsey | 3 Jun 2002 18:30
Picon
Picon

Re: Unicode and draft 07

In <20020531104641.GB16354 <at> finch-staff-1.demon.net> "Clive D.W. Feather" <clive <at> demon.net> writes:

>Charles Lindsey said:
>>>>     NOTE: UTF-8 is an encoding of the 16bit UCS-2 (and even the 32bit
>>>>     UCS-4) character sets ...
>>> I really think that's too much detail for our document. We don't care about
>>> UCS-2 or UCS-4 (which aren't Unicode terms anyway).

>> According to RFC2279bis, the terms UCS-2 and UCS-4 are certainly defined
>> in ISO 10646, if not in Unicode.

>Yes, but we don't really talk about Unicode v ISO (and nor should we).

>> Anyway, I now have:
>> 
>>         NOTE: UTF-8 is an encoding for the [ISO/IEC 10646] character set
>>         (in both its 16 and 32 bit forms) with the property that any
>>         octet less than 128 immediately represents the corresponding
>>         US-ASCII character, thus ensuring upwards compatibility with
>>         previous practice.  ...

>I can live with that, I suppose.

>Um, ISO or Unicode in the brackets ?

If you read the paragraph immediately preceding the one quoted, you will
see that it sets out the relationship between ISO 10646 and Unicode, so it
does not really matter which one is mentioned here. I chose to mention ISO
10646 because AIUI that still pays lip service to the possibility of 32
bit codes, whereas the Unicode people seem to have gone quite away from them.
(Continue reading)

Permalink | Reply | 9 comments |
headers
Charles Lindsey | 3 Jun 2002 18:25
Picon
Picon

Re: Another draft draft-ietf-usefor-article-07.01.unpaged

In <87adqg2o4c.fsf <at> erlenstar.demon.co.uk> Andrew Gierth <andrew <at> erlenstar.demon.co.uk> writes:

>>>>>> "Charles" == Charles Lindsey <chl <at> clw.cs.man.ac.uk> writes:

> Charles> The intention is that this is to be the final draft. So if I
> Charles> hear no objections by the next Friday, I shall put it up as
> Charles> an Internet Draft and ask the IESG to put it to Last
> Charles> Call. Then it will be up to the IESG.

>Only the working group Chair can make such a request (see section 7.5
>of RFC 2418).

Our chairman seems to have been silent for several months. Please could he
speak up?

--

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: chl <at> clw.cs.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
Permalink | Reply | 1 comment |
headers
David Barr | 3 Jun 2002 20:53
Favicon

RE: Another draft draft-ietf-usefor-article-07.01.unpaged

> 
> > Charles> The intention is that this is to be the final 
> draft. So if I 
> > Charles> hear no objections by the next Friday, I shall put 
> it up as 
> > Charles> an Internet Draft and ask the IESG to put it to Last Call. 
> > Charles> Then it will be up to the IESG.
> 
> >Only the working group Chair can make such a request (see 
> section 7.5 
> >of RFC 2418).
> 
> Our chairman seems to have been silent for several months. 
> Please could he speak up?

I've been lurking  :)

Feel free to make the request - you have my approval.

It is my hope that those people that have expressed objections about
some or all of the draft come up with alternate replacements.  There
have been a few somewhat vocal (yet still minority) opponents to various
issues, and I'd like (1) for their voice to be heard clearly and (2)
should the IESG have objections to the same sections of the draft, we
would have an immediate supply of alternate language to draw from.

On a personal note, I have been quiet here in large part because my
employer (Digital Island, who was purchased by Cable and Wireless, who
also purchased most of the US assets of Exodus) has been undergoing a
series of massive changes and in general going down the tubes.  I was
(Continue reading)

Permalink | Reply | 0 comments |
headers
Clive D.W. Feather | 3 Jun 2002 22:17

Re: Unicode and draft 07

Charles Lindsey said:
> If you read the paragraph immediately preceding the one quoted, you will
> see that it sets out the relationship between ISO 10646 and Unicode, so it
> does not really matter which one is mentioned here. I chose to mention ISO
> 10646 because AIUI that still pays lip service to the possibility of 32
> bit codes, whereas the Unicode people seem to have gone quite away from them.
> 
> Practically speaking, of course, they are dead. But UTF-8 still nominally
> covers them (and that includes the latest UTF-8 draft).

Okay.

--

-- 
Clive D.W. Feather  | Work:  <clive <at> demon.net>   | Tel:  +44 20 8371 1138
Internet Expert     | Home:  <clive <at> davros.org>  | Fax:  +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            | NOTE: fax number change
Permalink | Reply | 3 comments |
headers
Marc Mutz | 4 Jun 2002 01:47
Picon
Favicon

Re: Unicode and draft 07


On Monday 03 June 2002 18:30, Charles Lindsey wrote:
<snip>
> >Um, ISO or Unicode in the brackets ?
<snip>
> I chose to mention ISO 10646 because AIUI that still pays lip service
> to the possibility of 32 bit codes, whereas the Unicode people seem
> to have gone quite away from them.
>
> Practically speaking, of course, they are dead. But UTF-8 still
> nominally covers them (and that includes the latest UTF-8 draft).

Umm? I don't think that surrogates were invented without reason for 
UTF-16 and the BMP is becoming full already...

AFAIK, UTF-8 will not encode the surrogate pairs as two 16bit 
characters, but the _value_ of the surrogates, thus already leaving the 
16bit target space.

Correct me if I'm wrong, though.

Marc

--

-- 
Marc Mutz <mutz <at> kde.org>
Permalink | Reply | 4 comments |
headers
Henry Spencer | 4 Jun 2002 02:52

Re: Unicode and draft 07

On Tue, 4 Jun 2002, Marc Mutz wrote:
> > I chose to mention ISO 10646 because AIUI that still pays lip service
> > to the possibility of 32 bit codes, whereas the Unicode people seem
> > to have gone quite away from them.
> > Practically speaking, of course, they are dead...
> 
> Umm? I don't think that surrogates were invented without reason for 
> UTF-16 and the BMP is becoming full already...

I believe the distinction being referred to is not 16 vs 32, but 20 vs 32.
The (insert sound of retching here) surrogates stretch the Unicode code
space to (roughly speaking) 20 bits, not 32.

My understanding is that even the ISO side of the house has now come down
quite firmly against ever populating any of the 10646 code space beyond
there, but 10646 does not actually say that out loud. 

                                                          Henry Spencer
                                                       henry <at> spsystems.net
Permalink | Reply | 2 comments |

Gmane