headers
Charles Lindsey | 10 Nov 2005 21:05
Picon
Picon

#1047 - Path Syntax


Things have gone quiet. In an effort to get things moving, I have been
through the outstanding issues and extracted those which appear to be
holding us up. Here is where I think we are at with the Path Syntax:

There are two orthogonal choices for the WG to make in the following
proposal:

1. Syntactic style for the <source-keyword>s "MISMATCH" etc:

version 1:
   Path: downstream.example.com!123.123.123.123!MISMATCH
   !injector.example.com!POSTED!not-for-mail
version 2:
   Path: downstream.example.com!123.123.123.123..MISMATCH
   !injector.example.com!POSTED!not-for-mail

Observe that POSTED has '!'s on either side in both versions, because
peering sites still need to be able to recognize that articles should
not be sent back to injector.example.com.

2. The list of <source-keyword>s.

The proposed set is "SEEN", "MATCH", "MISMATCH". The WG may want to
reduce this (MATCH is redundant because of "!!") or extend it (Harald
even suggested letting sites invent additional ones).

I would suggest that we resolve these two main issues first, before
proceeding to any minor tuning.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Charles Lindsey | 10 Nov 2005 21:43
Picon
Picon

#1047 - Paths in USEPRO


Although not immediately relevant to USEFOR, Harald did ask us (on Sept
13th) to consider some related text in USEPRO, because it is closely
related to the syntax in USEFOR. Currently, my latest proposed text in
USEPRO contains 3 paragraphs telling you how to construct a
<path-identity> using
   1. an <fqdn>
   2. an IP address
   3. a <bareword>

Since we have decided to disallow IP addresses in <path-identity>s (they
are now only allowed in <souce-identity>s, aka diagnostics), that second
parapgraph has to come out.

Harald therefore proposed the following:

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

1. A fully qualified domain name (FQDN) that can be resolved to an email
server via an MX, A or AAAA record according to the procedures of
[RFC2821]; this guarantees that the name is unique, and makes it easy to
contact the administrators if needed.

2. A fully qualified domain name (FQDN) that is guaranteed to be
unique by the administrators of the domain; for instance, the
uniqueness of "server.example.org" could be guaranteed by the
administrator of "example.org" even if nothing is stored in the
DNS for that name.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Harald Tveit Alvestrand | 11 Nov 2005 02:14
Picon

Re: #1047 - Path Syntax

I'm at the IETF this week, and at IEEE next week. So I can't follow up much.

But consider this for a moment:

Given the total inability this group has had on getting consensus on even 
minor tightenings or changes to the current models - what's the *minimum* 
amount of specification that can get this piece finished?
Permalink | Reply | 3 comments |
headers
Frank Ellermann | 11 Nov 2005 06:10
Picon
Picon

OT: IMA (IEE BoF) jabber log


FYI, the IEE BoF jabber log is available at:
http://www.xmpp.org/ietf-logs/iee <at> ietf.xmpp.org/2005-11-10.html

Mailing list now also available at GMaNe (NNTP, RSS, search):
http://dir.gmane.org/gmane.ietf.ima

The project URL (until IEE is a WG) is apparently:
http://www.alvestrand.no/ietf/iee-bof/

Interesting snippets from the jabber log (thanks to Lisa):

[15:57:15] <lisa> Harald: There's a not-widely implemented
                          standard for tagging language of
                          email headers (RFC2231)

{16:04:42] <cyrus_daboo>  MUAs are important. There are still
                          many MUAs in use today that do not
                          support utf8 even in the message
                          body. So I agree with Chris.

[16:24:39] <cyrus_daboo>  PS If its not already on the list of
                          things to 'fix': the mailto URI
                          scheme will need some work too.

[16:29:36] <lisa> Keith:  There are multiple ways to fail, and
                          fragmenting the email system is one.
                          People to have to manually manage
                          their technology based on who they're
                          talking to is another. They're both
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charles Lindsey | 11 Nov 2005 21:34
Picon
Picon

#1080 - description of Injection-Info


AIUI, the present state of play is as follows:

1. Injection-Info currently makes use of MIME-style parameters.

2. It was always intended that these paramaters should accord in all
applicable respects with those defined in RFC 2045 plus RFC 2231.

3. It is not in dispute that the description in the current USEFOR does
not accord with RFC 2045, since it gives separate ABNF for each
<parameter>, which permits or does not permit CFWS in the proper places,
and which does not provide for encapsulation in <quoted-string>s in the
proper places. Also, it should be noted that RFC 2046 never gives ABNF for
specific <parameter>s, presumably for that same reason.

