headers
Tony Hansen | 26 Jul 06:22
Picon
Favicon

Mailing List Last Call for 2822 update internet-draft

There have been some comments on draft-resnick-2822upd-* but they have
dwindled down to none.

This is a "formal" Mailing List Last Call on
draft-resnick-2822upd-02.txt. The last call will last for two weeks
time, ending on August 10, 2007.

The document will be discussed on the 822 mailing list,
<ietf-822 <at> imc.org>. Please send your comments there.

For a copy of the current draft, you can find it at

	http://www.ietf.org/internet-drafts/draft-resnick-2822upd-02.txt
or
	http://tools.ietf.org/html/draft-resnick-2822upd

Depending on the outcome of the Mailing List Last Call, the next step
will be to submit the document (or its revision) to the IESG for
IETF-wide Last Call.

Thanks!

	Tony Hansen
	tony <at> att.com
Permalink | Reply | 1 comment |
headers
Alan Barrett | 26 Jul 11:01

Re: Mailing List Last Call for 2822 update internet-draft


On Thu, 26 Jul 2007, Tony Hansen wrote:
> This is a "formal" Mailing List Last Call on
> draft-resnick-2822upd-02.txt. The last call will last for two weeks
> time, ending on August 10, 2007.

In section 3.6.4, I suggest that we mention the idea that a software vendor
can use their domain name when generating message IDs.  For example, change
this:

"  Though other algorithms will work, it is RECOMMENDED that the right
"  hand side contain some domain identifier (either of the host itself
"  or otherwise) such that the generator of the message identifier can
"  guarantee the uniqueness of the left hand side within the scope of
"  that domain.

to this:

   It is RECOMMENDED that the right hand side contain a domain
   identifier of an entity that guarantees the uniqueness of the left
   hand side within the scope of that domain (for example, the domain
   name of the host itself, or a domain name controlled by the vendor of
   the software that generates the left hand side).

In section 4.3, why does obs-zone have [CFWS] between the sign and the
digits of the timezone offset?  Such space was not permitted by earlier
specifications.

--apb (Alan Barrett)
(Continue reading)

Permalink | Reply | 11 comments |
headers
SM | 26 Jul 19:14

Re: Mailing List Last Call for 2822 update internet-draft


Hi Alan,
At 02:01 26-07-2007, Alan Barrett wrote:
>In section 3.6.4, I suggest that we mention the idea that a software vendor
>can use their domain name when generating message IDs.  For example, change
>this:

I don't see a reason for this change.  Could you please elaborate on 
why you are recommending this?

Regards,
-sm
Permalink | Reply | 4 comments |
headers
Alan Barrett | 26 Jul 22:48

Re: Mailing List Last Call for 2822 update internet-draft


On Thu, 26 Jul 2007, SM wrote:
> >In section 3.6.4, I suggest that we mention the idea that a software vendor
> >can use their domain name when generating message IDs.  For example, change
> >this:
> 
> I don't see a reason for this change.  Could you please elaborate on 
> why you are recommending this?

