Subject: [APPS-REVIEW] Review request: draft-saintandre-jabberid-05.txt

From: Lisa Dusseault <[email-masked]>
Date: Thu, 23 Aug 2007 16:00:49 -0700

I've agreed to sponsor this, tentatively as as Proposed Standard:

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

I'd particularly like feedback from the team reviewer on the  
appropriateness of Proposed Standard.  There's a tie-in to email and  
i18n so I'll be sending the IETF Last Call announcement to IMAPEXT,  
LEMONADE and EAI as well.

Thanks,
Lisa

_______________________________________________
APPS-REVIEW mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/apps-review

---

From: Dave Cridland <[email-masked]>
Date: Fri, 24 Aug 2007 00:25:22 +0100

On Fri Aug 24 00:00:49 2007, Lisa Dusseault wrote:
> appropriateness of Proposed Standard.  There's a tie-in to email 
> and  i18n so I'll be sending the IETF Last Call announcement to 
> IMAPEXT,  LEMONADE and EAI as well.

For the record, I've looked at this before, and implemented it. I'm 
aware there are multiple implementations, so I'm quite happy with 
this in the context of an informational document, and believe this to 
be useful to publish.

I don't know if the SIP folk would be interested in a single header 
providing both an XMPP and SIP address. Without knowing whether the 
SIP folk consider this to be worth persuing, I don't know if this 
should be PS. I feel uncomfortable with the notion of there being one 
header for XMPP, and another for SIP.

I've not done a detailed review of the document, though I do note 
that the XMPP-IRI reference is outdated.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Scott Lawrence <[email-masked]>
Date: Thu, 23 Aug 2007 20:52:46 -0400

> header for XMPP, and another for SIP.

There are any number of possible 'other identifiers' that might be
included in email (or HTTP or SIP) headers to identify the sender.  I
suspect that identifiers for use in different protocols will all be
URIs, which implies that they contain a scheme that identifies the
protocol.  If there is a need for an email header that identifies an
'other identifier', then it seems to me that it would be better to make
it just that and let the scheme define the protocol.  Specify it such
that it can have multiple values:

 From-Alt-Uri: sip:[email-masked], xmpp:[email-masked]

This seems more flexible and cleaner than defining a new header for each
possible identifier type just so that the scheme can be implied for the
type.

---

From: Dave Cridland <[email-masked]>
Date: Fri, 24 Aug 2007 09:20:24 +0100

> possible identifier type just so that the scheme can be implied for 

Absolutely - without this discussion, I can't really back Proposed 
Standard. However, Jabber-Id is a deployed mechanism, so it needs 
publication as-is. Therefore I'd say Informational.

