Subject: [xmpp] Barry Leiba's No Objection on draft-ietf-xmpp-posh-04: (with COMMENT)

From: "Barry Leiba" <[email-masked]>
Date: Wed, 29 Jul 2015 02:04:41 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-xmpp-posh-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-xmpp-posh/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

No objection, in that I'm not going to block on these points, but I do
ask for some discussion, please; see below.

General: You're inconsistent in your use of "URI" and "URL", using the
former in Sections 3 and 8, the latter in Sections 1, 3.2, and 10 -- and,
of course, calling the member "url", rather than "uri".  I'd prefer that
you use "URI", but you should, in any case, be consistent.

-- Section 3 --

   When POSH is used, the first two aspects remain the same: the POSH
   server proves it identity by presenting a PKIX certificate [RFC5280]

Typo: It proves "its" identity, not "it".

       *  If it does not have any PKIX certificate information or a
          reference to such information for the requested path, it
          responds with an HTTP client error status code (e.g., 404).

Do you really want to leave the status code unspecified ("e.g."), rather
than just saying that the code to use is 404?

-- Section 3.1 --

   o  A "fingerprints" field whose value is a JSON array of fingerprint
      descriptors.

Here and elsewhere: the JSON term is "member", not "field" (for members
of an object; arrays have "elements").

Please check the content-length in the example; I don't think it's
correct (I get 176, assuming CRLF-termination, and 135 even if I get rid
of all the pretty-print).  Similarly for the example in Section 3.2.  If
you're using the pretty-print, the content-length should reflect it.

   If no "expires" field
   is included or its value is equal to 0, a POSH client SHOULD consider
   these verification materials invalid.

But above you say that having "expires" is a "MUST".  Why is this
"SHOULD" and not "MUST", and why is 0 not just outright invalid (previous
sentence, change "non-negative" to "positive")?  (And similarly for
Section 3.2.)

-- Section 3.2 --
The example shows using the same sort of .well-known URI, but I presume
there's no requirement that this referral be to one of those (if there
is, the doc should say so).  It might be worth making it clear, with
something like this (or adjust it if my previous presumption is wrong):

OLD
   o  A "url" field whose value is a JSON string specifying the HTTPS
      URL where POSH clients can obtain the actual certificate
      information.
NEW
   o  A "url" field whose value is a JSON string specifying the HTTPS
      URL where POSH clients can obtain the actual certificate
      information.  The URL can be a similar .well-known POSH URL, but
      it need not be.
END

-- Section 8 --
I'm not terribly happy with the mechanism of having a faux hierarchy in
the .well-known name (posh.servicename.json), not registering any
.well-known name here, and asking the .well-known registry (via the
designated expert) to register and evaluate each POSH service -- the
.well-known DE is not an expert for POSH.  Also if, using your example,
Victoria Beckham should want to have a .well-known URI to access her
tweets from anywhere, returning them in JSON wrappers, she might want to
register "posh.spice.json", which would then get in the way of that name
for POSH, entirely unintentionally.

I'd be much happier with using a real URI hierarchy and registering
"posh" as a .well-known name here, so a POSH URI might be this:
   https://hosting.example.net/.well-known/posh/spice/json
or this (I prefer the former, but don't really care):
   https://hosting.example.net/.well-known/posh/spice.json
...and you might establish an FCFS registry of POSH service names under
which "spice" (or "spice.json") would be registered.  Now you're putting
it all under one .well-known name, and only asking the .well-known expert
to review this one, rather than one for every POSH service.

Hable conmigo...

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 30 Jul 2015 19:13:35 -0600

Hi Barry, thanks for the review. Replies inline.

> https://datatracker.ietf.org/doc/draft-ietf-xmpp-posh/

Given that we have implementations, I'd prefer not to change the member 
name (although I can't remember why we would have named it "url" instead 
of "uri"). We will, however, make it consistent.

> Typo: It proves "its" identity, not "it".

Noted.

> than just saying that the code to use is 404?

Good point. Specifying 404 would be better.

> of an object; arrays have "elements").

Yes, sloppy terminology on our part. We'll clean that up.

> you're using the pretty-print, the content-length should reflect it.

We'll double-check those.

> But above you say that having "expires" is a "MUST".

Good catch. Earlier in the life of this draft, the "expires" member was 
not required; that changed at one point but we neglected to update this 
text.

> Why is this
> sentence, change "non-negative" to "positive")?

