The IESG | 21 May 01:36 2015
Picon

Last Call: <draft-ietf-xmpp-6122bis-22.txt> (Extensible Messaging and Presence Protocol (XMPP): Address Format) to Proposed Standard


The IESG has received a request from the Extensible Messaging and
Presence Protocol WG (xmpp) to consider the following document:
- 'Extensible Messaging and Presence Protocol (XMPP): Address Format'
  <draft-ietf-xmpp-6122bis-22.txt> as 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
ietf <at> ietf.org mailing lists by 2015-06-03. Exceptionally, comments may be
sent to iesg <at> ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document defines the address format for the Extensible Messaging
   and Presence Protocol (XMPP), including support for code points
   outside the ASCII range.  This document obsoletes RFC 6122.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/ballot/

No IPR declarations have been submitted directly on this I-D.
Ben Campbell | 20 May 23:29 2015

AD Evaluation: draft-ietf-xmpp-6122bis-22

Hi,

This is my AD evaluation of draft-ietf-xmpp-6122bis-22. I think this is 
ready for IETF last call, and will start that shortly.

I have only one comment of any substance:

-- section 3.1, 4 paragraphs from the end makes normative statements 
about the minimum and maximum length for each part of a JID. But the 
sections for each part repeat those statements, creating redundant 
normative language. I don't see disagreements between the sections, but 
it would still be better to avoid the redundancy.

Thanks!

Ben.
Florian Schmaus | 6 May 20:24 2015
Picon

6122bis nit

Hi everyone,

I know that 6122bis's IESG state is "Publication Requested", but I've a
minor remark:

3.1:

      resourcepart = 1*1023(resourcebyte)
                     ;
                     ; an "opaquebyte" is a byte used to represent a

Shouldn't 'resourcebyte' be 'opaquebyte'?

This was introduced with -18:
https://www.ietf.org/rfcdiff?url1=draft-ietf-xmpp-6122bis-17&url2=draft-ietf-xmpp-6122bis-18

- Florian

_______________________________________________
xmpp mailing list
xmpp <at> ietf.org
https://www.ietf.org/mailman/listinfo/xmpp
Ben Campbell | 23 Mar 16:06 2015

End-to-end milestone

Hi Everyone,

Based on discussion between the chairs, draft authors, and are 
directors, we are removing the end-to-end milestone. This does not mean 
the e2e work is dead. If there is sufficient interest in continuing that 
work, we can start it back up in some other context (e.g. in a dedicated 
working group). Many thanks to the various draft authors who have worked 
on this so far.

XMPP will continue to finish it’s other milestones, all of which are 
at the WGLC stage or later. When those are done, we expect to close the 
working group.

Thanks!

Ben.

_______________________________________________
xmpp mailing list
xmpp <at> ietf.org
https://www.ietf.org/mailman/listinfo/xmpp
IETF Secretariat | 23 Mar 15:45 2015
Picon

Milestones changed for xmpp WG

Deleted milestone "Define a solution for end-to-end encryption.".

URL: http://datatracker.ietf.org/wg/xmpp/charter/
internet-drafts | 9 Mar 23:56 2015
Picon

I-D Action: draft-ietf-xmpp-6122bis-19.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Extensible Messaging and Presence Protocol Working Group of the IETF.

        Title           : Extensible Messaging and Presence Protocol (XMPP): Address Format
        Author          : Peter Saint-Andre
	Filename        : draft-ietf-xmpp-6122bis-19.txt
	Pages           : 25
	Date            : 2015-03-09

Abstract:
   This document defines the address format for the Extensible Messaging
   and Presence Protocol (XMPP), including support for code points
   outside the ASCII range.  This document obsoletes RFC 6122.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-19

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-6122bis-19

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
(Continue reading)

Ben Campbell | 7 Mar 00:20 2015

No XMPP Meeting in Dallas

Hi Everyone,

I assume people have noticed by now that there is no XMPP meeting 
scheduled for Dallas. In the opinion of the chairs, none of our 
deliverables are currently in a state to benefit from a meeting.

( In all honesty, Joe and I had considered scheduling a meeting, but 
somehow screwed up the request. But that seems to have worked out for 
the best.)

I apologize for any inconvenience.

Thanks!

Ben.
internet-drafts | 24 Feb 00:05 2015
Picon

