Subject: Re: Last Call: draft-saintandre-jabberid (The Jabber-ID Header Field) to Proposed Standard

From: SM <[email-masked]>
Date: Wed, 05 Sep 2007 00:33:30 -0700

At 09:54 24-08-2007, Lisa Dusseault wrote:
>FYI on this last call document relating to email header 
>fields.  Please note that some review on the Apps-review team list 
>has already suggested this go to Experimental 
>instead 
>(<http://www1.ietf.org/mail-archive/web/apps-review/current/msg00062.html>http://www1.ietf.org/mail-archive/web/apps-review/current/msg00062.html 
>).

To avoid any ambiguity, between From and Sender, I suggest renaming 
the Examples section to Implementation and adding:

    The Jabber Identifier is associated with the author of the 
message; see [MESSAGE].
    If the "From:" header field contains more than one mailbox, the 
Jabber-ID header
    should not be added to the message.  There should be no more than 
one instance
    of the Jabber-ID header.

I preferred not to suggest associating the header with the Sender: 
header field as that field may be added at a later stage, for 
example, when the message is sent to a mailing list.  We could get 
around that by adding a Sender: field on transmission but then it 
would go against RFC 2822 Section 3.6.2.

Regards,
-sm

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 05 Sep 2007 16:11:52 -0600

SM wrote:
>> FYI on this last call document relating to email header fields. 
>> Please note that some review on the Apps-review team list has already
>> suggested this go to Experimental instead
> To avoid any ambiguity, between From and Sender, I suggest renaming the
> Examples section to Implementation and adding:
> 
>    The Jabber Identifier is associated with the author of the message;
> see [MESSAGE].
>    should not be added to the message.  There should be no more than one
> instance
>    of the Jabber-ID header.

That seems reasonable and I have incorporated it into my working
version. Thanks for the text.

> header field as that field may be added at a later stage, for example,
> when the message is sent to a mailing list.  We could get around that by
> adding a Sender: field on transmission but then it would go against RFC
> 2822 Section 3.6.2.

Hmm, yes, I think it would be best to avoid making that association.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Dave Crocker <[email-masked]>
Date: Wed, 05 Sep 2007 15:33:29 -0700

SM wrote:
> The Jabber Identifier is associated with the author of the message; see
> [MESSAGE]. If the "From:" header field contains more than one mailbox, the
>  Jabber-ID header should not be added to the message.  There should be no
> more than one instance of the Jabber-ID header.

Seems like good text to me, too.

The more general challenges to this specification really are classic and 
reasonable, but only if there is no real motivation for immediate use.  They 
call for a more general solution, which is always a desirable thing, but they 
do not seem to represent a real constituency for doing the work now or, more 
importantly, for using it.  (Or am I wrong?)

As I understand it, the current draft represents a motivated group that is 
trying to satisfy a specific requirement and already has some track record.

For me, that should partition comments between "it won't work" versus "it 
could be better".  The concern about ambiguity if there is more than one 
author (rfc2822.From) is an example of not working, absent clarifying text. 
The concern about a broader base of utility is in the latter camp of looking 
for enhancement.

> I preferred not to suggest associating the header with the Sender: header
> field as that field may be added at a later stage, 

Associating an XMPP address with the author makes sense to me.  Associating 
one with the rfc2822.Sender does not, since that address is supposed to relate 
to operations issues, not content-related exchanges.

Speaking of Jabber vs. XMPP, I do not understand characterizing this as 
XMPP-related work if the references and label are to Jabber.  If Jabber is the 
context, then this clearly is an Informational document, since it pertains to 
a base that is outside the IETF (or other?) formal standards work.  If it 
relates to XMPP, then shouldn't that be the reference and label?

(And, yes, I understand the cultural issue here, but alas, folks chose to name 
the IETF standard "XMPP" and I think we are stuck with that as the label, 
unless someone wants to try to alter the name of the base standard.)

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 06 Sep 2007 09:05:37 -0600

Dave Crocker wrote:
> reasonable, but only if there is no real motivation for immediate use. 
> They call for a more general solution, which is always a desirable
> thing, but they do not seem to represent a real constituency for doing
> the work now or, more importantly, for using it.  (Or am I wrong?)

I have no objections to working on a more general approach. Probably
that would mean two different header fields: one to encapsulate an "im:"
URI and the other to encapsulate a "pres:" URI. I'd be happy to work on
those specs with anyone who's interested. But as far as I can see there
is plenty of room in header-space, so publishing this as Informational
and adding the Jabber-ID header field to the provisional registry seems
appropriate to me.

<snip/>

> XMPP-related work if the references and label are to Jabber.  If Jabber
> is the context, then this clearly is an Informational document, since it
> pertains to a base that is outside the IETF (or other?) formal standards
> work.  If it relates to XMPP, then shouldn't that be the reference and
> label?
> 
> (And, yes, I understand the cultural issue here, but alas, folks chose
> to name the IETF standard "XMPP" and I think we are stuck with that as
> the label, unless someone wants to try to alter the name of the base
> standard.)

For historical reasons, even RFC 3920 and RFC 3921 use the term "JID",
the XML 'jid' attribute, etc., where "JID" stands for "Jabber ID" and
not (say) "Just an Identifier".

And yes there are long-standing cultural and political issues regarding
"Jabber" vs. "XMPP" among the hundreds of developers whom I don't even
try to herd. I tend to phrase it this way:

Jabber is to XMPP as email is to SMTP+POP+IMAP.

Or:

Jabber is to XMPP as the Web is to HTTP+HTML.

