Subject: [xmpp] Consensus Call on Adoption of POSH

From: Ben Campbell <[email-masked]>
Date: Mon, 6 Jan 2014 16:07:32 -0600

(as chair)

Hi,

The XMPP working group has a chartered work item for enabling multi-domain hosting and server connection sharing.

Matt has been working on POSH for a while now, as an enabler for that work. POSH is not currently expected to get its own working group, and no other working group is chartered for that work. Several people have proposed that, while POSH may have general applicability, XMPP is the group that needs it, and therefore XMPP should adopt it. It is further proposed that, we would try to keep it reasonably general, but would focus on XMPP related requirements.

Should we adopt https://datatracker.ietf.org/doc/draft-miller-posh/ as a working group item in support of the aforementioned chartered work? Keep in mind that acceptance does not mean the work group thinks the draft is absolutely correct or complete. It merely means that we think that the draft is a good start towards the milestone.

Please send your opinions to the XMPP working group by Jan 20.

Thanks!

Ben.

---

From: Philipp Hancke <[email-masked]>
Date: Mon, 06 Jan 2014 23:14:27 +0100

> Please send your opinions to the XMPP working group by Jan 20.

Yes -- it solves a deployment problem and improves the current 
situation. I have some rough running code for it. It seems to be easy to 
implement, the specification is well written.

I do FWIW not think that it solves the milestone you mention (we have 
DNA for that), but it's an important building block.

---

From: Matthew Wild <[email-masked]>
Date: Mon, 6 Jan 2014 22:16:22 +0000

> Should we adopt https://datatracker.ietf.org/doc/draft-miller-posh/ as a working group item in support of the aforementioned chartered work? Keep in mind that acceptance does not mean the work grou…

Yes, we should. It fills a necessary gap, and we have experimental
implementations already without any major issues.

Regards,
Matthew

---

From: Tobias Markmann <[email-masked]>
Date: Mon, 6 Jan 2014 23:21:44 +0100

Hi (this time to the whole list),

On Mon, Jan 6, 2014 at 11:07 PM, Ben Campbell <[email-masked]> wrote:

> Matt has been working on POSH for a while now, as an enabler for that
> work. POSH is not currently expected to get its own working group, and no
> other working group is chartered for that work. Several people have
> proposed that, while POSH may have general applicability, XMPP is the group
> that needs it, and therefore XMPP should adopt it. It is further proposed
> that, we would try to keep it reasonably general, but would focus on XMPP
> related requirements.
>
> Should we adopt https://datatracker.ietf.org/doc/draft-miller-posh/ as a
> working group item in support of the aforementioned chartered work? Keep in
> mind that acceptance does not mean the work group thinks the draft is
> absolutely correct or complete. It merely means that we think that the
> draft is a good start towards the milestone.
>

Yes. I think we should adopt POSH. The XMPP community as a whole is on its
way to ubiquitous encryption and authentication would be the obvious next
step from here [1]. POSH plays an important role here, especially for
hosted IM solutions, to bridge the time till DNSSEC and DANE is more
widespread, a lot TLDs still don't support DNSSEC, including the in the IM
world pretty popular .im TLD. I for one plan to update my current POSH
implementation for the Prosody XMPP server, which I started at the POSH BOF
meeting in Berlin.

Cheers,
Tobias

[1] https://github.com/stpeter/manifesto/blob/master/manifesto.txt

---

From: Ben Campbell <[email-masked]>
Date: Tue, 7 Jan 2014 09:16:34 -0600

On Jan 6, 2014, at 4:14 PM, Philipp Hancke <[email-masked]> wrote:

> I do FWIW not think that it solves the milestone you mention (we have DNA for that), but it's an important building block.

That is my understanding as well. It's a piece of the work, not all of it.

---

From: Alexander Holler <[email-masked]>
Date: Thu, 30 Jan 2014 09:46:41 +0100

> Please send your opinions to the XMPP working group by Jan 20.

Why does it use JSON and not XML? This makes it necessary to use another 
parser besides the XML-parser already available in http- and 
xmpp-clients and servers.

