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

Hi, all,

I too look forward to this coordination, especially as Eliot notes its
impact on the IANA ports review team.

I would encourage a look at RFC 7605 on this issue.

Joe

On 7/11/2017 1:36 AM, Eliot Lear wrote:
> Hi Mark,
>
> There is no question that 3205 could use a dust off.  I would suggest
> that document really served two purposes.  The first was to provide best
> practices on its use, and the second was more of an applicability
> statement.  You've gone to some detail as to best practices, but it
> seems to me more attention should be paid to the applicability component.
>
> Good engineering principles dictate not only when a mechanism should be
> used, but as important, when it should not.  HTTP's use has GREATLY
> expanded thanks in large part to REST, but it also could it might narrow
> somewhat, thanks to protocols such as CoAP, or through the further
> development of QUIC.  A valuable contribution would be to give guidance
> as to what substrate is appropriate and when.
>
> Related, we TCP/UDP port reviewers occasionally see requests for new
> ports that make use of HTTP as a substrate.  Personally I always welcome
> more guidance as to when to approve those ports.  The standing view is
> that we approve them in large part to address non-interference with
> existing services, but at some level that seems a bit of a waste, and
> perhaps we should come out more strongly to say that if HTTP is really
> to be used as a substrate, there must be some form of appropriate
> application layer dispatch perhaps tied to .well-known.
>
> I won't be attending the HTTPBIS meeting but I hope you'll consider
> these comments as you develop the document.
>
> Eliot
>
>
>
> On 7/11/17 6:14 AM, 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
>>
>
>
>
> _______________________________________________
> art mailing list
> art@ietf.org
> https://www.ietf.org/mailman/listinfo/art