On 19.02.18 16:30, Joe Clarke wrote:
> Speaking as a contributor...
>
> On 2/19/18 05:03, Eliot Lear wrote:
> > All,
>
> > Mark Nottingham and I had some extensive conversations about how
> > to handle the MUD URL.  The issue is was that Mark identified a
> > potential violation of a best practice in the way the URL was
> > structured.  The principles I seek to maintain are these:
>
> > * The base MUD URL is formed solely by the Thing
>
> _Formed by_, but relies on the URL pointing to something in the manuf.
> world.  Meaning, the Thing doesn't just make this up, which is how it
> initially read to me.
>
> > * It may be necessary in the future for the MUD controller to
> > provide additional information to the MUD file server. * How that
> > happens can be decided in the future, but we should be conservative
> > in our approach to leave options opened.
>
> This sounds reasonable.
>
>
> > Therefore, the result of the discussions is that we should permit
> > a normal HTTPS URI as a MUD URL, with all the associated semantics,
> > with the exception that queries for now will not be allowed.
>
> > At the same time, as we build out future work, we will hold
> > discussions with the Web/HTTP folk on the best way to proceed.
> > There are at least two ways to tackle this in the future: an HTTP
> > header, or some limited use of the query component.  We needn't
> > decide any of that today.
>
> > Is this okay with you?
>
> Yes.  It is good to be careful as to ensure a strong standard.  But...
>
> Speaking as a co-chair...
>
> Is this a case of perfect being the enemy of good?  I know of some
> people working to implement this.  I don't think they are all on this
> list.  Have you run this by them to see if this limits any use cases
> out of the box?

I have.  I think they're okay with it.  They would have been better with
it if we had resolved this a year ago but one doesn't get everything one
wants.  They DO expect us to hold discussions with the apps folks so we
can get on to the next thing.

Eliot

> It wouldn't make sense to put something out that
> wouldn't be implemented (i.e., implementors all need that future work
> to happen first).
>
> Joe
>

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Reply via email to