And if uses JSON, please make sure to define how comments will have to 
look. Last time I looked at the JSON spec, it didn't know comments, 
something I have no comment for. ;)

Regards,

Alexander Holler

---

From: Tobias Markmann <[email-masked]>
Date: Thu, 30 Jan 2014 10:13:18 +0100

On Thu, Jan 30, 2014 at 9:46 AM, Alexander Holler <[email-masked]>wrote:

> parser besides the XML-parser already available in http- and xmpp-clients
> and servers.
>

It uses JSON because it uses the JSON Web Key[1] format. POSH was
generalized to work for more than just the XMPP protocol, which, I suppose,
is the reason for it not wanting to depend on XML parsers.

The JSON[2] spec referenced by JWK doesn't mention comments at all. I guess
the JSON you'll use in JWK simply can't include any comments.

Cheers,
Tobias

[1] http://tools.ietf.org/html/draft-ietf-jose-json-web-key-20
[2] http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-10

---

From: Alexander Holler <[email-masked]>
Date: Thu, 30 Jan 2014 11:54:24 +0100

> the JSON you'll use in JWK simply can't include any comments.

Thats why I said POSH should define how comments shpuld be defined.
Almost any JSON parser provides a syntax for comments (e.g. using # or
//) and I'm unable to understand why comments in JSON aren't standardized.

And if I read the draft for POSH, e.g. setion 8. shows why one (human)
would like to have comments.

Regards,

Alexander Holler

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Thu, 30 Jan 2014 12:25:44 +0000

(As chair)

JSON comments are *out of scope* for the XMPP working group.  Please take
your suggestions to the JSON working group if you think you have an
approach that can be adopted.

On 1/30/14 11:54 AM, "Alexander Holler" <[email-masked]> wrote:

>_______________________________________________
>xmpp mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/xmpp
>

---

From: Alexander Holler <[email-masked]>
Date: Thu, 30 Jan 2014 13:48:25 +0100

> approach that can be adopted.

Hmm, so you are going to define or adopt a standard which lacks the 
possibility to use comments (either to provide human readable 
descriptions or as a way to quickly deactivate something)?

I would't call this out of scope. If you adopt POSH without providing 
(defining) a way how to add comments to the JSON definitions, this will 
be a serious flaw (in my humble opinion).

I'm not calling that the XMPP working group fixes that serious problem 
of JSON, I'm calling that they will add a sentence like "comments may 
start with a #) to the POSH standard or it's adoption if the working 
group is going to adopt it. You might call it a "variant" of JSON.

Anyway, I've just wanted to provide a maybe useful comment for POSH and 
don't want to discuss JSON.

Regards,

Alexander Holler

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Thu, 30 Jan 2014 13:30:35 +0000

>descriptions or as a way to quickly deactivate something)?

I carefully didn't say that.  Choosing something other than JSON is
certainly in scope.

>I would't call this out of scope.

If there are others that feel this way, let's have the discussion here to
try to change my mind, I suppose.  Failing that, there's an appeal
process.  I will say that when there's a currently chartered and active
working group in a particular space (json), it would be really odd to do
work on that protocol in a different working group (xmpp).

>If you adopt POSH without providing

That part of the discussion is also in scope.  Changing *JSON itself* is
the only thing I'm declaring out of scope for this wg.

>group is going to adopt it. You might call it a "variant" of JSON.

Setting up a competitor to JSON is not in this group's charter.  We don't
have to use JSON, but if we do, we'll have a normative reference to the
JSON RFC.

>don't want to discuss JSON.

Let's continue that discussion then.  Is there anyone else that thinks
that comments are important in POSH?  Are  those comments more important
than using JSON?  Can we come up with a format that includes comments in a
JSON-compatible manner?

-- 
Joe Hildebrand

---

From: Dave Cridland <[email-masked]>
Date: Thu, 30 Jan 2014 14:01:40 +0000

