Subject: [xmpp] Draft XMPP Agenda for IETF83

From: Ben Campbell <[email-masked]>
Date: Wed, 14 Mar 2012 09:18:46 -0500

Hi,

Here's the draft XMPP meeting agenda for IETF83. We're currently scheduled for Wednesday afternoon at 1510. Please send any suggested changes to the XMPP list as soon as possible.

Thanks!

Ben.

-----------------------------------

XMPP (IETF 83 - Paris, France) - Wednesday 28 March 2012 1510-1610

-- Status and Agenda Bashing -- 5 min (Chairs)

-- End to End Encryption (Matt Miller) -- 20 min
	
	htttp://tools.ietf.org/html/draft-miller-xmpp-e2e-00

-- Domain Name Assertions (Matt MIller) -- 15 min
	
	List Discussion, 
	http://tools.ietf.org/html/draft-ietf-xmpp-dna-01

-- Internationalization Issues (Peter St. Andre) --  15 min

	http://tools.ietf.org/html/draft-saintandre-xmpp-6122bis-01
	http://tools.ietf.org/html/draft-saintandre-precis-nickname-00

If time permits:

-- Combining XMPP and SIP ( Emil Ivov ) - 5 min
	
	http://tools.ietf.org/html/draft-ivov-xmpp-cusax-00

-- Open Discussion -- Any remaining time and energy

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 14 Mar 2012 09:15:18 -0600

> 	http://tools.ietf.org/html/draft-saintandre-precis-nickname-00

The main topic I'd like to discuss in person is this: do we really need
a PRECIS profile for resourceparts, or can we just do byte-for-byte
comparison in general and then define PRECIS profiles for specific
applications that use resourceparts (such as the nickname profile for
chatroom nicks)?

Peter

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

---

From: Nobuo Ogashiwa <[email-masked]>
Date: Thu, 15 Mar 2012 01:12:07 +0900

Dear Ben,

We have submitted an internet-draft:
http://tools.ietf.org/html/draft-harada-xmpp-srv-record-query-00
Can we have a 5-10 minute slot to discuss this draft?

If we have a presentation slot, Akari Harada will take care of a presentation.

Regards,
Nobuo Ogashiwa

2012/3/14 Ben Campbell <[email-masked]>:
> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp

---

From: Ralph Meijer <[email-masked]>
Date: Wed, 14 Mar 2012 17:38:10 +0100

> applications that use resourceparts (such as the nickname profile for

I'm not sure if we need a full-blown PRECIS profile for resourceparts in 
general, but I do think that byte-for-byte comparison is problematic.

XML handling libraries typically deal with objects representing strings 
of codepoints, not the string of bytes sent over the wire. 
Codepoint-for-codepoint comparison is probably the reasonable minimum.

-- 
ralphm

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 14 Mar 2012 14:10:16 -0600

> Codepoint-for-codepoint comparison is probably the reasonable minimum.

Hi Ralph!

Yes, I think Dave Cridland probably meant codepoint-for-codepoint
comparison when he mentioned the idea on another list.

Purely from the perspective of stanza delivery, the server doesn't care
about presentation or user confusion, only about differentiating between
two resources. For example:

[email-masked]/Henry IV's Laptop
[email-masked]/Henry Ⅳ's Laptop

The first one has LATIN CAPITAL LETTER I and LATIN CAPITAL LETTER V
(U+0049 and U+0056), whereas the second one has ROMAN NUMERAL FOUR (U+2163).

However, if clients are ever going to show these resourceparts in the
UI, you can bet that users would be confused.

At this point in the evolution of our thinking about i18n, I think it is
probably safest to define a PRECIS profile that does exactly what
Resourceprep did using stringprep (or as close as we can come to that).
However, we would consider that profile to be a baseline, and would
allow applications that use resourceparts in more creative ways to apply
more stringent PRECIS profiles -- currently I'm thinking only about the
use of resourceparts as user nicknames in XMPP chatrooms, where the MUC
service could enforce the PRECIS nickname profile (and perhaps also
additional logic about confusable characters, yet to be defined) so as
to prevent chatroom participants from being confused about who is who in
the room.

Peter

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

---

From: Ralph Meijer <[email-masked]>
Date: Wed, 14 Mar 2012 21:38:10 +0100

On 2012-03-14 21:10 , Peter Saint-Andre wrote:
 > [..]
> two resources. [..]

Hi! Agreed.

> to prevent chatroom participants from being confused about who is who in

Yes, that does seem sensible to me, too. Figuring out conflicts between 
those PRECIS profiles might be funny, though.

-- 
ralphm

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 14 Mar 2012 15:02:21 -0600

> those PRECIS profiles might be funny, though.

If they are defined carefully, we would not have conflicts but a kind of
layering. For example, in PRECIS right now the NameClass is more
restrictive than the FreeClass, but everything that's allowed by the
NameClass is allowed by the FreeClass. I'd envision doing something
similar here -- that is, for resourceparts we'd use the FreeClass pretty
much as-is (specify NFC and perhaps optional casemapping), whereas the
nickname profile would restrict things further by specifying NFKC
instead of NFC and required casemapping. Naturally the proof of the
pudding is in the eating, and we'd need to check the codepoints that
result from each class and subclass to make sure that the nickname
profile is strictly a subset of the FreeClass.

Peter

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

---

From: Ben Campbell <[email-masked]>
Date: Mon, 19 Mar 2012 10:49:35 -0500

Hi everyone,

We've got an updated, and probably final*, agenda:

http://www.ietf.org/proceedings/83/agenda/agenda-83-xmpp.txt

* Of course, it's always bashable :-)

Thanks!

Ben.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 19 Mar 2012 15:15:52 -0600

>> http://tools.ietf.org/html/draft-saintandre-xmpp-6122bis-01

As previously noted, that's draft-ietf-xmpp-6122bis-00. :)

>> http://tools.ietf.org/html/draft-saintandre-precis-nickname-00

Here are slides (subject to change this week):

http://www.saint-andre.com/ietf/ietf83-xmpp-6122bis.pdf

http://www.saint-andre.com/ietf/ietf83-precis-nickname.pdf

Feedback is welcome!

Peter

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

---

From: Matt Miller <[email-masked]>
Date: Sun, 25 Mar 2012 16:40:06 +0200

Slides (subject to change): < http://outer-planes.net/ietf/ietf83-xmppwg-e2e.pdf >

>> -- Domain Name Assertions (Matt Miller) -- 15 min
>> 	
>> 	List Discussion, 

Slides (subject to change): < http://outer-planes.net/ietf/ietf83-xmppwg-dna.pdf >

- - m&m

Matt Miller - <[email-masked]>
Cisco Systems, Inc.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 26 Mar 2012 02:12:19 +0200

On 3/25/12 4:40 PM, Matt Miller wrote:
> Slides (subject to change): <
> http://outer-planes.net/ietf/ietf83-xmppwg-e2e.pdf >
> 
>>> -- Domain Name Assertions (Matt Miller) -- 15 min  List
>>> Discussion, http://tools.ietf.org/html/draft-ietf-xmpp-dna-01
>>> 
> 
> Slides (subject to change): <
> http://outer-planes.net/ietf/ietf83-xmppwg-dna.pdf >

Yay! Looks like we could have an interesting discussion. :)

