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

[Peter Saint-Andre - &yet <[e-mail]>]

On 7/30/15 11:55 PM, Barry Leiba wrote:
> Hi, Peter, and thanks for the quick response.  Only the last issue
> remains to chat further about:
>
>>> -- 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.
>>
>> 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?
>
> 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.

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.

> If you like, it could even do POSH service names and POSH format
> names, and specify ".well-known/posh/<servicename>/<formatname>",

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

> define one <formatname> as "json" and say that a registry could be
> 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.

> 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".

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

Peter

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