On 6 Jan 2014 22:07, "Ben Campbell" <[email-masked]> wrote:
>
>
> (as chair)
>
> Hi,
>
> The XMPP working group has a chartered work item for enabling
multi-domain hosting and server connection sharing.
> Please send your opinions to the XMPP working group by Jan 20.

Late comment, sorry, but I consider this a slam-dunk adoption personally. I
think something like this is inevitable, and this is a viable idea from the
outset.

(Joe spurred me into replying at the XMPP Summit).

Dave.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 30 Jan 2014 09:12:05 -0600

(As the "other chair:)

I concur with Joe that extensions to JSON itself belong in the JSON working group. That being said, if we run into a JSON limitation, nothing prevents us (or some subset of us) from taking the problem to the JSON wg. Perhaps if any JSON chairs happen to be monitoring this thread, they can comment on how this sort of thing fits in their charter and schedule ;-)

(As individual: I am agnostic towards the need for comments, and if they are best handled in JSON (the format, not the wg) vs elsewhere. I await further discussion to form an opinion.)

Thanks!

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 30 Jan 2014 09:16:04 -0600

(As [the other] Chair)

Alexander, do you support (or object to)  adoption of POSH as a working group item? 

Keep in mind that adoption doesn't imply the draft is complete or even correct, just that it's the best way forward. I expect we would continue this discussion, among other technical discussions.

Thanks!

Ben.

On Jan 30, 2014, at 6:48 AM, Alexander Holler <[email-masked]> wrote:

> Hmm, so you are going to define or adopt a standard which lacks the possibility to use comments (either to provide human readable descriptions or as a way to quickly deactivate something)?
> 
> I would't call this out of scope. If you adopt POSH without providing (defining) a way how to add comments to the JSON definitions, this will be a serious flaw (in my humble opinion).
> 
> I'm not calling that the XMPP working group fixes that serious problem of JSON, I'm calling that they will add a sentence like "comments may start with a #) to the POSH standard or it's adoption if the working group is going to adopt it. You might call it a "variant" of JSON.
> 
> Anyway, I've just wanted to provide a maybe useful comment for POSH and don't want to discuss JSON.
> 
> Regards,
> 
> Alexander Holler
> 
>> 
>>

---

From: Alexander Holler <[email-masked]>
Date: Thu, 30 Jan 2014 18:33:09 +0100

> Alexander, do you support (or object to)  adoption of POSH as a working group item?

Hmm, I haven't studied POSH in depth, but I like everything which gets 
rid of the need of DNSSEC (to store certificates) or CA's and enables 
the use of e.g. self-signed certificates for XMPP. I don't trust the 
root key of DNSSEC or any CA. ;)

So I would like POSH, I just think it should accept some form of 
comments in their JSON (as most JSON-parsers already do).

I've run into that problem with missing standardized comments in JSON 
already in other places, that's why I've brought up that topic (as I 
really think it is fatal design flaw of JSON in it's current form, at 
least if whatever that JSON is used for should be readable/editable by 
humans).

Regards,

Alexander Holler

---

From: Lance Stout <[email-masked]>
Date: Fri, 31 Jan 2014 14:54:51 +0100

+1 to adopting POSH in the XMPP WG; this is a good starting point to work from.

---

From: Matt Miller <[email-masked]>
Date: Thu, 30 Jan 2014 08:28:51 -0700

[ speaking as a co-chair of the JSON Working Group ]

The sole item for the JSON WG -- an update to RFC4627 -- is currently
in the RFC editor's queue.  The WG discussed the topic of comments a
number of times, but there was no consensus to add comments to the
JSON format at the time.

The JSON WG is currently discussing what to do next.

[ speaking personally ]

I don't think the lack of a specific syntax for comments is all that
harmful.  Plenty of systems use JSON today for configuration, and seem
to be getting by fine; *some* of them use a special syntax, but many
(from the discussions in the jSON WG, it might even be a majority)
make use of special name/value pairs within the objects.

- -- 
- - m&m

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