On reflection, I see no reason to say SHOULD (i.e., I see no 
circumstance under which it would make sense for the client to consider 
the verification materials as valid if the "expires" value is zero).

So changing SHOULD to MUST seems like the right thing to do.

> (And similarly for

Yep.

> is, the doc should say so).

The use of .well-known is not required, it's simply a useful convention.

> It might be worth making it clear, with

+1

> to review this one, rather than one for every POSH service.

We're not terribly happy with the faux hierarchy, either, and we 
considered the approach you suggest (and consulted on the matter with 
Mark Nottingham). Unfortunately, the specification for well-known URIs 
(RFC 5785) states:

    Registered names MUST conform to the segment-nz production in
    [RFC3986].

Because the segment-nz production does not allow "/", a real hierarchy 
won't work.

In practice, we are not expecting a large number of POSH registrations 
so I doubt that this would put a significant burden on the DE for the 
well-known URI registry. However, do you think it would be helpful to 
provide some additional guidance to the DE in this document?

Peter

P.S. My co-author is on vacation right now so I might not be able to 
coordinate with him quickly.

---

From: Barry Leiba <[email-masked]>
Date: Fri, 31 Jul 2015 07:55:56 +0200

Hi, Peter, and thanks for the quick response.  Only the last issue
remains to chat further about:

> We're not terribly happy with the faux hierarchy, either, and we considered
> the approach you suggest (and consulted on the matter with Mark Nottingham).
> Unfortunately, the specification for well-known URIs (RFC 5785) states:
>
> Because the segment-nz production does not allow "/", a real hierarchy won't
> work.
>
> In practice, we are not expecting a large number of POSH registrations so I
> doubt that this would put a significant burden on the DE for the well-known
> URI registry. However, do you think it would be helpful to provide some
> additional guidance to the DE in this document?

The hierarchy would work fine: the point is that the registered
.well-known name would just be "posh", and would be registered once
here -- and that confirms fine to the .well-known requirements.  This
document would then specify the use of hierarchy under
.well-known/posh, and would create a (FCFS) registry for POSH service
names.

If you like, it could even do POSH service names and POSH format
names, and specify ".well-known/posh/<servicename>/<formatname>",
define one <formatname> as "json" and say that a registry could be
created in future if necessary.

I know that changing this would affect current implementations and
make them change, but I think it's worth it.  On the other hand, if
you don't agree, I won't push it further.  I just think it'd be much
better to have just "posh" as the registered .well-known "segment-nz".

Barry

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 31 Jul 2015 09:32:09 -0500

On 31 Jul 2015, at 0:55, Barry Leiba wrote:

>> considered

I'm a bit confused, is it seems like the effective end result would 
still be hierarchical well-known URLs. So I guess I have to wonder why 
they are prohibited from the well-known registry in the first place. Was 
there some problem the original authors were trying to avoid?

(And for the record, I agree that the current "template" approach is 
ugly)

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Fri, 31 Jul 2015 10:39:29 -0600

> .well-known/posh, and would create a (FCFS) registry for POSH service

Yes, we talked with Mark Nottingham (expert reviewer for the well-known 
URIs registry, co-author of RFC 5785) about that option, too. His 
preference was for the approach that's currently documented in the spec.

> names, and specify ".well-known/posh/<servicename>/<formatname>",

Currently it's the <servicename> field that we're most interested in.

> created in future if necessary.

That strikes me as excessively flexible, since it would imply the use of 
data formats other than JSON (say, XML?). Given that POSH is, we 
strenuously hope, a temporary workaround while DNSSEC and DANE become 
more widely deployed, I don't foresee the need for extensibility here. 
Naturally, DNSSEC/DANE might never take off, but thankfully that doesn't 
seem to be the current trajectory.

> better to have just "posh" as the registered .well-known "segment-nz".

Perhaps it makes sense to talk about it again with Mark?

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Barry Leiba <[email-masked]>
Date: Sat, 1 Aug 2015 03:50:28 +0200

> Currently it's the <servicename> field that we're most interested in.

Right... and that's what I'm suggesting an FCFS registry for.  You
register "posh" in .well-known, and you create your own FCFS registry
for service names, and if you don't care about the format as a
separate thing, you just register "spice.json" (and so on) in your
FCFS registry.  That way, Mark doesn't get involved in approving
"posh.x" and "posh.y" and "posh.z", when Mark has no idea of what to
say about posh service names (or seedy ones, for that matter).

> Perhaps it makes sense to talk about it again with Mark?

Sounds like a plan.

b