I-D Action: draft-ietf-xmpp-posh-04.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Extensible Messaging and Presence Protocol Working Group of the IETF.

        Title           : PKIX over Secure HTTP (POSH)
        Authors         : Matthew Miller
                          Peter Saint-Andre
	Filename        : draft-ietf-xmpp-posh-04.txt
	Pages           : 15
	Date            : 2015-02-23

Abstract:
   Experience has shown that it is extremely difficult to deploy proper
   PKIX certificates for TLS in multi-tenanted environments.  As a
   result, domains hosted in such environments often deploy applications
   using certificates that identify the hosting service, not the hosted
   domain.  Such deployments force end users and peer services to accept
   a certificate with an improper identifier, resulting in obvious
   security implications.  This document defines two methods that make
   it easier to deploy certificates for proper server identity checking
   in non-HTTP application protocols.  While these methods developed for
   use in the Extensible Messaging and Presence Protocol (XMPP) as a
   Domain Name Association (DNA) prooftype, they might also be usable in
   other non-HTTP application protocols.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-xmpp-posh/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-xmpp-posh-04
(Continue reading)

Ben Campbell | 21 Feb 01:30 2015

PROTO review of draft-ietf-xmpp-posh

Hi Peter and Matt,

I’m in the process of doing a PROTO writeup for POSH, and have one 
possibly material comment, and a few minor comments. Apologies for not 
turning these up during WLGC, and also if these rehash stuff we’ve 
already closed on. (The chairs should yell at me.)

— Material Comment: IANA Considerations

These seems a bit unusual, since we are registering a “fragment” 
that other protocols will use to register actual URIs.  This does not 
seem to have been contemplated by RFC5785. This also the side effect of 
establishing rules for certain entries in the well-known URI registry 
over and above those from RFC5785.

Does it make sense to actually register the prefix itself, since it’s 
not really a URI? It would seem reasonable to leave the actual 
registration to protocols that need to register posh URIs.

I see Mark Nottingham is the expert for the well-known URI registry. By 
any chance has anyone run this by him?

Editorial Comments:

— section 3, numbered steps:

Which server is the POSH server? Is that the hosting server, or the web 
server that serves the well-known URI? I can infer the answer, but it 
would be good to be explicit.

(Continue reading)

Ben Campbell | 20 Feb 22:36 2015

WGLC of draft-ietf-xmpp-dna-09


This is an XMPP Working Group Last Call of draft-ietf-xmpp-dna-09. The 
draft is available at the following URL

https://datatracker.ietf.org/doc/draft-ietf-xmpp-dna/

The WGLC will conclude on March 6, 2015. Please send your comments to 
the authors and the XMPP mailing list.

(Given that the draft deadline for IETF92 is the following Monday, I 
suspect the authors would really appreciate people not waiting till the 
last minute to send feedback.)

Thanks!

Ben.
Peter Saint-Andre - &yet | 13 Feb 18:49 2015
Picon

e2e encryption

We're close to finishing all of our deliverables (6122bis, POSH, DNA) 
other than end-to-end encryption ("e2e") - IMHO they can all be sent to 
the IESG by, say, the end of April.

I know we plan to talk about e2e at IETF 92 in Dallas at the end of 
March, but I figured it would be good to start a list thread before then.

To be blunt, we (narrowly the XMPP WG but more widely and importantly 
the XMPP community) have failed to deliver an e2e technology. It's not 
for lack of proposals over the years: PGP, S/MIME, XML encryption, 
SIGMA, e2e TLS, OTR, and JOSE-based signing and encryption have all 
flitted across the stage.

To also be blunt, I don't think we have the right people in the room 
here to make significant progress on e2e. I don't think the XSF has had 
the right people in the room, either. I am of the opinion that, in order 
to move forward, someone - probably the XSF - needs to get all the 
relevant client and library developers working together. By which I mean 
writing code, experimenting with alternative approaches, meeting in 
person for interop testing, hashing out spec details, etc. That will 
require funding (which the XSF might be able to raise and provide), 
dedicated energy among developers, and a real attempt to push forward 
together as a community.

This isn't the place to make an organizing proposal for such an 
initiative. Although it is possible that the IETF or the XMPP WG could 
work in concert with the XSF or the XMPP developer community on such an 
initiative, that has its own challenges. In any case, I don't think the 
IETF can really find rough consensus until we have the relevant 
developers engaged to write some running code.
(Continue reading)


Gmane