Subject: [Ietf-message-headers] Jabber-ID header field

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 12 Sep 2006 14:22:28 -0600

The following Internet-Draft defines a header field for encapsulating a
Jabber Identifier:

http://www.ietf.org/internet-drafts/draft-saintandre-jabberid-03.txt

In accordance with RFC 3864, feedback from this list is requested.

Thanks!

Peter

--
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

_______________________________________________
Ietf-message-headers mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-message-headers

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 13 Sep 2006 00:21:53 +0200

Peter Saint-Andre wrote:

> feedback from this list is requested.

It's ready (I think).  Don't forget to update the status if
it's changed, that part was interesting with Received-SPF :-)

---

From: Graham Klyne <[email-masked]>
Date: Thu, 14 Sep 2006 09:22:45 +0100

> In accordance with RFC 3864, feedback from this list is requested.

Two small comments, neither critical I think:

(1) since this is a new email header field, why allow the obsolete
folding-whitespace (obs-FWS)?

(2) under security considerations, you usefully raise the problem of id
harvesting by spammers (or would that be "jammers"? ;).  It occurs to me that
email clients might be encouraged (required?) to NOT disclose jabber-id headers
to any particular recipient without first obtaining the sender's permission (a
bit like the MDN response requirements).

#g

-- 
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 14 Sep 2006 19:19:40 +0200

Graham Klyne wrote:
 
> why allow the obsolete folding-whitespace (obs-FWS)?

It's more like "inherited" than "allow", it's what you
get if you remove the "F" from ... [FWS] CRLF

Clearly nobody should fold trailing white-space before
the CRLF, that's a MUST NOT in 2822.  The FWS-syntax is:

| FWS =  ([*WSP CRLF] 1*WSP) /   ; Folding white space
|        obs-FWS

With that you inherit obs-FWS (MUST NOT generate etc.)
as soon as you say FWS.  If you then remove the bogus 
folding from ... [FWS] CRLF the rest is the same as
... [ 1*WSP / obs-FWS ] CRLF   

Where "obs" stands for MUST accept + MUST NOT generate.

Getting rid of it would work best in a future 2822bis,
until then obsolete gateways could try strange foldings.

For another attempt to nail this oddity see
<http://permalink.gmane.org/gmane.ietf.rfc.interest/110>
 
Frank

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 14 Sep 2006 16:28:19 -0600

Graham Klyne wrote:

> (2) under security considerations, you usefully raise the problem
> of id harvesting by spammers (or would that be "jammers"? ;).

Heh, I like that. Usually people use the term "SPIM" (IM spam).

> It
> occurs to me that email clients might be encouraged (required?) to
> NOT disclose jabber-id headers to any particular recipient without
> first obtaining the sender's permission (a bit like the MDN response
> requirements).

So something like the following?

   An email user agent that is capable of including the
   Jabber-ID header field in outgoing email messages MUST
   provide an option for its user to disable inclusion of
   the Jabber-ID header field generally, on a per-message
   basis, or on a per-recipient basis.

Peter

---

From: Graham Klyne <[email-masked]>
Date: Wed, 20 Sep 2006 11:03:01 +0100

>    basis, or on a per-recipient basis.

That certainly addresses the point I raised, and it usefully draws attention to
a possible remedy for the issue raised.  One might debate MUST/SHOULD
distinctions here -- I lack a clear opinion on this.

#g

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 20 Sep 2006 05:51:18 -0500

> distinctions here -- I lack a clear opinion on this.

I think should is enough. The text I have in my working copy reads as
follows:

***

Advertising XMPP addresses in email headers may make it easier for
malicious users to harvest XMPP addresses and therefore to send
unsolicited bulk communications to the users or applications represented
by those addresses.  Care should be taken in balancing the benefits of
open information exchange against the potential costs of unwanted
communications.  An email user agent that is capable of including the
Jabber-ID header field in outgoing email messages should provide an
option for its user to disable inclusion of the Jabber-ID header field
generally, on a per-message basis, or on a per-recipient basis.

***

Peter

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 28 Sep 2006 03:21:16 -0400

> In accordance with RFC 3864, feedback from this list is requested.

There are several issues with the proposal and with the draft, and I
can suggest a method to avoid the issues.  First, issues with the
draft:

[N.B. I recommend reading to the end of this message before reading
referenced RFCs, as many points may be moot if a different approach,
such as the one suggested near the end of this message, is taken]

1. the draft has apparently been replaced [the URI above results in a 402
   error], so I'll comment on -04
2. See RFC 4249 and its references, paying particular attention to sections
   3.1.1, 3.2.1, 3.2.2, 3.3.1, 3.3.2, 3.3.3, and 3.4.1.  Section 3.4.4 might
   or might not be applicable (it is unclear from the draft).  Some
   specifics:
   a) note that some proposed syntax conflicts with RFC 2822 (e.g. ';' is
      an RFC 2822 "special").
   b) I believe that the peculiarity of use of an obs- construct in a
      proposed new field has already been noted.
   c) the security considerations section seems rather light.
   d) the draft wording could use improvement for clarity and to remove
      ambiguities (e.g. "Message headers are an existing standard"; is that
      supposed to be plural or singular?)