On 1/30/14, 8:12 AM, Ben Campbell wrote:
> (As the "other chair:)
> 
> I concur with Joe that extensions to JSON itself belong in the JSON
> working group. That being said, if we run into a JSON limitation,
> nothing prevents us (or some subset of us) from taking the problem
> to the JSON wg. Perhaps if any JSON chairs happen to be monitoring
> this thread, they can comment on how this sort of thing fits in
> their charter and schedule ;-)
> 
> (As individual: I am agnostic towards the need for comments, and if
> they are best handled in JSON (the format, not the wg) vs
> elsewhere. I await further discussion to form an opinion.)
> 
> Thanks!
> 
> Ben.
> 
>>>> JSON comments are *out of scope* for the XMPP working group.
>>>> Please take your suggestions to the JSON working group if you
>>>> think you have an approach that can be adopted.
>>> 
>>> Hmm, so you are going to define or adopt a standard which lacks
>>> the possibility to use comments (either to provide human
>>> readable descriptions or as a way to quickly deactivate
>>> something)?
>> 
>> I carefully didn't say that.  Choosing something other than JSON
>> is certainly in scope.
>> 
>> If there are others that feel this way, let's have the discussion
>> here to try to change my mind, I suppose.  Failing that, there's
>> an appeal process.  I will say that when there's a currently
>> chartered and active working group in a particular space (json),
>> it would be really odd to do work on that protocol in a different
>> working group (xmpp).
>> 
>>> If you adopt POSH without providing (defining) a way how to add
>>> comments to the JSON definitions, this will be a serious flaw
>>> (in my humble opinion).
>> 
>> That part of the discussion is also in scope.  Changing *JSON
>> itself* is the only thing I'm declaring out of scope for this
>> wg.
>> 
>>> I'm not calling that the XMPP working group fixes that serious
>>> problem of JSON, I'm calling that they will add a sentence like
>>> "comments may start with a #) to the POSH standard or it's
>>> adoption if the working group is going to adopt it. You might
>>> call it a "variant" of JSON.
>> 
>> Setting up a competitor to JSON is not in this group's charter.
>> We don't have to use JSON, but if we do, we'll have a normative
>> reference to the JSON RFC.
>> 
>> Let's continue that discussion then.  Is there anyone else that
>> thinks that comments are important in POSH?  Are  those comments
>> more important than using JSON?  Can we come up with a format
>> that includes comments in a JSON-compatible manner?
>> 
>> -- Joe Hildebrand
>> 
>> 
>> 
>> _______________________________________________ xmpp mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/xmpp
> 
> _______________________________________________ xmpp mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/xmpp
>

---

From: Alexander Holler <[email-masked]>
Date: Fri, 31 Jan 2014 16:49:25 +0100

> make use of special name/value pairs within the objects.

When you use it for configuration, you can just use the comment type the
parser of your choice uses. You rely on that parser anyway and will
unlikely switch it. And that workaround to use a special key with the
comment as value is ugly and doesn't give you the possibility to quickly
or temporary disable stuff, nor does it give you the possibility to
comment whole blocks.

Nothing of the above is a solution for standards. They can not rely on
the parser and using a special key as comment doesn't make sense.

And I'm unable to see why they have a problem in defining a character
and it's successors until newline as whitespace. Maybe they can't decide
on the character. They even don't have to enforce it, all what is
necessary is that they standardize one and the same character for the
optional comment-functionality so that all comment-allowing parsers do
use the same character. Something which should have been done right from
the beginning.

Anyway, I assume I'm now really offtopic. Sorry for that, but for me
missing comment functionality is a show blocker for many things and it
smells like going back to stone age.

Regards,

Alexander Holler

---

From: Kevin Smith <[email-masked]>
Date: Sat, 1 Feb 2014 07:55:10 +0000

> Should we adopt https://datatracker.ietf.org/doc/draft-miller-posh/ as a working group item in support of the aforementioned chartered work? Keep in mind that acceptance does not mean the work grou…

I don't much like POSH as a concept; it resolves the issue of virtual
hosting certificates
(keys) by making it someone else's responsibility to virtual host
certificates(keys).

However, this is a mostly solved problem for HTTPS and I think the WG
should adopt POSH in the absence of better options.

/K