Harald Tveit Alvestrand | 1 Aug 17:48 2005
Picon

I'm back.... sorry about the absence


I was on another holiday trip last week, and returned home to find that my 
email server's OS disk had decided to call it a day.

Decent email service was only restored today (Monday) - and now I'm at the 
IETF meeting, which, despite my low level of formal responsibility, has the 
capacity for generating plenty of interrupts on my time.

I'll try to catch up and give reasonably coherent comments later - Alexey 
and I are meeting (physically) here in Paris on Wednesday.

                  Harald

Charles Lindsey | 1 Aug 15:37 2005
Picon
Picon

Re: #1080 - MIME parameters for Injection-Info and Archive header field need more text/updated syntax


In <42EA6A98.12FF <at> xyzzy.claranet.de> Frank Ellermann <nobody <at> xyzzy.claranet.de> writes:

>Okay.  Reason I stumbled over it:  It starts (optionally) with
><host> ":" followed by the IP.  Hard to read for an IPv6, e.g.
>need.more.cafe:cafe:cafe::cafe for a future gTLD cafe.  OTOH
>need.more.cafe:[cafe:cafe::cafe] could be clearer.

Ah! I see the problem. We have:

   host-value      =  dot-atom /
                      [ dot-atom ":" ] ( IPv4address / IPv6address )
                                       ;  see [RFC 3986]

and the ":" used as a separator can also appear in an IPv6address.

It is not actually ambiguous, but it is not tidy. We need a separator that
cannot occur in either a dot.atom (well, dot.atom.text maybe) or in an IP
address. That gives us:

    ( ) < > [ ] ;  <at>  \ ,

none of which is really suitable. So maybe square brackets as you
suggested:

    posting-host = example.com
    posting-host = example.com[123.123.123.123]
    posting-host = example.com[beef:beef:beef:beef:....]
    posting-host = 123.123.123.123
    posting-host = [123.123.123.123]
(Continue reading)

Charles Lindsey | 3 Aug 12:43 2005
Picon
Picon

Re: New USEPRO path-identity text (Hello, Chair?)


In <42EA99A0.72B6 <at> xyzzy.claranet.de> Frank Ellermann <nobody <at> xyzzy.claranet.de> writes:

>Charles Lindsey wrote:

>> What is you position on MUST vs SHOULD for providing at least
>> one? Richard seems to be preferring SHOULD, and we all know
>> that MUST sends John into apoplexy :-(

>We can justify a MUST about news <at>  / usenet <at>  because that's how
>it always was, and NetNews is one of these very old systems
>where "interoperability problems" (aka errors) have to be fixed
>manually and are reported by mail (or phone).

Though I am not sure I really want MUST for that case.

>For the mail-complaints-to better avoid 2119 keywords, and as
>long as Scott doesn't catch you there is still the lower case
>"must" or similar words.  Actually I think you can omit abuse <at> ,
>those who don't use mail-complaints-to (or its x-predecessor)
>will also ignore any "MUST abuse <at> ".

OK, I think I have now heard enough to propose new text. But note that
there are still some questions at the end which need to be decided.

2.3.  Identification of news-servers

[new version]

   In order to record the passage of articles through the network, and
(Continue reading)

Richard Clayton | 3 Aug 14:42 2005

Re: New USEPRO path-identity text (Hello, Chair?)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In message <IKn757.8qu <at> clerew.man.ac.uk>, Charles Lindsey
<chl <at> clerew.man.ac.uk> writes

>2.3.  Identification of news-servers
>
>[new version]
>
>   In order to record the passage of articles through the network, and
>   to enable their administrators to be contacted, news-servers need to
>   identify themselves by means of a <path-identity> (F-3.1.6), which
>   can appear in Path, Injection-Info and Xref header fields. Whatever
>   <path-identity> is used in the Path header field SHOULD be used also
>   in any Injection-Info header field (and it would be normal to use it
>   in any Xref header field also).

This still mixes two very different things and it would be better to
separate them far more clearly:

Make this intro just say:

    In order to record the passage of articles through the network,
    news-servers need to identify themselves by means of a <path-
    identity> (F-3.1.6), which appears in the Path header field.

and then the next bit is OK, by me....

(Continue reading)

Harald Tveit Alvestrand | 3 Aug 15:05 2005
Picon

#1093 Email addresses: Poll


I think the issue can be broken down into two different pieces:

1) news <at>  and usenet <at>  for all path-identities in the Path: or
  Injection-info: headers
  Alternatives, plese pick one:

  1A) All identities that look like domain-names MUST support
  1B) All identities that look like domain-names SHOULD support
  1C) Some identities MUST support
      ("at least one of the <path-identity>s inserted by
      themselves" is one example of "some")
  1D) Some identities SHOULD support
  1E) No requirement
  1F) None of the above

2) abuse <at>  for injecting agents as identified in Path:, for the
   case where Injection-info doesn't contain "mail-complaints-to"
   Alternatives, please pick one:

  2A) All identities MUST support abuse <at> identity
  2B) All identities SHOULD support
  2C) No requirement
  2D) Top level domain corresponding to identity MUST support
  2E) Top level domain corresponding to identity SHOULD support
  2F) None of the above

I read Charles' currently proposed text as 1D & 2B.
Please send a message to the list saying which alternatives you support; 
once we know if there is a consensus in the working group on one pair of 
(Continue reading)

Harald Tveit Alvestrand | 3 Aug 15:08 2005
Picon

#1093 USEPRO 2.3: Supported email addresses


I have created ticket #1093 to track this issue.
I'll send out one of my (in)famous polls in the next message.