Issues with the proposal per se:

A. [Abstract] "associating the email message or sender with a particular
   Extensible Messaging and Presence Protocol (XMPP) address".  Curiously,
   this is not discussed in the body of the draft per se.  Several
   questions:
   a) what exactly does it mean to associate an ID of this type with a
      message?
   b) how does a recipient determine whether an ID is supposed to be
      associated with a message or with "sender"?
   c) given the following snippet of fields from a message, and assuming
      that the ID is supposed to be associated with "sender" rather than
      with the message per se, exactly which mailbox or set of mailboxes
      corresponds to the draft use of the word "sender"?
        Resent-Sender: [email-masked]
        Resent-From: [email-masked], [email-masked]
        From: [email-masked], [email-masked]
        Sender: (see RFC 3192) "FAX=+33-1-88335215"@l.com
        Reply-To: foo list: [email-masked], [email-masked];
B. There appears to be no provision for line folding within an ID (RFC
   4622 "pathxmpp" production).
C. There appears to be no upper bound on the length of an ID, either in
   raw form or when "converted".
D. What happens when an ID exceeds 998 octets in length (N.B. maximum
   header field line length in RFC 2822 is 998 octets; also note the
   recommended maximum of 78 octets)?
E. Why not start with registration in the provisional registry rather than
   the permanent registry (see BCP 90 (a.k.a. RFC 3864) section 2.1)?  Is
   it the author's assertion that this field is now in widespread use?

A possible solution to the issues noted above: instead of a message header
field, specify a media type (presumably under the "application" IETF tree;
see BCP 13 ,a.k.a. RFC 4288).  Advantages:

i.   no content restriction if binary transfer is used or if a transfer
     encoding is applied
ii.  no need to "convert" ID under the above conditions
iii. no conflicts with RFC 2822 syntax (RFC 2822 "specials", line length
     limits, parentheses vs. comments, etc.)
iv.  a media type (applicable parameters or content) can be defined to
     specify whether an ID is to be associated with a message, with some
     mailbox, or with some other object.
v.   transfer is possible via any mechanism which uses MIME (e.g. HTTP)
     and perhaps via some mechanisms which use MIME media types but not
     MIME per se (RTP), not limited to email.
vi.  in MIME contexts, additional MIME fields can be used to affect
     presentation and/or to provide auxiliary information (e.g.
     Content-Disposition, Content-Description fields)

security issues would still need to be more fully fleshed out (see RFC
3552).

---

From: "Peter Saint-Andre" <[email-masked]>
Date: Thu, 28 Sep 2006 02:21:49 CDT

<< IMPORTANT INFORMATION! >>

This is an automated message. 

The message you sent (attached below) requires confirmation
before it can be delivered. To confirm that you sent the
message below, just hit the "R"eply button and send this
message back (you don't need to edit anything). Once this is
done, no more confirmations will be necessary.

This email account is protected by:
Active Spam Killer (ASK) V2.5.2 - (C) 2001-2004 by Marco Paganini
For more information visit http://www.paganini.net/ask

--- Original Message Follows ---

From: Bruce Lilly <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-message-headers] Jabber-ID header field

(Original message truncated)

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 28 Sep 2006 03:38:11 -0400

On Thu September 28 2006 03:21, Bruce Lilly wrote:
[...]
>  Advantages:
[...]
>      Content-Disposition, Content-Description fields)

P.S.

vii.  using S/MIME or PGP/MIME, media content can be digitally signed to
      provide authentication.
viii. using S/MIME or PGP/MIME, media content can be encrypted to preclude
      ID harvesting

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 28 Sep 2006 09:35:15 -0600

<snip/>

Er, sorry, didn't tweak my whitelists correctly.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 28 Sep 2006 14:06:17 -0600

Thanks for the feedback. I probably won't have time to reply for about a
week or two, but will do so then.

Peter

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 29 Sep 2006 00:54:04 +0200

Bruce Lilly wrote:

  [Peter wrote]
>> In accordance with RFC 3864, feedback from this list is

BTW, that's not required for header fields with a proper RFC,
but obviously a good idea.

> some proposed syntax conflicts with RFC 2822 (e.g. ';' is
> an RFC 2822 "special").

Grmbl, yes.  Do you have a tool for this ?  My experiments
in this direction are not in a state where I could simply
put ABNF in and get conflicts out.

All of <unreserved> and <pct-encoded> is <atext>, so far no
problem.  But <node-allow> and <res-allow> run into troubles.

> I believe that the peculiarity of use of an obs- construct
> in a proposed new field has already been noted.

That's just the known issue of "no folding in a FWS directly
before a CRLF" combined with the 2822 accept obs-FWS MUSTard
in a pending erratum.

> exactly which mailbox or set of mailboxes corresponds to the
> draft use of the word "sender"?
>         Resent-Sender: [email-masked]