Peter

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

---

From: Matt Miller <[email-masked]>
Date: Mon, 26 Mar 2012 09:26:40 +0200

On Mar 26, 2012, at 02:12, Peter Saint-Andre wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

slides updated to fix typos (same location)

> Yay! Looks like we could have an interesting discussion. :)

That's the hope (-:

- - m&m

---

From: Dave Cridland <[email-masked]>
Date: Mon, 26 Mar 2012 15:22:39 +0100

> >> http://outer-planes.net/ietf/ietf83-xmppwg-dna.pdf >

A few comments:

1) I still maintain you don't need to change XMPP on the wire at all  
to handle this case.

All you need to do is change, in effect, the out of band RFC 6125  
replacement which allows us to delegate service to a specific cert.

2) You needn't signal to a connecting entity (C2S or S2S) that you're  
capable of using this replacement, whichever it is. How you  
authenticate people is up to you; how they authenticate you is up to  
them. You present the best certificate you can in each case.

3) You needn't change the on-wire format of XEP-0220 either -  
dialback can carry a key even if it's ignored by the other end.

Doing things this way is not only simpler, it also means that there's  
no fork-lift required.

Now, you *can* have a stream feature so that servers can boast about  
how they use DANE, .well-known, and TurboHalibut - but this is  
essentially in-line marketing, and it's equivalent to suggesting that  
clients should list what SASL mechanisms they will use to servers.  
Really, the peer (client or server) will trust what it trusts.

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: Peter Saint-Andre <[email-masked]>
Date: Mon, 26 Mar 2012 17:53:24 +0200

On 3/26/12 4:22 PM, Dave Cridland wrote:
> 1) I still maintain you don't need to change XMPP on the wire at all to
> handle this case.
> 
> capable of using this replacement, whichever it is. How you authenticate
> people is up to you; how they authenticate you is up to them. You
> present the best certificate you can in each case.
> 
> 3) You needn't change the on-wire format of XEP-0220 either - dialback
> can carry a key even if it's ignored by the other end.

Yes, that's broadly consistent with what Matt Miller, Richard Barnes,
and I discussed yesterday.

Peter

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

---

From: Philipp Hancke <[email-masked]>
Date: Mon, 26 Mar 2012 20:16:49 +0200 (CEST)

On Mon, 26 Mar 2012, Dave Cridland wrote:
> All you need to do is change, in effect, the out of band RFC 6125 replacement 
> which allows us to delegate service to a specific cert.

well, you still need to answer the "when to multiplex two target domains 
to the same tcp connextion" issue. Sounds trivial (same ip/port + support 
for dialback errors as described in 220), but even I was scared 
when implementing this. The main problem is that it takes quite a number 
of round trips to discover the latter condition. That quickly becomes ugly 
and inefficient. bidi helps a little at least.

---

From: Matt Miller <[email-masked]>
Date: Wed, 28 Mar 2012 09:50:44 +0200

> and I discussed yesterday.

Richard Barnes expressed a desire for the receiving server to *require* the initiating server support these alternatives.  I tentatively agree that this can be done with no changes, but not yet completely (-:

Sounds like we'll have a fruitful discussion today at 13:10Z (-:

- - m&m

---

From: Dave Cridland <[email-masked]>
Date: Wed, 28 Mar 2012 09:00:00 +0100

On Wed Mar 28 08:50:44 2012, Matt Miller wrote:
> Richard Barnes expressed a desire for the receiving server to  
> *require* the initiating server support these alternatives.  I  
> tentatively agree that this can be done with no changes, but not  
> yet completely (-:

So the receiving server needs to require the initiator to  
authenticate it in certain ways?

What if those ways are considered insufficient by the initiator? What  
if the initiator supports other ways, which work to its satisfaction?  
How far do we go - do we mandate trust anchors? Allowable SANs?

How does the receiving server enforce its requirement?

I don't really see the benefit of going this route.

(I do see a benefit to servers to have a configured list of how they  
think they could be authenticated, but equally that then has the  
possibility of needing code changes on the receiving server, which  
otherwise isn't mandated, so...)

Dave.