Subject: USEPRO 2.3: Supported email addresses

Charles proposed the following new text:

There are two circumstances when news-server administrators may need
to be contacted by email:

1. (injecting agents only)
For sending complaints concerning the behavior of the poster of an
article, the correct address is
o If there is an Injection-Info header field with a "mail-
complaints-to" <parameter>, then the address in that
<parameter>; otherwise
o "abuse <at> " followed by the <path-identity> in that Injection-Info
field; or, in the absence of any Injection-Info field, the
<path-identity> inserted by that agent in the Path header field
(which, for an injecting agent, should be the one followed by
the keyword "POSTED"). Evidently, that <path-identity> needs to
be an FQDN for this to work.
Injecting agent administrators SHOULD[2,3] ensure that a working
email address is obtained by this process.

2. (all agents)
For reporting technical problems concerning the operation of a
news-server, the correct address is either "news <at> " or "usenet <at> "
followed by a <path-identity> obtained from an Injection-Info or
(Continue reading)

Richard Clayton | 3 Aug 15:58 2005

Re: #1093 Email addresses: Poll


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In message <5CDF309B260515727F61EBA3 <at> B50854F0A9192E8EC6CDA126>, Harald
Tveit Alvestrand <harald <at> alvestrand.no> writes

>I think the issue can be broken down into two different pieces:
>
>1) news <at>  and usenet <at>  for all path-identities in the Path: or
> Injection-info: headers
> Alternatives, plese pick one:
>
> 1A) All identities that look like domain-names MUST support
> 1B) All identities that look like domain-names SHOULD support
> 1C) Some identities MUST support
>     ("at least one of the <path-identity>s inserted by
>     themselves" is one example of "some")
> 1D) Some identities SHOULD support
> 1E) No requirement
> 1F) None of the above

1E  but if this is too extreme, then 1D

>2) abuse <at>  for injecting agents as identified in Path:, for the
>  case where Injection-info doesn't contain "mail-complaints-to"
>  Alternatives, please pick one:
>
> 2A) All identities MUST support abuse <at> identity
> 2B) All identities SHOULD support
(Continue reading)

Russ Allbery | 3 Aug 19:18 2005
Picon

Re: #1093 Email addresses: Poll


Harald Tveit Alvestrand <harald <at> alvestrand.no> writes:

> I think the issue can be broken down into two different pieces:

> 1) news <at>  and usenet <at>  for all path-identities in the Path: or
>  Injection-info: headers
>  Alternatives, plese pick one:

>  1A) All identities that look like domain-names MUST support
>  1B) All identities that look like domain-names SHOULD support
>  1C) Some identities MUST support
>      ("at least one of the <path-identity>s inserted by
>      themselves" is one example of "some")
>  1D) Some identities SHOULD support
>  1E) No requirement
>  1F) None of the above

1E.  People aren't going to support it anyway, and I don't see any reason
to raise hopes in the standard.

> 2) abuse <at>  for injecting agents as identified in Path:, for the
>   case where Injection-info doesn't contain "mail-complaints-to"
>   Alternatives, please pick one:

>  2A) All identities MUST support abuse <at> identity
>  2B) All identities SHOULD support
>  2C) No requirement
>  2D) Top level domain corresponding to identity MUST support
>  2E) Top level domain corresponding to identity SHOULD support
(Continue reading)

John Stanley | 3 Aug 19:31 2005

#1093 Email addresses: Poll


Harald Tveit Alvestrand <harald <at> xxxxxxxxxxxxx>:

>1) news <at>  and usenet <at>  for all path-identities in the Path: or
> Injection-info: headers
> Alternatives, plese pick one:

> 1A) All identities that look like domain-names MUST support

And just how do we define what "looks like" a domain name? And why should 
WE be defining what "looks like" a domain name, when our task is USENET?

 1F) None of the above

I guess I have to go with that, since none of the options is correct. 
We can justify a MUST for one (or both, by stretching history) for every 
site, but "looks like a domain name" is silly. 

>2) abuse <at>  for injecting agents as identified in Path:, for the
>  case where Injection-info doesn't contain "mail-complaints-to"
>  Alternatives, please pick one:

> 2A) All identities MUST support abuse <at> identity

Expressly contradicted by existing standard.

> 2C) No requirement

Since existing standards already put some requirement on this, how can we 
come along and say "no requirement"? 
(Continue reading)

John Stanley | 3 Aug 19:51 2005

Re: New USEPRO path-identity text (Hello, Chair?)


"Charles Lindsey" <chl <at> xxxxxxxxxxxxxxxx>:

>   In order to record the passage of articles through the network, and
>   to enable their administrators to be contacted, news-servers need to
>   identify themselves by means of a <path-identity> (F-3.1.6), which
>   can appear in Path, Injection-Info and Xref header fields.

Is it the function of Path to "enable administrators to be contacted", or 
is it to simply record the path the article has taken? 

>   <Path-identity>s can take the following forms (in decreasing order of
>   suitability):

Either suitable is or is not. Your preference is not a measure of 
suitability. Do you really mean "preference"?

>   3. Some other (arbitrary) name believed to be unique and registered
>      at least with all other news-servers sending articles directly to

Hyphen-ated news-servers why-is?

>      the given one. The news-server administrator is responsible for
>      choosing an appropriate name (and will bear the consequences of an
>      inappropriate choice). This option SHOULD NOT be used unless the

Here's that threat again. Tell the admin how to do it right and stop 
threatening him with unspecified "consequences" for listening to us.

>        NOTE: The syntax permits the colon character (which, prior to
(Continue reading)


Gmane