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

From: Eric Allman <[email-masked]>
Date: Fri, 24 Aug 2007 07:07:09 -0700

A couple of quick comments:

It isn't clear from the draft if this is intended to be Standards 
Track; I assume it is.

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

Given that the other official standards are named "XMPP" rather than 
"Jabber", why isn't the field name "XMPP-ID"?

The forgery discussion in section 5 might reference 4871 (DKIM-BASE).

eric

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 24 Aug 2007 11:05:31 -0600

Eric Allman wrote:
> It isn't clear from the draft if this is intended to be Standards Track;
> I assume it is.

My apologies. The intended state is Experimental. As I explained just
now on the APPS-REVIEW list:

***

I think this document should be Experimental. Implementation and
deployment experience will tell us whether this approach has value.
If it does, then we may want to abstract from that experience to
design a more general approach along the lines that Barry has
described [1].

I have received indications from several large entities providing
both email and XMPP-based IM services that they will likely deploy
this technology. The same may be true of one or more mail user agents.
If and when that happens, I will report back (or ask them to do so)
regarding their experience.

***

[1] http://www1.ietf.org/mail-archive/web/apps-review/current/msg00063.html

> 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

> "Jabber", why isn't the field name "XMPP-ID"?

Mindshare. Real people know what "Jabber" is. Only us geeks know what
"XMPP" is. Think "email" vs. "SMTP", "web" vs. "HTTP", etc.

> The forgery discussion in section 5 might reference 4871 (DKIM-BASE).

That too has been pointed out by another reviewer. In my working copy I
have the following text:

***

Including the Jabber-ID header among the signer header fields in
DomainKeys Identified Mail (DKIM) can help to mitigate against forging
of the header (see [DKIMSIG]).

***

(Where [DKIMSIG] is a reference to RFC 4871.)

Thanks for the review.

Peter

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

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 24 Aug 2007 10:38:54 -0700

I think a much better design would be one that supported many  
protocols and took advantage of the flexibility or URIs instead of  
just jabber - for example a header that looked like

IMPP: xmpp:[email-masked]

The way we did vcard might be a good thing to look at, or heck, just  
attach a vcard.

(sorry for few of you that got duplicate on this - sent to wrong list  
first time)

On Aug 24, 2007, at 6:51 AM, The IESG wrote:

> The IESG has received a request from an individual submitter to  
> consider
> the following document:
>
> - 'The Jabber-ID Header Field '
>    <draft-saintandre-jabberid-05.txt> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to  
> the
> [email-masked] mailing lists by 2007-09-21. Exceptionally,
> comments may be sent to [email-masked] instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-saintandre-jabberid-05.txt
>
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi? 
> command=view_id&dTag=14260&rfc_flag=0
>
>
> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 24 Aug 2007 10:41:56 -0700

Making this experimental not make much sense to me - there is no real  
experiment here other than "will anyone use it" and that could be  
said about a large percentage of PS documents. When I read 2026, this  
looks like PS.

On Aug 24, 2007, at 10:05 AM, Peter Saint-Andre wrote:

>> Track;
>> obsolete

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 24 Aug 2007 18:59:28 +0100

> said about a large percentage of PS documents. When I read 2026, this  

I agree. If the document is standardizing what is deployed and there is 
no desire to change it, then it should be Informational. Otherwise it 
looks like PS.

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 24 Aug 2007 12:16:18 -0600

> no desire to change it, then it should be Informational. Otherwise it

Well, folks are using it right now:

http://wiki.jabber.org/index.php/Jabber_Email_Header

I see it in the wild quite a bit, admittedly among people who may simply
be experimenting with it since they are heavy users of XMPP-based
instant messaging systems.

So perhaps Informational is appropriate.

Again, I'm not averse to designing something more general. And I think
that experience with this header field may provide useful input to that
process.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 24 Aug 2007 12:19:50 -0600

Cullen Jennings wrote:
> 
> I think a much better design would be one that supported many protocols
> and took advantage of the flexibility or URIs instead of just jabber -
> for example a header that looked like
> 

Another approach, naturally, would be to define a header field for
including an im: URI and/or one for including a pres: URI. That seems
fairly straightforward.

Peter

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

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 24 Aug 2007 19:23:46 +0100

>that experience with this header field may provide useful input to that
IMHO, if the header is deployed and you publish even an Informational 
RFC on it, there is very little chance that existing implementations 
would change when a new replacement header is standardized. And it might 
be too late already (even before the Informational RFC is published) to 
standardize a replacement.

All comments I've seen so far seem to imply that this is useful. There 
are existing implementations. So it doesn't seem like an Experimental 
RFC is needed, as the experiment is already successful.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 24 Aug 2007 14:44:41 -0700

On Aug 24, 2007, at 11:19 AM, Peter Saint-Andre wrote:

>> protocols

Sure - that works for me too.

BTW - I do like the basic idea of the draft - I just prefer the more  
general form of it.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 24 Aug 2007 21:13:10 -0700

On Aug 24, 2007, at 11:23 AM, Alexey Melnikov wrote:

> Peter Saint-Andre wrote:
>
>> Alexey Melnikov wrote:
>>
>>> Cullen Jennings wrote:
>>>
>>>> Making this experimental not make much sense to me - there is no  
>>>> real experiment here other than "will anyone use it" and that  
>>>> could be said about a large percentage of PS documents. When I  
>>>> read 2026, this looks like PS.
>>>>
> IMHO, if the header is deployed and you publish even an  
> Informational RFC on it, there is very little chance that existing  
> implementations would change when a new replacement header is  
> standardized. And it might be too late already (even before the  
> Informational RFC is published) to standardize a replacement.
>
> All comments I've seen so far seem to imply that this is useful.  
> There are existing implementations. So it doesn't seem like an  
> Experimental RFC is needed, as the experiment is already successful.

I agree it useful and I can't see any reason for it to be  
experimental - that's exactly the reason I think it is worth doing. I  
understand that when people bring something to a standards body they  
typically wish it would not change but often the change is for the  
better and allows the standard to have a wider scope and better  
longevity than the very initial idea. It's the nature of pre standard  
implementations.

Cullen

PS (as of this email being sent, if you check out the headers I think  
you will see there is an implementation of the header I proposed  
too :-) It's one of the good things IETF can do is help come to  
consensus between conflicting pre standard implementations.