Frank Ellermann | 2 Feb 2005 09:40
Picon
Picon

Re: To do


Charles Lindsey wrote:

> should now be fixed

Thanks.

> http://www.imc.org/ietf-usefor/drafts/draft-ietf-usefor-msg-id-alt-00.txt

Another vote for <unique <at> mdomain> instead of <id-left <at> id-right>
if I got this right... ;->  It even says that using IPs is now
(= 1998) obsolete, and it mentions the problem with dynamic IPs.

                          Bye, Frank

Frank Ellermann | 2 Feb 2005 10:26
Picon
Picon

Re: To do


Charles Lindsey wrote:

> There are examples in RFC 1036 of two <path-delimiter>s
> adjacent, so presumably it was intended to be OK.

I haven't found it looking for "!" or "path:".  If that's
the case it should be good enough for your ...!!... idea.

You snipped my question about IPv6 path identities, how's
that supposed to work ?  RfC 1036 says:

| Letters, digits, periods and hyphens are considered part
| of host names; other punctuation, including blanks, are
| considered separators.

One of the RfC 3513 formats is x:x:x:x:x:x:d.d.d.d, and
that IPv6 is generally not the same as an IPv4 d.d.d.d

> It was all in the old draft-13

That explains why you added ":", but not that it may not work
with the RfC 1036 idea of "punctuation".  We really need that
"THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED" note in
STD 10.

> I am waiting for Ken to move them into USEFOR

Okay, let's wait for usefor-03 and an "official" usepro-02,
I'd like to see the new msg-id and *WSP syntax.  Bye, Frank
(Continue reading)

Charles Lindsey | 3 Feb 2005 13:05
Picon
Picon

Re: To do


In <42009CBD.130F <at> xyzzy.claranet.de> Frank Ellermann <nobody <at> xyzzy.claranet.de> writes:

>Charles Lindsey wrote:

>> There are examples in RFC 1036 of two <path-delimiter>s
>> adjacent, so presumably it was intended to be OK.

>I haven't found it looking for "!" or "path:".  If that's
>the case it should be good enough for your ...!!... idea.

The example in RFC 1036 is:

	cbosgd!mhuxj!mhuxt
	cbosgd, mhuxj, mhuxt
	 <at> cbosgd.ATT.COM, <at> mjuxj.ATT.COM, <at> mhuxt.ATT.COM
	teklabs, zehntel, sri-unix <at> cca!decvax

There are several examples of ', ' there (SP is a delimiter, and those
examples plus RFC 822, are sufficient to establish that long Path lines
can be folded).

The 3rd line contains two examples of ', <at> ' i.e. two delimiters immediately
together. There is also an example of ' <at> ' on its own to confirm that it is a
delimiter. There is also the interesting case of an ' <at> ' on its own at the
start of a line. By RFC 1036 standards, that is pretty convincing stuff.

>You snipped my question about IPv6 path identities, how's
>that supposed to work ?  RfC 1036 says:

(Continue reading)

Charles Lindsey | 3 Feb 2005 13:09
Picon
Picon

Re: To do


In <4200920B.624C <at> xyzzy.claranet.de> Frank Ellermann <nobody <at> xyzzy.claranet.de> writes:

>Charles Lindsey wrote:

>> should now be fixed

>Thanks.

>> http://www.imc.org/ietf-usefor/drafts/draft-ietf-usefor-msg-id-alt-00.txt

>Another vote for <unique <at> mdomain> instead of <id-left <at> id-right>

No, that draft was written over two years vefore RFC 2822 came out, and
before the id-left and id-right stuff had appeared in the DRUMS drafts.

>if I got this right... ;->  It even says that using IPs is now
>(= 1998) obsolete, and it mentions the problem with dynamic IPs.

That was its opinion. But there could exist some machine somewhere with an
IP address and no domain-name to go with it. Agreed, the practice should
be deprecated, and RFC 2822 does so (though USEFOR should probably apply a
little reinforcement).

--

-- 
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

(Continue reading)

Charles Lindsey | 4 Feb 2005 22:38
Picon
Picon

Issues outstanding


Some while back I posted a list of issues (and our Chair added some more).
We have now reached the point where we cannot continue working on our
drafts until these are resolved.

So here is the list again, with my comments on where we are at on each
one. SO PLEASE CAN WE HAVE INPUT ON THESE, especially on the ones which
still appear to be OPEN?

>We are coming to the point where there is little more that can be done on
>the documents we are supposed to be producing without deciding how various
>outstanding issues are to be resolved.

1. Complaints-To

>I published a list of 4 options (and invited other options) in
>http://www.imc.org/ietf-usefor/mail-archive/msg00151.html. Only three
>people have expressed any preference amongst them. I think #4 is dead, and
>#2 is the one most people could live with (but on such a small sample,
>that is hardly meaningful).

>#2 was to do it in Injection-Info rather than in a Complaints-To header,
>and to provide only a mail-complaints-to parameter (which would leave open
>the option to provide a separate url-complaints parameter as a future
>extension).

I think the conclusion we reached on this was to have a
'mail-complaints-to' parameter in the Injection-Info header with an
<address-list> for its parameter. And we decided not to have any provision
for URLs at this time, though a url-complaints-to parameter could be added
(Continue reading)

Charles Lindsey | 5 Feb 2005 21:44
Picon
Picon

draft-ietf-usefor-usepro-02.txt


I submitted draft-ietf-usefor-usepro-02.txt to the drafts editor last  
December (and we have been discussing it since then on the basis of the  
copy on our website).

Frank pointed out last week that it had still not appeared on the official  
drafts sites, so I sent it again.