In the end it doesn't really matter what the name of the header field
is, does it? I mean we could call it the "Crocker" field if we really
wanted to, as long as the spec describing it clearly defined its
meaning. I happened to call it the "Jabber-ID" field because the term
"Jabber" has much greater mindshare than the term "XMPP" and eventually
one would hope that a header field of this kind will be used by real
people, not IETF protocol geeks or XMPP developers. This point about
mindshare is true even within the IETF: at WG meetings, you will hear
the chair ask for "a Jabber scribe" but I have never heard one ask for
"an XMPP scribe" (or to be even more precise -- since XMPP-based
groupchat is defined in a spec published by the XMPP Standards
Foundation -- "a scribe for the text chat room that uses XMPP and
XMPP-based extensions" or somesuch). I don't see a particularly good
reason to fight over labelling, especially if this specification is
Informational and the resulting header field is added to the provisional
registry (an intent that is not clear in this version of the spec, but
that will be clear in the next version).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Dave Crocker <[email-masked]>
Date: Thu, 06 Sep 2007 10:19:40 -0700

> I have no objections to working on a more general approach. Probably

Yup.  I wasn't criticizing the idea, either.  It's just a question of who is 
trying to satisfy an immediate requirement.

> URI and the other to encapsulate a "pres:" URI. I'd be happy to work on

My own guess is that as soon as any real generalization effort is pursued in 
this topic, we wind up affixing vcards.  And that's probably a good thing.

> Jabber is to XMPP as email is to SMTP+POP+IMAP.

Well, I appreciate the effort, but no.

IM is to XMPP as email is to SMTP et al.

> In the end it doesn't really matter what the name of the header field

Alas, yes.  Those fields are referenced by humans, which is after all why they 
tend to have human symbolic meaning.  Specs which create confusing 
nomenclature and labels are harder to debug and deploy.

> is, does it? I mean we could call it the "Crocker" field if we really

Or you could call it Lemonade.

Oh.  Right.  That's been taken.

> "Jabber" has much greater mindshare than the term "XMPP" and eventually

That's why I would have preferred calling the IETF spec Jabber or a 
derivative.  But I'm not trying to revisit the decision, merely suggest that 
it be handled consistently.

> "an XMPP scribe" (or to be even more precise -- since XMPP-based

Then let's in fact rename the protocol.

d/
-- 

   Dave Crocker

---

From: Tony Finch <[email-masked]>
Date: Thu, 6 Sep 2007 19:37:16 +0100

> IM is to XMPP as email is to SMTP et al.

That would be premature, since Jabber has not yet taken over the IM world
in the way that the Internet standards have done for email.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR
MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 06 Sep 2007 13:12:16 -0600

> in the way that the Internet standards have done for email.

Right. "Jabber is to XMPP as email is to SMTP as the web is to HTTP"
doesn't imply that all IM systems are based on XMPP.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Tony Finch <[email-masked]>
Date: Thu, 6 Sep 2007 20:21:05 +0100

> doesn't imply that all IM systems are based on XMPP.

Regarding your second comparison, it occurs to me that we still call it
the (world-wide) web, not distributed multimedia hypertext, even though
practically all distributed multimedia hypertext uses HTTP and HTML.
[But then even WWW has less than twelve syllables.]

Tony.

---

From: "Frank Ellermann" <[email-masked]>
Date: Sun, 16 Sep 2007 20:05:04 +0200

Peter Saint-Andre wrote:

> Eric Allman wrote:

>> I don't see any reason why a new proposed standard should allow
>> obsolete syntax (specifically, obs-FWS in section 2).

> Another reviewer pointed that out as well. As a result, in my 
> working copy I have changed that to:

> "Jabber-ID:" [FWS] pathxmpp [FWS] CRLF

We discussed this elsewhere a year ago:
http://permalink.gmane.org/gmane.ietf.message-headers/8

You can't have any ... [FWS] CRLF in a header field, what you
really want is ... *WSP CRLF.  That 2822 issue is already fixed in
http://tools.ietf.org/html/draft-resnick-2822upd-02#section-3.2.6

[new]
| unstructured    =       (*([FWS] utext) *WSP) / obs-unstruct
[old]
| unstructured    =       *([FWS] utext) [FWS]

If you intend to rule out the obsolete syntax you don't need the
obs-FWS case covering what 2822upd-02 has as obs-unstruct.

While you're at it it could make sense to define the Jabber-ID in
a way also working for Netnews.  If you do that you'd arrive at...

| "Jabber-ID:" SP *WSP pathxmpp *WSP CRLF

...with the "magic SP" for Netnews (see a recent thread ont the
822 list about this oddity).  If you don't care about Netnews for
the moment you get:

| "Jabber-ID:" [FWS] pathxmpp *WSP CRLF

The reasoning behind this is that mail doesn't allow "apparently
empty lines" ... CRLF 1*WSP CRLF within the header.  And Netnews
is even stricter and doesn't allow an "apparently empty" header
field body line.

Or in other words the RFC 2822 message syntax is designed so that
losing trailing white space can't cause havoc (in the form of a
premature end-of header CRLF CRLF condition).  

The obsolete RFC 822 syntax like the RFC 4234 LWSP construct still
demand that CRLF 1*WSP CRLF is very different from CRLF CRLF, and
won't survive conditions where significant trailing white space is
lost or ignored.

Frank

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 18 Sep 2007 11:46:56 -0600

> obs-FWS case covering what 2822upd-02 has as obs-unstruct.

Thanks for the clarification.

> | "Jabber-ID:" SP *WSP pathxmpp *WSP CRLF

I see no particular reason to define the header field so that it cannot
be used on Netnews...

> won't survive conditions where significant trailing white space is

Thanks again. I'll clean up the ABNF accordingly (i.e., I think it
should be the Netnews-friendly format you describe above).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/