FWIW, another point occured to me - which From address does this 
information pertain to? (Technically, a message may have multiple 
 From addresses. Perhaps this specification, and any From-Alt-Uri 
specification, should stipulate it's the Sender, not the From.)

Dave.

---

From: Barry Leiba <[email-masked]>
Date: Fri, 24 Aug 2007 09:00:02 -0400

I've reviewed the spec, and I've a few comments:

1. I don't think it should be PS, not even Info, as it is.

2. I agree with Scott's comments that if we do this, we should instead have a 
field that specifies a list of alternative addresses or identifiers.  One might 
even want them to be email addresses, in fact, listing other email addresses for 
the sender, as well as IM names or other things... so a list of URIs works well.

3. It might be problematic to associate this specifically with the "From" 
address.  I'm thinking on the fly here, but I worry about things that futz with 
the message but that don't understand the new field.  They might morph the "from" 
(or the "sender", or whatever), and not know about this "alt-id" field, and we 
could end up with a mismatch somewhere.

4. Why not use an attached VCard to convey all this information.  If all one 
wants is to add a Jabber ID, that's a little heavy, but it's not terribly bad (an 
abbreviated VCard could be used, with just the desired information).  But in the 
general case, it allows the inclusion of various alternative addresses, as well 
as postal contact info, telephone numbers, and so on.  And it eliminates the 
problem of association with the "from" field, since the VCard is completely 
self-contained.  And and, lots of programs already know what to do with VCards. 
And and and, we're starting up a VCardDav working group, n'est-ce pas?

5. If this IS to be on standards track, I'd like to see some of the language look 
more normative.  In particular, I'd like to see more explanation of 
how/where/when it would be used, and what the association is between the 
Jabber-ID field and any other identifiers in the header (is it associated with 
From, or Sender, or Resent-From, or Reply-To, or what?), and I think the "should 
not" and "should" in the Security Considerations section should (uh, SHOULD) 
reference RFC 2119.

Barry

--
Barry Leiba, STSM, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 24 Aug 2007 10:12:53 -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 draft should also address when / how this should be used instead  
of just attaching a vcard.

---

From: John C Klensin <[email-masked]>
Date: Sun, 26 Aug 2007 12:30:58 -0400

Hi.

I want to address the experimental vs proposed std vs something
else discussion, independent of the specifics of this proposal.

We decided during the DRUMS effort to essentially remove the 822
treatment of private use (X-...) headers, permitting anyone to
invent any header they might like and put it to use.  We
encourage registration of such things, but the registration
process is fairly uncritical and there is no effective way to
require people to register.  The bottom line is that some new
headers ("new" as in "not specified in 822 or maybe 2822") will
be dropped or ignored by some gateways and MUAs and some won't.
There is no way to predict which ones will or will not be usable
in practice.  In practice, standardization has little effect on
that question since legacy systems won't know about newer
standards.

Dropping special treatment for X- headers may or may not have
been a good idea, but that is a discussion for 2822bis, not this
header.

Whether or not this particular header is standardized seems to
me to be a separate question.  Personally, I like some of the
other proposals better.  However, I see no value at all in
Experimental treatment for the proposal.   If the header is in
use, as it appear to be, there is no experiment to be performed:
2822 authorizes introduction of non-standard headers.  We know
that, unless they disclose information that should be secured,
they aren't harmful to any system unless it depends on the
header arriving and doesn't see it.  If we don't think it
sensible to standardize the thing, we should, IMO, publish a
description of it as Informational, giving the community
information about what is being done already, and then move on.

    john

---

From: Thomas Roessler <[email-masked]>
Date: Sun, 26 Aug 2007 16:59:27 +0200

On 2007-08-24 10:12:53 -0700, Cullen Jennings wrote:

> protocols and took advantage of the flexibility or URIs instead
> of just jabber - for example a header that looked like

> IMPP: xmpp:[email-masked]

I agree that it appears strange to specify a header that *almost*
includes a URI -- effectively, it just turns the scheme into an RFC
2822 header tag, and renames it on the way.

Putting a full URI (including the scheme) into that header appears
much cleaner.

-- 
Thomas Roessler, W3C  <[email-masked]>

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 27 Aug 2007 19:37:32 -0600

>> IMPP: xmpp:[email-masked]

The more I think about it, the more I realize that "IMPP" is odd. What
does that mean? Is it a technology for which there is both an Instant
Messaging SRV Protocol Label Registration and a Presence SRV Protocol
Label Registration in accordance with RFC 3861? That would include only
XMPP and the SIMPLE extensions to SIP, and exclude all of the silo'd IM
and presence services like AIM, ICQ, MSN (now Windows Live Messenger),
Skype, and Yahoo. At which point someone is going to come up with header
fields like the following:

AOL-Screen-Name: MyScreenName
ICQ-NUM: 123456789
WLM-Id: MyMSNAddress
Skype-Handle: MySkypeHandle
YIM-ID: MyYahooID

So you're going to have proliferation anyway.

> Putting a full URI (including the scheme) into that header appears

In fact I think it is cleaner to not include a full URI. The reason is
that both SIP URIs and XMPP URIs can include a great deal of very
interesting aspects (query identifiers, fragment identifiers, authority
components, and the like) that are ultimately extraneous for the purpose
of telling people what your bare identifier is on an IM and presence
system (which, I submit, is the use case that will be of interest 99% of
the time).

However, I suppose it would be possible to restrict the aspects of a URI
that are included in this identifier during generation, thus simplifying
the task of processing such a URI.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 27 Aug 2007 19:39:41 -0600

> information about what is being done already, and then move on.

That seems reasonable in this case.

Peter

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

---

From: Joe Hildebrand <[email-masked]>
Date: Tue, 28 Aug 2007 09:08:19 -0600

On Aug 27, 2007, at 7:37 PM, Peter Saint-Andre wrote:
> In fact I think it is cleaner to not include a full URI. (...)
>
IIRC, the other reason we used a URI was so that we didn't have to  
specify escaping rules to get down to ASCII-7.

-- 
Joe Hildebrand