It has happened in the past that software vendors have created
message-id algorithms that did not guarantee unique message-ids in the
face of non-unique host names.  The common wisdom has been that it's
better to generate message-id's of the form <${something derived from
a random number, a timestamp, and the non-unique hostname}@${something
that encodes the software version}.${vendor's domain name}> than to
generate message-id's of the form <${anyhing}@${non-unique hostname}>.

The intent behind my suggested wording is to make it more clear to
software vendors that the domain name on the right hand side of the
message-id is allowed to be the vendor's domain name; that it doesn't
have to be the domain name of the host that's running the software, and
that inability to know the domain name of the host is not necessarily a
problem.

--apb (Alan Barrett)
Permalink | Reply | 3 comments |
headers
Charles Lindsey | 26 Jul 23:44
Picon
Picon

draft-resnick-2822upd-02 and Netnews


Sorry, I should have made these comments before, but recent threats of
Last Calls have brought it rapidly to the top of my 'todo' list :-( .

The principlal change in this latest draft is the removal of
<quoted-string> from the <id-left>. This is much to be welcomed, but it
still does not address several other Netnews incompatibility problems that
I raised in my original message entitled "Compatibility with Netnews"
which I posted on April 27th.

I also have some niggles with the latest draft not related to Netnews, but
I shall save those for a separate thread. So here are the issues that
remain vis a vis Netnews.

1. Message-ID
-------------

The latest change is a huge improvement, but some niggles still remain.

Netnews has a requirement to be able to compare two msg-ids by a simple
octer-by-octet comparison (which also implies case sensitivity). That
surely is a desirable aim for Email also, and indeed it would be useful to
mention that property in the paragraph of section 3.6.4 that starts with
"The message identifier (msg-id) MUST ...".  But we are not quite there
yet, because a <quoted-pair> is still allowed within a <no-fold-literal>.
True, there is a mention that "other specifications" will limit it, but no
such specifications are mentioned.  Pointers to
draft-ietf-usefor-usefor-12 and to RFC2821-bis would be in order here (cf
such a mention in 3.4.1).
(Continue reading)

Permalink | Reply | 16 comments |
headers
SM | 27 Jul 07:03

Re: Mailing List Last Call for 2822 update internet-draft


Hi Alan,
At 13:48 26-07-2007, Alan Barrett wrote:
>It has happened in the past that software vendors have created
>message-id algorithms that did not guarantee unique message-ids in the
>face of non-unique host names.  The common wisdom has been that it's
>better to generate message-id's of the form <${something derived from
>a random number, a timestamp, and the non-unique hostname}@${something
>that encodes the software version}.${vendor's domain name}> than to
>generate message-id's of the form <${anyhing}@${non-unique hostname}>.

Having the hostname on the left or on the right in terms of 
uniqueness would not be much of a difference as you face the same 
situation when doing a binary comparison of two message-ids.  The use 
of the domain name/IP address on the right is based on the assumption 
that it guarantees that the message-id is globally unique.  That 
doesn't always hold nowadays with NAT.

>The intent behind my suggested wording is to make it more clear to
>software vendors that the domain name on the right hand side of the
>message-id is allowed to be the vendor's domain name; that it doesn't
>have to be the domain name of the host that's running the software, and
>that inability to know the domain name of the host is not necessarily a
>problem.

The rationale of having the domain name on the right is that it 
guarantees uniqueness of the left-hand side within the scope of that 
domain.  If there is a recommendation to use the vendor's domain on 
the right-hand side, it lessens the scope for uniqueness within that 
domain.  If the domain name of the host cannot be determine, an IP
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charles Lindsey | 27 Jul 15:20
Picon
Picon

Re: Mailing List Last Call for 2822 update internet-draft


In <20070726204813.GL4619 <at> apb-laptoy.apb.alt.za> Alan Barrett <apb <at> cequrux.com> writes:

>The intent behind my suggested wording is to make it more clear to
>software vendors that the domain name on the right hand side of the
>message-id is allowed to be the vendor's domain name; that it doesn't
>have to be the domain name of the host that's running the software, and
>that inability to know the domain name of the host is not necessarily a
>problem.

There is indeed one well known vendor which does what you say, but I am not
sure whether it is a practice we want to encourage (that is not to say
that vendor is likely to be swayed by such non-encouragement).

Essentially, such vendors have to rely on generating a sufficiently long
random number for the id-left to make it astronomically improbable that a
clash will occur. We mght have some discussion as to whether we regard
that as a good method worthy of our blessing.

--

-- 
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> clerew.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
Alan Barrett | 28 Jul 15:43

Re: Mailing List Last Call for 2822 update internet-draft


On Fri, 27 Jul 2007, Charles Lindsey wrote:
> Essentially, such vendors have to rely on generating a sufficiently
> long random number for the id-left to make it astronomically
> improbable that a clash will occur.

Right.  And, if a clash does occur, it's under a domain controlled by
the vendor, so we know who to blame, unlike <${random}@localhost> or
<${random}@${one_word_host_name}>.  The point is that the owner of the
id-right domain takes responsibility for ensuring uniqueness of the
id-left within the scope of that domain.

> We mght have some discussion as to whether we regard
> that as a good method worthy of our blessing.

I am not proposing to change the requirements, only to add an example
and change the wording.  The existing text already says that the
generator must guarantee uniqueness of the left hand side within the
scope of the right hand side domain, and already says that the right
hand side domain does not have to belong to the host itself.  Using
a vendor's domain would fit all these requirements, but I have seen
discussions in various places over the years that suggests that vendors
are not aware that they are allowed to do this.

--apb (Alan Barrett)
Permalink | Reply | 0 comments |
headers
Pete Resnick | 30 Jul 05:25
Favicon

Re: Mailing List Last Call for 2822 update internet-draft


On 7/26/07 at 11:01 AM +0200, Alan Barrett wrote:

>    It is RECOMMENDED that the right hand side contain a domain
>    identifier of an entity that guarantees the uniqueness of the left
>    hand side within the scope of that domain (for example, the domain
>    name of the host itself, or a domain name controlled by the vendor of
>    the software that generates the left hand side).

How about this instead (which is a little closer to the text 
throughout the rest of the document)?:

                         ...it is RECOMMENDED that the right hand side 
contain some domain
                         identifier (either of the host itself, of the 
implementer, or otherwise)
                         such that the generator of the message 
identifier can guarantee the
                         uniqueness of the left hand side within the 
scope of that domain.

We don't talk of "software" or "vendors" in this document. 
"Implementations" and "implementers" are about it.

>In section 4.3, why does obs-zone have [CFWS] between the sign and 
>the digits of the timezone offset?  Such space was not permitted by 
>earlier specifications.

It sure was. Comments and folding white space were allowed between 
any two tokens in RFC 822. And since the syntax for zone was:
(Continue reading)

Permalink | Reply | 5 comments |
headers
Pete Resnick | 30 Jul 05:56
Favicon

Re: draft-resnick-2822upd-02 and Netnews


I want to start out by saying that in answering this, I'm trying to 
take RFC 2119, section 6 *very* seriously:

6. Guidance in the use of these Imperatives

    Imperatives of the type defined in this memo must be used with care
    and sparingly.  In particular, they MUST only be used where it is
    actually required for interoperation or to limit behavior which has
    potential for causing harm (e.g., limiting retransmisssions)  For
    example, they must not be used to try to impose a particular method
    on implementors where the method is not required for
    interoperability.

Insofar as I interpret this:

MUST means, "You must do this or seriously bad things will happen, 
either with regard to interoperation with other implementers of this 
specification or known harm will come to this or other parts of the 
Internet." SHOULD means, "You probably want to do this, and not doing 
so may cause some interoperability problems, but you can do this if 
you fully understand the ramifications and you have a good reason to 
do so."

If below I ask why something should be a MUST or a SHOULD, I'm 
looking for an answer in light of the above.

Also, Charles alone does not rough consensus make. If there are 
others who strongly feel that these changes should be made (and 
strongly would be good; we're trying to push this along through the
(Continue reading)

Permalink | Reply | 15 comments |

Gmane