4. There is some disquiet about the unnecessary complications introduced
by the more gibbous features of RFC 2231. Nevertheless, everybody (except
possibly Bruce) has, at one time or another, expressed a willingness to
live with MIME-style parameters if nothing else is seen to be forthcoming.

5. The possibility of an entirely different syntax has been mooted from
time to time but, at the last poll that was conducted, there was clearly
no consensus to embark on such a step, and I doubt Harald would wish us to
embark on reinventing any such wheels at the present time.

6. Absent such a major change of direction, it only remains to fix the
problems mention in #3 above. I proposed a text some while back, but Russ
seemed to suggest there might be some other fix possible, though we have
seen no details of any other fix.
(Continue reading)

Permalink | Reply | 7 comments |
headers
Ralph Babel | 12 Nov 2005 10:17
Picon

Re: #1080 - description of Injection-Info


Charles Lindsey wrote:

> Nevertheless, everybody (except possibly Bruce) has,
> at one time or another, expressed a willingness to
> live with MIME-style parameters if nothing else is
> seen to be forthcoming.

No, Mr. "Editor".

http://imc.org/ietf-usefor/mail-archive/msg02554.html
Permalink | Reply | 0 comments |
headers
Frank Ellermann | 12 Nov 2005 21:08
Picon
Picon

Re: #1080 - description of Injection-Info


Charles Lindsey wrote:

> However, it is unlikely that the more gibbous mechanisms of
> Section 3 will be needed, given the possibility of folding
> within <quoted-string>s and the lack of any limit on the
> length of a header line short of the maximum 998 characters.

Get rid of that, it doesn't help.  The proposed "security
considerations" already take care of some gibbous 2822 / 2231
"features".

If implementors still don't get the message (= "PITA"), then
your "however...unlikely" note declaring that a problem is no
real problem makes it worse.
                               Bye, Frank
Permalink | Reply | 3 comments |
headers
Charles Lindsey | 14 Nov 2005 12:54
Picon
Picon

Re: #1080 - description of Injection-Info


In <43764BBD.704 <at> xyzzy.claranet.de> Frank Ellermann <nobody <at> xyzzy.claranet.de> writes:

>Charles Lindsey wrote:

>> However, it is unlikely that the more gibbous mechanisms of
>> Section 3 will be needed, given the possibility of folding
>> within <quoted-string>s and the lack of any limit on the
>> length of a header line short of the maximum 998 characters.

>Get rid of that, it doesn't help.  The proposed "security
>considerations" already take care of some gibbous 2822 / 2231
>"features".

Yes, I have no problem with getting rid of that if people do not want it.

Are you happy with the rest of it?

--

-- 
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 | 2 comments |
headers
Frank Ellermann | 14 Nov 2005 14:59
Picon
Picon

Re: #1080 - description of Injection-Info


Charles Lindsey wrote:

> Are you happy with the rest of it?

As long as Bruce proposes no better solution - in a form ready
for his own review (and relatively minor obstacles like Gen-Art
or the IESG) - it's the only Injection-Info game in town:

<http://mid.gmane.org/431BCC44.70D4 <at> xyzzy.claranet.de>

I haven't checked that all [CFWS] are where they should be,
and I'm lost with your revised revisions of something that
I've never seen, because it's not draft-ietf-usefor-usefor-05.

                         Bye, Frank
Permalink | Reply | 1 comment |
headers
Charles Lindsey | 15 Nov 2005 12:15
Picon
Picon

Re: #1080 - description of Injection-Info


In <43789842.6365 <at> xyzzy.claranet.de> Frank Ellermann <nobody <at> xyzzy.claranet.de> writes:

>Charles Lindsey wrote:

>> Are you happy with the rest of it?

>As long as Bruce proposes no better solution - in a form ready
>for his own review (and relatively minor obstacles like Gen-Art
>or the IESG) - it's the only Injection-Info game in town:

><http://mid.gmane.org/431BCC44.70D4 <at> xyzzy.claranet.de>

>I haven't checked that all [CFWS] are where they should be,
>and I'm lost with your revised revisions of something that
>I've never seen, because it's not draft-ietf-usefor-usefor-05.

I hope it is clear which paragraphs of USEFOR are to be replaced. For the
removal of doubt, the existing 1st para from USEFOR 3.2.14 remains, the
ABNF syntax is replace by my text (probably without the "gibbous" bit),
and all existing USEFOR paragraphs following the present ABNF remain.

--

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

Gmane