I received the usual auto-acknowledgements both times, but nothing else.

So finally I escalated to the next stage up, and received the following  
response:

"We sent you twice messages saying that your draft did not have required
statements in it. PLease fix the problem with your draft and resubmit."

Well, they may have sent them, but I never received them (and I have  
carefully examined my trash file, which has not been pruned of late, and  
they are certainly not there). Moreover, they carefully did not explain  
which required statements they were concerned about, which was not overly  
helpful.

Anyway, I have now studied their website and RFCs 3667 and 3668 and fixed  
such problems as I could find and resubmitted. So we shall see. Draft-03  
is now almost ready, and will be submitted in about a week's time (I am  
away until then), assuming draft-02 finally makes it.

And, in spite of their protestations, I see that drafts with incorrect  
texts were still being accepted in January, including one by a certain Mr  
Lilly :-( .
(Continue reading)

Frank Ellermann | 6 Feb 2005 11:01
Picon
Picon

Re: To do


Charles Lindsey wrote:

>  <at> cbosgd.ATT.COM, <at> mjuxj.ATT.COM, <at> mhuxt.ATT.COM

Thanks, clearly two adjacent delimiters, your ...!!... syntax
should work with 1036-servers.  It's a good compromise between
options 2C and 2D in the "outstanding issues".

> Our draft makes it clear that ':' is henceforth to be part of
> the path-identity and not a delimiter. Hence ap IPv6 address
> would appear as ...!x:x:x:x:x:x:d.d.d.d!...

Okay, maybe add two IPv6 examples and a pointer to RfC 3513.

For BBBB:CCCC:DDDD:EEEE:FFFF:0000:1234:5678 the path identities
...!BBBB:CCCC:DDDD:EEEE:FFFF::1234:5678!... and
...!BBBB:CCCC:DDDD:EEEE:FFFF:0000:18.52.86.120!... are actually
the same, aren't they ?

For implementors these examples make it clear, that something
starting with a letter is not necessarily a FQDN, and that
(apparently) different path identities can be the same IP.

> If some ancient system misparses that

Modern systems also have an excellent chance to get this wrong.

> I doubt Ken will want to adopt the *WSP syntax.

(Continue reading)

Frank Ellermann | 6 Feb 2005 13:17
Picon
Picon

Re: Issues outstanding


Charles Lindsey wrote:

 [Posted-And-Mailed]
> I gather our Chair prefers #2 (a or b), but he has made no
> definitive pronouncement.

Add me and my ersatz-newsreader.  Obscure news-only headers to
"solve" netiquette-problems make no sense, they should at least
also work for mailing lists.

> It is still not clear (to me) what the objection to keeping
> them is

See above.  Some users want / send courtesy copies, other users
hate it.  A news-only "solution" doesn't help, it increases the
confusion (new vs. old UAs + news vs. mailing lists).

 [Followup]
> It has been established that there is no technical difference
> between these formulations. It is just a matter of wording

ACK.  Let's use your 1st definition and get rid of the "MUST":

| A followup is a response, and has a References header.

No details about the parts of a multi-part FAQs, they are only
confusing.  And IMHO no 2119 keywords for definitions, if A is
defined by B, then it's unnecessary to say that A MUST be B.

(Continue reading)

Gunnar Ritter | 6 Feb 2005 17:19
Picon

Re: User-Agent


Bruce Lilly <blilly <at> erols.com> wrote (on July 6, 2004):

> There are some issues with User-Agent: [...]
> 2. the syntax doesn't seem to be well-received by implementors:
>
> > Date: Sun, 02 May 2004 18:56:38 +0200
> > Sender: Gunnar.Ritter <at> pluto.uni-freiburg.de
> > From: Gunnar Ritter <Gunnar.Ritter <at> pluto.uni-freiburg.de>
> > Organization: Privat.
> > To: blilly <at> erols.com
> > Subject: Re: Nail and User-Agent
> > Message-ID: <40952846.nailWF11HPDB <at> pluto.uni-freiburg.de>
> > References: <409520F2.8030805 <at> erols.com>
> > In-Reply-To: <409520F2.8030805 <at> erols.com>
> > User-Agent: nail 10.8pre 4/14/04
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=us-ascii
> > Content-Transfer-Encoding: 7bit
> > X-Junkmail-Status: score=0/65, host=mr12.mrf.mail.rcn.net
> > 
> > Bruce Lilly <blilly <at> erols.com> wrote:
> > 
> >> Nail appears to insert header fields such as
> >>   User-Agent: nail 10.5 4/27/03
> >>
> >> The only specification for a User-Agent field that I am aware
> >> of is in draft-ietf-usefor-article-12.txt, section 6.18: [...]
> >>
> >> Note that the use of multiple '/' characters in the content
(Continue reading)

John Stanley | 7 Feb 2005 21:23

Issues outstanding


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

>It has been established that there is no technical difference between
>these formulations. 

Established by whom? Certainly not by anyone in this group. 

I keep pointing out the difference. If a non-followup MAY have a 
References header, you lose the ability to identify followups. Until
you can answer this question with the same certainty under both 
"formulations", you cannot say that there is no technical difference:

"Article A has a References header that points to article B. Is it a 
followup to B?"

It used to be considered important to be able to identify followups, to 
the point that RFC2119 language was used in a place where it would 
otherwise be impermissible, and prior to that, language equivalent to 
RFC2119 was used. I'll point out to the peanut gallery that this language 
predated my participation in this process by quite a bit of time.

If followups are no longer important, than lets get rid of the header
whose sole function is to identify what follows up to what. If they are
still important, then don't eviscerate the only header that can identify
them. 


Gmane