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

["Ben Campbell" <[e-mail]>]

On 31 Jul 2015, at 0:55, 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.
>
> 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".

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)

>
> Barry