It's no Resent-Jabber-ID, the Resent-* are out.  The Reply-To
is for mail replies, the Jabber-ID for jabber replies.  The
I-D says that the Sender sets the Jabber-ID.  Like it sets
the Reply-To.  Per message.  From that I'd expect that I can
discuss the given message per mail on foo list, with m@n org,
or with o@p edu.  Or I can discuss it via jabber with JID.

Testing that theory with JID stpeter@ it worked as expected.

> There appears to be no provision for line folding within an
> ID (RFC 4622 "pathxmpp" production).

Yes, same issue as for <msg-id> and <addr-spec> in RFC 2822.
What do you propose, a statement "make sure that a Jabber-ID
isn't longer than 997 octets" ?

> What happens when an ID exceeds 998 octets in length

The nice MSA will reject the message as specified in RFC 4409.

> Why not start with registration in the provisional registry

Permanent and RFC is better for MUA implementors.

Your media type proposal strikes me as odd, the JID could then
be also added to some existing vcard or similar "attachment"...

Nobody would use it, and we're back at square one.  With the
JID as header field you implicitly have the vcard, if you have
an UA suppporting to retrieve the user info of the given JID.

Some hen and egg issue here, the JID is an egg.

Frank

---

From: Graham Klyne <[email-masked]>
Date: Fri, 29 Sep 2006 10:16:36 +0100

[This message is more about reviewing RFC3864 than the specific Jabber-id header]

> Permanent and RFC is better for MUA implementors.

Sure, ...

But, in general, I note that requesting a provisional registration in no way
precludes moving later to a permanent registration.

And the barrier for provisional registration being so much lower (this the
Jabber-ID draft would be sufficient), it's easy to get a record of its intended
purpose published where developers can find it.  I would expect that a header
destined for the standards track would be provisionally registered pretty much
as soon as it is first published.

In this case, it looks as things might move quite quickly, so going straight for
the permanent registry saves some administration.  I'd like to think it can be
done as soon as IESG approves the draft for standards-track publication.  Hmmm,
checking [http://www.rfc-editor.org/rfc/rfc3864.txt]:

[[
      The assignment policy for
      such registration is "Specification Required", as defined by RFC
      2434 [3], where the specification must be published in an RFC
      (standards-track, experimental, informational or historic), or as
      an "Open Standard" in the sense of RFC 2026, section 7 [1].
]]

That text is a bit limiting... maybe also add ", or has been approved for such
publication".

Looking over the text I'd also be inclined to indicate more explicitly that the
IESG also has discretion to approve registration of any entry in the permanent
registry, to avoid potential wrangling over such small points.

#g

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 30 Sep 2006 15:46:59 +0200

Graham Klyne wrote:

> in general, I note that requesting a provisional registration
> in no way precludes moving later to a permanent registration.

Yes, Martin's Archived-At could have been an example for this
procedure (if "could have been" is English, I hope it's clear).

Compare <http://article.gmane.org/gmane.ietf.rfc822/10973>, the
first of 20 articles here on this list from my POV.  At this
time GMaNe did not yet support Archived-At.

That didn't make it into the provisional registry.  Maybe IANA
didn't get the mail, or Martin forgot to send it after the two
weeks.

The "designated expert" part of RFC 3864 apparently also didn't
make it to IANA so far, their "assignments" page says "(need to
fill in)" in <http://www.iana.org/numbers.html#M> for RFC 3864.

Possibly the IESG simply forgot to appoint an expert.  Without
that IANA is lost.  For the http header fields they now have
both provisional _and_ permanent registrations.  IMHO that makes
no sense for _identical_ specifications (in this case RFC 4229):

<http://www.iana.org/assignments/message-headers/prov-headers.html>

To see what happens I've now submitted Archive-At for netnews
claiming that it already exists for mail (CC to Martin because
he's the change controller of his I-D).

> I would expect that a header destined for the standards track
> would be provisionally registered pretty much as soon as it is
> first published.

Yes, obviously it's a good idea to get feedback about issues like
the RFC 2822 <specials> - certainly more relevant than the rather
esoteric pending "[FWS] CRLF" erratum.

> That text is a bit limiting... maybe also add ", or has been
> approved for such publication".

Jabber could be special, they are their own SDO. but apparently
the header field draft is no JEP <http://www.jabber.org/protocol/>

Maybe limit the "approved for such publication" to the case of
RFCs.  For other document series like JEP or this obscure PICS
header field nobody knows or cares how their "approval" works.

> Looking over the text I'd also be inclined to indicate more
> explicitly that the IESG also has discretion to approve
> registration of any entry in the permanent registry, to avoid
> potential wrangling over such small points.

For permanent entries specified in IETF RFCs that's no issue,
if they don't like it why would they approve the RFC ?  For
independent RFCs or other standards it's an idea.  Maybe the
designated expert could handle this.  The IESG shouldn't be
forced to offer their speculations about the merits of header
fields defined by other SDOs, that could be a conflict of
interests.

Frank