Re: [art] Revising BCP56: On the use of HTTP as a Substrate

In reading over the current draft a bit more, another specific piece of 
advice stuck out as interesting:

    Another common practice is assuming that the HTTP server's name space
    (or a portion thereof) is exclusively for the use of a single
    application.  This effectively overlays special, application-specific
    semantics onto that space, precludes other applications from using
    it.

It's the "or portion thereof" that sticks out at me. I'll note that this 
*is* consistent with the guidance in RFC7320 section 2.3, but that 
document didn't cross my radar at the time either.

In a similar vein as my questions before -- if this guidance were in 
effect at the time that RFC 4825 (XCAP) were under development, are we 
sure that it would have been appropriate? Semantically, the extension of 
URL paths down into XML documents seems both clean and appropriate; 
however, it is most certainly overlaying "special, application-specific 
semantics" onto the path component.

So, if we were doing XCAP today from scratch, what *would* be the 
preferred mechanism for addressing an element?

/a

On 7/11/17 06:14, Mark Nottingham wrote:
> A number of folks have recently noted that BCP56 addresses the problems of using HTTP for protocols in the early 2000's, but we've moved on considerably since then.
>
> Given the number of IETF protocols being build upon HTTP these days, it seems timely to reconsider it. I've been working on a candidate for replacing it for a little while; see:
>    https://tools.ietf.org/html/draft-nottingham-bcp56bis
>    https://mnot.github.io/I-D/bcp56bis/
>
> I have a small-ish slot in the HTTP WG session on Wednesday to discuss this.
>
> Cheers,
>
> --
> Mark Nottingham   https://www.mnot.net/
>
> _______________________________________________
> art mailing list
> art@ietf.org
> https://www.ietf.org/mailman/listinfo/art