From nobody Mon Feb 8 15:28:54 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A493A0D97 for ; Mon, 8 Feb 2021 15:28:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ccm8B-PkV9M for ; Mon, 8 Feb 2021 15:28:50 -0800 (PST) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7AFE3A0D8A for ; Mon, 8 Feb 2021 15:28:50 -0800 (PST) Received: by mail-ed1-x52e.google.com with SMTP id y8so21262810ede.6 for ; Mon, 08 Feb 2021 15:28:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:mime-version:content-disposition; bh=g+/4I2P3jEe0z+sPVV0n1xpN7gis7GdPNnqNQJ7dpN0=; b=lxOA3wEpRUYYt56k63LgQWNGbCx/pjDLUvyCvwpvKjXWxHsqcqHGSjesqNFciv+hOL IEOgoDiVqu/GzMkKyIOhuYOGvpfHGXqlhkv5gxoxGL/TzWK7/HCI44uGIGqpICuiMjQL /0A+d27ZcRenIVlnKubmQQYTzvdSEtdW8nfUUNJrY4+HLnQyqEENu7pPc+mKJrokAV8l XFSSKEW11zswgDsD0/wWUW3AR8H2YGL5S6N1Cx04o2B0jDm/64S9YEhn8EkPrfbXjWl+ 4M9F+Al9TvbPWO5QVHvzq/YpENAl3147LvQ8s3h0O33snOYgdK8oBU44Hfjsew2NdZ0p gSzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition; bh=g+/4I2P3jEe0z+sPVV0n1xpN7gis7GdPNnqNQJ7dpN0=; b=gY7uFvIFSayIqSDo+DK4IZSIYFoXLPzRCcLLQPcldzsDdp5+LGHOQLPl6Hdo/x+VZI HTdLxNTBkpY/yy+PMI3Kq8Z88WXZ/07kobo2ISYxNuzVTcHez59KQsN4O1ViFBvBpQNY uETgWZpKTvfllZ2LTiYGATcIcxtVxfWyTaelzB8DpHr12eRj5TLi44jFFYr/gneIG1cv fCvlv+E731BLQjJ+7WoKE65T0suASFsE7dayTJfWQOtGphSDB4eZ7hJCx24AAZG8hdQ4 zdZATVz5h+QXHtSCf0VeaX0uWK7emiRa/sPS0FJeRM0yyLdog+GnG83AfBLx6cB8gNxe rxJw== X-Gm-Message-State: AOAM533GJ35EJ5sRjCx/QnsWCt+uWiZeLSiUjERUxtAZDmESg9KivXi0 WObiRivs5PakQwoi54e6QtKjBP4KsrA= X-Google-Smtp-Source: ABdhPJwRZ9aFiGX6sQ1SJELw+PnGnC64bYMVEqz4FrthUCgWiaBruOKo4s8uXlDTbgvGe6v9oJO41w== X-Received: by 2002:a50:fe11:: with SMTP id f17mr19425717edt.88.1612826929043; Mon, 08 Feb 2021 15:28:49 -0800 (PST) Received: from localhost (80-100-157-193.ip.xs4all.nl. [80.100.157.193]) by smtp.gmail.com with ESMTPSA id zg22sm5319754ejb.0.2021.02.08.15.28.48 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Feb 2021 15:28:48 -0800 (PST) Date: Mon, 8 Feb 2021 23:28:47 +0000 From: James To: dispatch@ietf.org Message-ID: <20210208232847.qzfeqmpxeopwtcph@59dc8eeeb793> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Archived-At: Subject: [dispatch] draft-gruessing-sdp-http - mapping SDP into HTTP structured headers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 23:28:52 -0000 Hi Dispatch, I've written a draft[1] that I'd like your help in finding the right place to carry on the work. This draft solves the problem of having session information about media being transmitted over HTTP, so implementations can use existing HTTP semantics to represent SDP data models instead of handling SDP's serialisation format. Looking at possible places for this work to go, I've considered: * mmusic - HTTP work doesn't appear to fit in here * httpapi - This work might be "too specific" for media and out of scope * wish - Whilst my use case isn't specific for WISH, it might fit in I'll be presenting to the working group at IETF 110, but before then any feedback you have would be appreciated. Regards - J 1: https://datatracker.ietf.org/doc/draft-gruessing-sdp-http/ From nobody Mon Feb 8 16:16:03 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A963A172E for ; Mon, 8 Feb 2021 16:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.08 X-Spam-Level: X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e342o0KHj6JL for ; Mon, 8 Feb 2021 16:15:59 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67CA13A172A for ; Mon, 8 Feb 2021 16:15:59 -0800 (PST) Received: from Zephyrus.local (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 1190FqwQ099642 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 8 Feb 2021 18:15:53 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1612829753; bh=4G7nU7jApWzKbnFFM9DDHd9ORzJc8lbiUOOgiCRRvAM=; h=Subject:To:References:From:Date:In-Reply-To; b=PvfxPOirnh7BYqqJcu2G/amb15/Yn6I+Gr+eTJBLez0xZRv8YAxHPy9kQDJUInLL0 5ZJWX3EYcFiXV1ATFIOPz8WOeEWAjzDa2647PuXPEm1yylQhiDx9aOW1rXZ8LnkP2p rmseTTCaU7CFjm0SEODXvsVV9hauUxZPCdFQ7QUg= X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be Zephyrus.local To: James , dispatch@ietf.org References: <20210208232847.qzfeqmpxeopwtcph@59dc8eeeb793> From: Adam Roach Message-ID: <05fd6a60-5847-59e3-8ce6-05cb224199b3@nostrum.com> Date: Mon, 8 Feb 2021 18:15:47 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <20210208232847.qzfeqmpxeopwtcph@59dc8eeeb793> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dispatch] draft-gruessing-sdp-http - mapping SDP into HTTP structured headers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2021 00:16:02 -0000 Hi! It's not as much a suggestion for where this should go as it is a request to understand the use cases involved. I see that there is a desire to avoid parsing SDP syntax when it is sent in an HTTP context. What I'm trying to work though is which use cases this might happen in and what is really gained. For the lines that are called out in this initial proposal, parsing is a pretty straightforward exercise of =, and multi-field values separated into fields using spaces. This is trivial to code. Where SDP's complexity comes into play is parsing the values of "a=" fields, which vary from attribute type to attribute type, and which will continue to grow over time as new attributes are defined. This proposal does nothing to assist in parsing these fields, and any effort to do so will necessarily require new attributes to take into account HTTP encoding (unless we're just willing to let the HTTP encoding become out of date as soon as the next attribute is defined). Given the foregoing, I'm scratching my head about which use cases will legitimately be simplified by encoding SDP as part of HTTP header fields. I think we really need to understand this before we can figure out who (if anyone) should work on it. (Minor aside: the proposal right now seems to lack any way to encode the media type, port, profile, and parameters, as well as leaving off "a=" attributes for media sections.) /a On 2/8/21 17:28, James wrote: > Hi Dispatch, > > I've written a draft[1] that I'd like your help in finding the right > place to carry on the work. > > This draft solves the problem of having session information about media > being transmitted over HTTP, so implementations can use existing HTTP > semantics to represent SDP data models instead of handling SDP's > serialisation format. > > Looking at possible places for this work to go, I've considered: > * mmusic - HTTP work doesn't appear to fit in here > * httpapi - This work might be "too specific" for media and out of scope > * wish - Whilst my use case isn't specific for WISH, it might fit in > > I'll be presenting to the working group at IETF 110, but before then any > feedback you have would be appreciated. > > Regards > > - J > > 1: https://datatracker.ietf.org/doc/draft-gruessing-sdp-http/ > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Mon Feb 8 16:21:20 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDBC3A16BC for ; Mon, 8 Feb 2021 16:21:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8g1pwijCFu2e for ; Mon, 8 Feb 2021 16:21:16 -0800 (PST) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 203413A0C9F for ; Mon, 8 Feb 2021 16:21:15 -0800 (PST) Received: by mail-ej1-x62a.google.com with SMTP id b9so28480248ejy.12 for ; Mon, 08 Feb 2021 16:21:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tZ2dcSKbFSiNRcCR5anzSd1PZ1/vFyPoyGD9wTVqbkY=; b=WD9qmzbX/kSQCQR8nFugLBiqQ2cBBn+plkY64UdrwUUP4/38FiHWKQpqPTy38++jdz v32Mvdv+CgjDb5BBxDZuAq8thcmfPbL/NN81zUUaeBBZriIH2DFEmy7trypvTmXBLk7M oRRZErTL7imYdOmB6D8LQ0bb+7x+9MsCJvsoGoBMyRy3c/qoSykFqCpryVk7iAfkhhpx cEuDkMGSikwvEi3VesQT5LL8YXQgP/VS1VtVuxXR3JKQXjvxqpoJVGI8K2TDD4IjwrqG X195dVZPAsx0edoe0PJ3FieH1yzLQ0DoI+/nuLvBFDjGC1hRDyxf1/hgMnm8881zYvpP wjzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tZ2dcSKbFSiNRcCR5anzSd1PZ1/vFyPoyGD9wTVqbkY=; b=MZ+rVLOR8qKJ+xVniNxmraJSxupoRiGn4/5EfYPGM9EC6NgyXYsTvwWkgpBZE9a8Bq Qq8YkkHbPIc19nBvjlkJdXiLPD5S2YRoLkJXFW8sf009dQ3i5BUxRcBJz4nYFGBiVI8J ElSRTc1kZKnWPlQvep21PY4SImnRHSo4mP/4rBuiGnrSDL1hSi5l5/xuKZIxxWR2ZeqA ltOee1rtuKUTfjnBoQYT5tP1n/aL6cAJ+HXn8g+ngxc7h/6bdqcWFD2IZpFYMH9KfeG3 hgJNIDccEZ6jSBc3wlyS0VPPy43qDRQ5gLaso8mbAPmFvbrGnqMYnMqKsoL4DE5bOalC P2dw== X-Gm-Message-State: AOAM533O0ynz76o+cUh7vi1WAcKH+vYisgakunFiBv3s2ih7n+GxXxoD C+1JBNg4WQpDW4Zc7037HfTBNotgZsPqXgw+dXE= X-Google-Smtp-Source: ABdhPJxEpAlF4Qqa+YHaxR7QdJpMzK3W1S42RnZf/8zy2Ow91/yg9+OAGT0X53GXuE+giykRGLKYafrIkvPqlfFyLr8= X-Received: by 2002:a17:906:5d0b:: with SMTP id g11mr19430559ejt.542.1612830074193; Mon, 08 Feb 2021 16:21:14 -0800 (PST) MIME-Version: 1.0 References: <20210208232847.qzfeqmpxeopwtcph@59dc8eeeb793> <05fd6a60-5847-59e3-8ce6-05cb224199b3@nostrum.com> In-Reply-To: <05fd6a60-5847-59e3-8ce6-05cb224199b3@nostrum.com> From: Lucas Pardue Date: Tue, 9 Feb 2021 00:21:03 +0000 Message-ID: To: Adam Roach Cc: James , DISPATCH WG Content-Type: multipart/alternative; boundary="000000000000a7c96005badc4365" Archived-At: Subject: Re: [dispatch] draft-gruessing-sdp-http - mapping SDP into HTTP structured headers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2021 00:21:18 -0000 --000000000000a7c96005badc4365 Content-Type: text/plain; charset="UTF-8" Given the parsing facets that Adam mentioned, would it be as simple to just base64-encode the SDP, and stick to reusing off-the-shelf SDP parsers? Cheers Lucas --000000000000a7c96005badc4365 Content-Type: text/html; charset="UTF-8"
Given the parsing facets that Adam mentioned, would it be as simple to just base64-encode the SDP, and stick to reusing off-the-shelf SDP parsers?

Cheers
Lucas
--000000000000a7c96005badc4365-- From nobody Mon Feb 8 19:44:33 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB293A0EDB for ; Mon, 8 Feb 2021 19:44:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.08 X-Spam-Level: X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRyTb3WfBpNo for ; Mon, 8 Feb 2021 19:44:29 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D34443A0EC9 for ; Mon, 8 Feb 2021 19:44:29 -0800 (PST) Received: from [172.17.121.48] (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 1193iNok071894 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 8 Feb 2021 21:44:24 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1612842264; bh=G4/c+stat8XExP5KKc0hzl/cxpFEKJq7Of5xVcGG/aI=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=YuogHQUVwXrRz0g5h9xvFONFqRI8PYtc/SN6LkTd/2ZS7n6+OzKxTWwhRYo9w5frp mKEqUACdXa85HQsVGUuk6hDALPxP13Ai9ANYSjLoWzcjoTt1Siqbk0M+jl6ke5AhKn Nqfc5JgiMpjJAJDBb2IeYmp1z0hgpdIoi/GpG11U= X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be [172.17.121.48] To: Lucas Pardue Cc: James , DISPATCH WG References: <20210208232847.qzfeqmpxeopwtcph@59dc8eeeb793> <05fd6a60-5847-59e3-8ce6-05cb224199b3@nostrum.com> From: Adam Roach Message-ID: <90b8d889-fe34-c6ef-f404-fbaf79b44577@nostrum.com> Date: Mon, 8 Feb 2021 21:44:14 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dispatch] draft-gruessing-sdp-http - mapping SDP into HTTP structured headers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2021 03:44:32 -0000 On 2/8/2021 6:21 PM, Lucas Pardue wrote: > Given the parsing facets that Adam mentioned, would it be as simple to > just base64-encode the SDP, and stick to reusing off-the-shelf SDP > parsers? That raises the same question about what one might gain from doing so. Would we entertain the notion of encoding images in HTTP header fields? HTML? There's a way this kind of thing is transferred in HTTP, and it's the message body. Again, before we set off trying to figure out how to put SDP into HTTP header fields and who might go about designing how to do so, I think the first step is understanding the use cases that are driving such a solution. /a From nobody Mon Feb 8 20:10:18 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 026653A18A2 for ; Mon, 8 Feb 2021 20:10:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXRvRS12M7IG for ; Mon, 8 Feb 2021 20:10:15 -0800 (PST) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F9283A18A1 for ; Mon, 8 Feb 2021 20:10:15 -0800 (PST) Received: by mail-ej1-x62f.google.com with SMTP id lg21so29195696ejb.3 for ; Mon, 08 Feb 2021 20:10:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=c2eDVULwHYdKKNfj5lS1SgYJevZig1fmBXuvTB/B/tw=; b=oCvPwNPx3q90GKW5jtL2OpKfk2V4P4uwcoeg6YckV7eLesceCHuzp1MHUlXFZEewzr VCCRZ4kHQVYUI+BQQizmXgwwuOunVD0uq9YtIbUvOL0GjeLtDhbpbURPbbkO7JhIttWk jrjsrM75O10uGwO2AG8qkuvnACCXQxy6T70MU035+aYb4tYT0jHHbURq2Y+ntrR4X4ZO c9uzCgAPR2Np7Az2ZfyPmmBofpBDBmxAL7QUxoDn5g/QMO6p/9KqHRr4+KobnSoGGFio 1bR7sO5G2fEQNDqxAl9UDif4rbjdVz/bGOaF9aZK0f5C4tVf3NKxK5YAL5AJ6vOt6ElX 2xrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=c2eDVULwHYdKKNfj5lS1SgYJevZig1fmBXuvTB/B/tw=; b=XxqcbKHGT0dV4K3ijYXi2BlGwc67lvDb6m8mBY5WjUOHVVBmNsqFy2Cj7MRNDd34g5 8D2IgxLR2/uOa6eaDIDAl3B0VihDVeOZMq3Fu+ntDdE+A8xpP24rbGbqxJwrBs1tmDEQ 16Wur5o0NT/AEnSI1kQS1cjfq1IgfYkU0yuzgLeVN4Exqa7mBKPBQeipUHfsqtJfNM5w 2Bb3WaDvgApVs8ksjeu5vIyJa7olZhstRrNzFetx7Gh6zIYAVGnUWQ+t5KJA1JrtmHm3 hIZGGNUUIEz7p9HXDAN95gNFQa6iUi6T3B/WSKv7S8wk+OCXVpyTlHeIybXcS3n5nNIr gvjA== X-Gm-Message-State: AOAM53125xR07AXk4mfPWhu433zB/yuQhq7qfaHu1U8ieUTAsBU8ucsx cO/JRqZBUCXTOCWWSPY5DNTjxC09n2cyZe7tDWI= X-Google-Smtp-Source: ABdhPJymh57W/ek/Xfj1repObqd++OQm2COTY0R7DK+vlU+vxKCOWTekCGX4OWkyMgyf32Z7oDdcVtV397ilP3tQ6mI= X-Received: by 2002:a17:906:2755:: with SMTP id a21mr20641125ejd.374.1612843813625; Mon, 08 Feb 2021 20:10:13 -0800 (PST) MIME-Version: 1.0 References: <20210208232847.qzfeqmpxeopwtcph@59dc8eeeb793> <05fd6a60-5847-59e3-8ce6-05cb224199b3@nostrum.com> <90b8d889-fe34-c6ef-f404-fbaf79b44577@nostrum.com> In-Reply-To: <90b8d889-fe34-c6ef-f404-fbaf79b44577@nostrum.com> From: Lucas Pardue Date: Tue, 9 Feb 2021 04:10:03 +0000 Message-ID: To: Adam Roach Cc: James , DISPATCH WG Content-Type: multipart/alternative; boundary="00000000000096e3d605badf76ec" Archived-At: Subject: Re: [dispatch] draft-gruessing-sdp-http - mapping SDP into HTTP structured headers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2021 04:10:17 -0000 --00000000000096e3d605badf76ec Content-Type: text/plain; charset="UTF-8" On Tue, 9 Feb 2021, 03:44 Adam Roach, wrote: > > That raises the same question about what one might gain from doing so. > Would we entertain the notion of encoding images in HTTP header fields? > Good idea. SVGs can be super tiny [1], we could then leverage HPACK compression ;) HTML? There's a way this kind of thing is transferred in HTTP, and it's > the message body. > Again, before we set off trying to figure out how to put SDP into HTTP > header fields and who might go about designing how to do so, I think the > first step is understanding the use cases that are driving such a solution. > In seriousness, I agree totally. I might hazard a guess that the SDP is being considered as metadata for the associated media. Therefore to use HTTP, the proposal directly overlays on HTTP concepts of metadata and content. But I'd love to hear more about the motivation from the horses mouth. Cheers Lucas [1] https://github.com/edent/SuperTinyIcons --00000000000096e3d605badf76ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, 9 Feb 2021, 03:44 Adam Roach, <adam@nostrum.com> wrote:

That raises the same question about what one might gain from doing so.
Would we entertain the notion of encoding images in HTTP header fields?

Goo= d idea. SVGs can be super tiny [1], we could then leverage HPACK compressio= n ;)

HTML? There's a way this kind of thing is transferred in HTTP, and it&#= 39;s
the message body.

Again, before we set off trying to figure out how to put SDP into HTTP
header fields and who might go about designing how to do so, I think the first step is understanding the use cases that are driving such a solution.=

= In seriousness, I agree totally.=C2=A0

I might hazard a guess that the SDP is being considered as m= etadata for the associated media. Therefore to use HTTP, the proposal direc= tly overlays on HTTP concepts of metadata and content. But I'd love to = hear more about the motivation from the horses mouth.

Cheers=C2=A0
--00000000000096e3d605badf76ec-- From nobody Tue Feb 9 03:37:34 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10EB13A19D3 for ; Tue, 9 Feb 2021 03:37:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9PP4NKC-nNy for ; Tue, 9 Feb 2021 03:37:31 -0800 (PST) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2062.outbound.protection.outlook.com [40.107.20.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 566AA3A16E5 for ; Tue, 9 Feb 2021 03:37:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UdQhT207hNfJQNVzw6I0BdQ40ySHnJSlOJuu/ofMLyYAjYMiFIGfXJy1UBDZmaZboiYpUkXudm5uUE3/vU5qDjjGhuXHNKLFBBzcu9USmFnfIuqQi0mg2LIHR49YLgLuF5jP7+d9nkjD9va5GzG6En73li1mMK/HWcIKWC+9bL2Is471XqXWmiutdQqSUZYfTGKgdjwK3HUin75KBzmIWWaDPN2W5jPiVLDXVWYM79XqiY3e2JlwButnekAnaiYEgC+SRGEJIETKLq0nFAiZJuMvNkZicC54TzbNGTLxoW9UHeXLbYkiQZKcwsG43I0u0+WrI2qNAb3slKGEUcGFag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/5RYnEe/iOs6YDEkRwc5c35STPYQL6RCc/mZClh2CZI=; b=XE3tpKOrRZ982NCRSVHrkmxn7C9RLCYHvZ4LkuTNOnbDFqyI+DTRKSu0A7eNTx2AjJA8OX5oV2mdjOiWvn9vfis8XUl+83sQOzmGxBVwVTrLh5Q+UHhANYdofXIXlpm8weh8DvqbjcsnnKNvDzoNdkuFWoofoZOrIsGHzLz6SBkxyxp5ZL74k9GbYNpc6nPforIaDZw5uvjj8d2oJqp207F3SjiWdg2scJFNoKwZ1T+AyGa0UaHlSkKZa69oZ9+j6eifnzgDMkzjUaxQhr2+35xjeoNS4gUmmLuQlJnLUQlF8993CE24wXwCtkc0QO47OC0gWkcnkmTGe43y1YVecw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/5RYnEe/iOs6YDEkRwc5c35STPYQL6RCc/mZClh2CZI=; b=HzjuW7wxawDgHFS8pZ+7LYhJU9M7QTDIVpP5uSeX2rmZlLQJbASLm4OqCXtLK6wT76RPdMYaySu4mKzZeoFb+eF5oS5xYZFMJ7ggn4WLSSllsydflyDqbvywaOSXGSl6IZyLmWzq806GFWo1XR/N+P2WgyMOhkzjRMJ8pcCMkNs= Received: from (2603:10a6:208:4c::18) by AM4PR07MB3473.eurprd07.prod.outlook.com (2603:10a6:205:c::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.11; Tue, 9 Feb 2021 11:37:28 +0000 Received: from AM0PR07MB3860.eurprd07.prod.outlook.com ([fe80::35d8:a4ac:4e0d:f0dd]) by AM0PR07MB3860.eurprd07.prod.outlook.com ([fe80::35d8:a4ac:4e0d:f0dd%4]) with mapi id 15.20.3846.025; Tue, 9 Feb 2021 11:37:28 +0000 From: Christer Holmberg To: Adam Roach , Lucas Pardue CC: DISPATCH WG Thread-Topic: [dispatch] draft-gruessing-sdp-http - mapping SDP into HTTP structured headers Thread-Index: AQHW/nI0Vh6bcEtGIUybE+q0E13y0apO9ImAgAABeICAADjFAIAAgqtw Date: Tue, 9 Feb 2021 11:37:28 +0000 Message-ID: References: <20210208232847.qzfeqmpxeopwtcph@59dc8eeeb793> <05fd6a60-5847-59e3-8ce6-05cb224199b3@nostrum.com> <90b8d889-fe34-c6ef-f404-fbaf79b44577@nostrum.com> In-Reply-To: <90b8d889-fe34-c6ef-f404-fbaf79b44577@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nostrum.com; dkim=none (message not signed) header.d=none;nostrum.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [80.248.247.159] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b53c84f5-85b2-4ff5-4075-08d8ccef149d x-ms-traffictypediagnostic: AM4PR07MB3473: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1RlOf290Y/tRizFp0xARDzNGAo0/QdMcj1IvKN1N+aTKl0cZKbElpTqvuBmVZSg5Vf7oy1xqtKqRSuvdzorQzP1WJ54ML+7H9Xh5sRKSj5k8wn+o7WS1ikpJNhXWR5f/CH3fLjaAX6xju0hSIt4Snv7Ujh+qkE8KtftYZapss20rVBptsHfxTAZSVmYUIoAAofwwM/bC8xSAkOXUSSU0b6dYYnuYwuOO5q9neEmdyawXumVRElOz37fvhe2eU5WMV6gISxj7bFfhSIQ+QDsB9iLvZ2vYyi/7uFx8pVktHfR9USJa62U7sHY1vWM2iLYKNNGYJR0w3NQs7sWQ1OV2EdwAneWlSok89Og+h8ldCYglOglL41LerLjhbjdTP4EQZ86oZC5HWi4bN5D6bhh8mD72+pQoDOmmX2xol6XFtnBgXnVNWEAir/zu68m99rS9rdGGXILXBaJFnPIVs0trQ+/jRV5SPIl05PD88YyAN6/fTvyWvgDcpZlGpnJ4LEa9BlIm2jRZLssYl1YtMxe68BHMwMQTvfQDbFZhhnWebb0+PPHcsLbsSbZMLsBva4G+3+cB+DLWLtuitLJybeAtpeNvy16yD7Jw5miuCDo+uMA= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB3860.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(71200400001)(66446008)(64756008)(52536014)(83380400001)(966005)(66556008)(498600001)(44832011)(33656002)(4326008)(26005)(2906002)(66946007)(186003)(66476007)(76116006)(7696005)(9686003)(53546011)(55016002)(8676002)(86362001)(110136005)(5660300002)(6506007)(8936002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?aNEtlwqRBYSJNxmEGwPsIlr9n5iA1SJfsL/iqDYyMk4QnYiwlUunL0rD7UQk?= =?us-ascii?Q?0j4E/3Wj/IpFfyx0rT5RsOjWrKiHi+ha25MvVvKS7b60onxELOwUwnw5N4VK?= =?us-ascii?Q?jqPZ0msu4N/cx33mA6lTcVY/eFCGkUXICTp3rk42mlEpbuRzg6P04bC94ucJ?= =?us-ascii?Q?rzLQV/8oGb/I03RE09P3TqDFPeiBHCvNEWssEqjTwWxCEqWSM4MYHzbxFFMw?= =?us-ascii?Q?Zd2drVTkUak8RIUd4fHX+i5hB0FHEaBLjfrZzx1QnoxrkbT1KSrBdTKPZ384?= =?us-ascii?Q?Yq4YXKGdMNekHR88nzVfY+KMWn+YqWmAtZj8x8TRLEDvas3of+tD/PKI+Ibz?= =?us-ascii?Q?CnH644W/G+aSZFObeoORlAK0GpOHWfUA9Igc61S+vUGgi8Ekh70yaX8liZi9?= =?us-ascii?Q?BvG0OyMk1lOozDau2GLPs0yh7tSGEBvzFl9QJC5up2LAS8D2NLop7YpWwyl5?= =?us-ascii?Q?5OiJRLp6GZvluNjaqbD4qf9/oPfKIaHEL8SX1DAAyKEpyIkkcrClruF+Nrnd?= =?us-ascii?Q?EbctdGt10DM/uYP8/wpUoarrV4HwZHneZBnF9We4humFZSyvpYVj5k/XZ0sh?= =?us-ascii?Q?p9o9glTidumYqBtgW9vzMtP+q6J/uPYP7eQXD4fRVFwIfbTrsAsntoPjWpjx?= =?us-ascii?Q?76hNeTuvy9+TmT1B6U91lqpEUb9p6zlPioiGZIT6uzeMv5xYK4Z3nCqLei83?= =?us-ascii?Q?fB/5t2KnZuBdiqeHKtRJ2a8zlSfRyLiTVvMzM+9s7hsl3osZDhNJOU14V2Q4?= =?us-ascii?Q?1Vwr5tGstEyXw2PZqbb/z5n+bkAzvfgW8K3s3hHKPmy+I7XPvi7ZDmtG+5t+?= =?us-ascii?Q?2IjTpMKY0xmTgmFUUEpTXro7GsfIpZGu+e8meUuW+Fe3ng2xbmFYiAMZDUi1?= =?us-ascii?Q?CVtp9w+MypiGLja8ovIvXfmiccB8cPuD8pMBDjvr26qQgSNiLKkpReWp3dL0?= =?us-ascii?Q?wafUL32aLGkOFLEx/GUCezBEJOET6WVKMfEfYsf0ESVk0NoOPfQDxpitoUg6?= =?us-ascii?Q?otbRfFGGJ/v9RKX0JaAu4u35ELK/YAylzPyKiaR8EWxOQy/+pOp7hSg88pkp?= =?us-ascii?Q?GM40KLJTuOdQiharTbkiJGE+WK59ctrMQG3n51VDDpptSLVqfvR6vbur42eL?= =?us-ascii?Q?qxoXb5gijxEZHHwiuCLC7ebMToFpcNqX99HRqTZcFHkSUUHDqKB9v03jexxT?= =?us-ascii?Q?MmJMOGGiqUB1A/vPm3uMoZpVLxEUVxBeu02bpFxUWkGdYCR/1GpxL/nFp6Tr?= =?us-ascii?Q?rFWJJcPdmoFeXVZmwcp3r/zkt6EpVZNoMDTbIIE7hDljielKg4jnSVtbYYvD?= =?us-ascii?Q?D72kdXvl5OFFEtHTajDgfMzI?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR07MB3860.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b53c84f5-85b2-4ff5-4075-08d8ccef149d X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2021 11:37:28.7215 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: AyZqvcdN57MvjGIk24fNGb/DbtwsQdnHjLiOSCaAZ1PKwkNDkFmnyenwBeIfA4hX8+i5mMTlMn7akUsBzCDN/UDrAk4JNagIex/7aiTiT2I= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3473 Archived-At: Subject: Re: [dispatch] draft-gruessing-sdp-http - mapping SDP into HTTP structured headers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2021 11:37:33 -0000 Hi, I agree with Adam, that we should first get a wider picture of what you are= trying to do. The draft says: "The Session-Description header MAY be sent at the same time in a response with a HTTP body that also contains the SDP payload for backwards compatibility." Backwards compatibility with what? If there are existing solutions where HT= TP and SDP are used to negotiate media sessions I think it would be good to= reference those, and describe what the issues sending SDP as body content = are in those solutions. Regards, Christer -----Original Message----- From: dispatch On Behalf Of Adam Roach Sent: tiistai 9. helmikuuta 2021 5.44 To: Lucas Pardue Cc: DISPATCH WG Subject: Re: [dispatch] draft-gruessing-sdp-http - mapping SDP into HTTP st= ructured headers On 2/8/2021 6:21 PM, Lucas Pardue wrote: > Given the parsing facets that Adam mentioned, would it be as simple to=20 > just base64-encode the SDP, and stick to reusing off-the-shelf SDP=20 > parsers? That raises the same question about what one might gain from doing so.=20 Would we entertain the notion of encoding images in HTTP header fields?=20 HTML? There's a way this kind of thing is transferred in HTTP, and it's the= message body. Again, before we set off trying to figure out how to put SDP into HTTP head= er fields and who might go about designing how to do so, I think the first = step is understanding the use cases that are driving such a solution. /a _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From nobody Thu Feb 11 14:51:46 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00DDB3A0D8E for ; Thu, 11 Feb 2021 14:51:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTTop6aTtE3k for ; Thu, 11 Feb 2021 14:51:41 -0800 (PST) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D1663A0D8C for ; Thu, 11 Feb 2021 14:51:41 -0800 (PST) Received: by mail-ed1-x52d.google.com with SMTP id s11so8713178edd.5 for ; Thu, 11 Feb 2021 14:51:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=DoGl7lc7f9n2ZdefOUmOlDvOS9Q8e57uoGi0NU1EvzA=; b=OW9LIytCoTn0kPlx3JCImG8Ci42ujbKu6kP7kMzjooE045eRxD07RAMYEDkXJrFQTs tvvACTqmCMoPyRngv05fTt7NzZI2JT9UTU4Tfa+x8j3tiZW94UuQE2rz2NHZZOFUth2m oo9k6UZgZ5gKXGH2TMp1Z+B59V1SK6dwtc0lHvxhufXG+vN7CeCSzlqd0tJsID9gyoWM qid/M6sCxVTceII8p0KQXjVnBRbtMTUgiceuN2LQCArkq2xh1L3B054B0JYDp63HuEL9 O32yp99D5rKFRVkZo8Wsi2+Uo/rBzApU+/gvtFmMLWfT6pmcM+VK+K97Guys0yJ833S5 qAyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=DoGl7lc7f9n2ZdefOUmOlDvOS9Q8e57uoGi0NU1EvzA=; b=F2TsJh+OWSQWwfAossU/SX5lldcJvo4dt4RgET5pywb1SF0kU2hBdlYW/zdxcWop1K WzIdDzZ2W3IcZObiuNbOycQBadVpvl5OoBsvZtVwcusw4elLkcWCXWLeP31uqo5wOVzM oee8GUGl34jMfZkymroICsYjspDUWfE61CkXb5b0feXnaDgcVjO9Boa+EMAH03U7GRwQ OyOFseoIGKHDVWF68a5Vj8XTzjaGs1XxmKFai8/kkKS4pfirOzB/avOvJUYTAWH25d0H Ne6B1OR62RBDR3Qo851Lvp5VGdz6M5cK9z87xNBtjezf7dzrlL/7HU8W0+AVhIp9eJgq KsAQ== X-Gm-Message-State: AOAM532IUYUofzGWofq3cOhineN0As1u98WLOaMxjyNso4GWBa9FdL2Y g3OLo4+P1EiC4Rl+FOwMvdU= X-Google-Smtp-Source: ABdhPJwPOTlnob2y6FlYUU/rGxInkZb63hCcmy0qkFOfKm2AVNckw/+b6NJ6WI/x66dEvpVE0JaZBw== X-Received: by 2002:a05:6402:26c7:: with SMTP id x7mr431589edd.24.1613083899039; Thu, 11 Feb 2021 14:51:39 -0800 (PST) Received: from localhost (80-100-157-193.ip.xs4all.nl. [80.100.157.193]) by smtp.gmail.com with ESMTPSA id u9sm5362761ejc.57.2021.02.11.14.51.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Feb 2021 14:51:38 -0800 (PST) Date: Thu, 11 Feb 2021 22:51:37 +0000 From: James To: Adam Roach Cc: dispatch@ietf.org Message-ID: <20210211225137.3zr563n4gvjrlte5@d8c0c25eea0a> References: <20210208232847.qzfeqmpxeopwtcph@59dc8eeeb793> <05fd6a60-5847-59e3-8ce6-05cb224199b3@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <05fd6a60-5847-59e3-8ce6-05cb224199b3@nostrum.com> Archived-At: Subject: Re: [dispatch] draft-gruessing-sdp-http - mapping SDP into HTTP structured headers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2021 22:51:44 -0000 Thanks for taking the time to read the draft. However after some careful consideration and significant procrastination, I believe I've worked out where my work should go and that is - nowhere. To least provide the basic courtesy of answering your question of further clarification of my use case; where this is already (internally) deployed is on the control plane of broadcast media enccoders where signalling and control is done over HTTP, and where some components (including browsers) understand HTTP wholesale and the SDP data model but not the SDP serialisation format. Having this standardised would help with interop with suppliers and other systems, as well as potentially having broader applicability. In future I'll do a better effort up front of covering the details in my use case (lawyers permitting) and abstain from ever trying to standardise HTTP headers. - J On Mon, Feb 08, 2021 at 06:15:47PM -0600, Adam Roach wrote: > Hi! It's not as much a suggestion for where this should go as it is a > request to understand the use cases involved. I see that there is a desire > to avoid parsing SDP syntax when it is sent in an HTTP context. What I'm > trying to work though is which use cases this might happen in and what is > really gained. > > For the lines that are called out in this initial proposal, parsing is a > pretty straightforward exercise of =, and multi-field values > separated into fields using spaces. This is trivial to code. > > Where SDP's complexity comes into play is parsing the values of "a=" fields, > which vary from attribute type to attribute type, and which will continue to > grow over time as new attributes are defined. This proposal does nothing to > assist in parsing these fields, and any effort to do so will necessarily > require new attributes to take into account HTTP encoding (unless we're just > willing to let the HTTP encoding become out of date as soon as the next > attribute is defined). > > Given the foregoing, I'm scratching my head about which use cases will > legitimately be simplified by encoding SDP as part of HTTP header fields. I > think we really need to understand this before we can figure out who (if > anyone) should work on it. > > (Minor aside: the proposal right now seems to lack any way to encode the > media type, port, profile, and parameters, as well as leaving off "a=" > attributes for media sections.) > > /a > > On 2/8/21 17:28, James wrote: > > Hi Dispatch, > > > > I've written a draft[1] that I'd like your help in finding the right > > place to carry on the work. > > > > This draft solves the problem of having session information about media > > being transmitted over HTTP, so implementations can use existing HTTP > > semantics to represent SDP data models instead of handling SDP's > > serialisation format. > > > > Looking at possible places for this work to go, I've considered: > > * mmusic - HTTP work doesn't appear to fit in here > > * httpapi - This work might be "too specific" for media and out of scope > > * wish - Whilst my use case isn't specific for WISH, it might fit in > > > > I'll be presenting to the working group at IETF 110, but before then any > > feedback you have would be appreciated. > > > > Regards > > > > - J > > > > 1: https://datatracker.ietf.org/doc/draft-gruessing-sdp-http/ > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > From nobody Fri Feb 12 12:31:00 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC0D53A0E07 for ; Fri, 12 Feb 2021 12:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.621 X-Spam-Level: X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yandex.ru Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kTHiY5j9ulR for ; Fri, 12 Feb 2021 12:30:57 -0800 (PST) Received: from forward105j.mail.yandex.net (forward105j.mail.yandex.net [5.45.198.248]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B6473A0E04 for ; Fri, 12 Feb 2021 12:30:57 -0800 (PST) Received: from iva8-6377ea28ef3a.qloud-c.yandex.net (iva8-6377ea28ef3a.qloud-c.yandex.net [IPv6:2a02:6b8:c0c:6f19:0:640:6377:ea28]) by forward105j.mail.yandex.net (Yandex) with ESMTP id 0B5E0B210CB; Fri, 12 Feb 2021 23:30:55 +0300 (MSK) Received: from localhost (localhost [::1]) by iva8-6377ea28ef3a.qloud-c.yandex.net (mxback/Yandex) with ESMTP id XxAlco4vMi-UsIaYsr6; Fri, 12 Feb 2021 23:30:54 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1613161854; bh=AwusVgl/PLcAkWfdi8i7vpRezRO1rdUWsIr9Xe0Y21w=; h=Message-Id:Date:Cc:Subject:To:From; b=cnptwbmYbQUm2+YDnaR8QBUWXe5ZXVC/i/RjIBbjiOCSxChaAIlmRtfh5pE9gb0C+ xUhZrhK+bnym58z/x0WD903mh1U0EEHml3CIS5XhyZ/Pw6ZpfS+Xh77PHl6f5eV8YR 8s3F+QSGTOqh8hT2IpOteL7BQGn18X/0UYqwnotk= Authentication-Results: iva8-6377ea28ef3a.qloud-c.yandex.net; dkim=pass header.i=@yandex.ru Received: by iva3-64eac1bc5e68.qloud-c.yandex.net with HTTP; Fri, 12 Feb 2021 23:30:54 +0300 From: Anton Tveretin To: James Cc: DISPATCH list MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Sat, 13 Feb 2021 01:30:54 +0500 Message-Id: <226391613160464@mail.yandex.ru> Content-Transfer-Encoding: 7bit Content-Type: text/html Archived-At: Subject: Re: [dispatch] draft-gruessing-sdp-http X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 20:30:59 -0000
Hello James,
First of all, I do not see the idea of the same SDP for all applications (telephony/TV/VCR). In each case, some parameters are useless (I believe that t= and r= are TV-specific). Who at least thinks of v=1? PrSD focuses on telephony. What about your draft?
Second, I indeed find a= abused.
To be continued...
Best regards,
Anton.
From nobody Fri Feb 12 16:37:13 2021 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2360C3A1219; Fri, 12 Feb 2021 16:33:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: barryleiba@computer.org, dispatch@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161317641012.31337.17940051721662137452@ietfa.amsl.com> Date: Fri, 12 Feb 2021 16:33:30 -0800 Archived-At: Subject: [dispatch] dispatch - Requested session has been scheduled for IETF 110 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2021 00:33:38 -0000 Dear Kirsty P, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dispatch Session 1 (2:00 requested) Monday, 8 March 2021, Session I 1300-1500 Room Name: Room 1 size: 501 --------------------------------------------- Special Note: Joint with ARTAREA iCalendar: https://datatracker.ietf.org/meeting/110/sessions/dispatch.ics Request Information: --------------------------------------------------------- Working Group Name: Dispatch Area Name: Applications and Real-Time Area Session Requester: Kirsty P Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: Chair Conflict: rum stir sipcore mmusic ecrit avtcore cfrg quic httpbis add Technology Overlap: perc cellar dmarc jmap uta rmcat extra core opsarea tsvarea tsvwg tram secdispatch emailcore asdf sframe jsonpath webtrans regext cbor calext httpapi Key Participant Conflict: acme cose dprive lamps tls mls People who must be present: Barry Leiba Kirsty P Murray Kucherawy Patrick McManus Resources Requested: Special Requests: Please schedule in the 1st slot Monday morning, and list as coupled with ARTAREA. Please avoid conflicts with other ART area WGs and BoFs, other area meetings, other dispatch groups, and BoFs. --------------------------------------------------------- From nobody Tue Feb 16 07:36:36 2021 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2183D3A0FBF for ; Tue, 16 Feb 2021 07:36:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161348979512.24840.15926478426165582468@ietfa.amsl.com> Date: Tue, 16 Feb 2021 07:36:35 -0800 From: IETF Secretariat Archived-At: Subject: [dispatch] Milestones changed for dispatch WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2021 15:36:35 -0000 Deleted milestone "EMCAscript Media Type Updates to IESG for publication as Informational". URL: https://datatracker.ietf.org/wg/dispatch/about/ From nobody Thu Feb 18 20:20:34 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB5E3A0D78 for ; Thu, 18 Feb 2021 20:20:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=jpfMfupr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=v8qksjYe Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzOmwisGY6yi for ; Thu, 18 Feb 2021 20:20:30 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DFC63A0D76 for ; Thu, 18 Feb 2021 20:20:30 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id AE1615C00B4; Thu, 18 Feb 2021 23:20:29 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Thu, 18 Feb 2021 23:20:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:cc :subject:content-type; s=fm2; bh=gk+oOfaSTF4feO1w+XTXqP/7LxLtM3f lkOAyS7IaUhc=; b=jpfMfupr3I5NcorETXui/OkHgxlHgO2+O6/q0CwfWgGYgFU kkUIlVWZJXfK42klv0aXXo1/A+xcPRAybo+gRSWxaraeez6LzlryFspsR8wZha90 kCuxonC6mA28rIfGZJBbx+Fibj42Fh8GUh8PyojnH2LUjfUW1WfQK+F2p60sJc0Q WPibM4ppkNP8hNzq1T3c1xPpQnPyBbcGemVo54xipRdLsTUuvIPZm9uwKALBF0ij RPg+6TdtHq0lnWOidsM29WTv6K5SDn3+ir7oy8DOFV6jMqgXATAQt606MBfYgdpW /aahSYJo6I+1R64vNKKdYudGKYolHp9qXDaOCKQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=gk+oOfaSTF4feO1w+XTXqP/7LxLtM 3flkOAyS7IaUhc=; b=v8qksjYeycd9Gd8nMIdch6TGfNcgCAr9j1V8b5Xd6KXXZ Sqi+Gdqr8ZdGUQBxCdyhHssjkQMRPr5y+VAujAvqJim17AUN6sEU7ZYtDU+0jmMg qouu3r9ZlCm/u2mLQcBIOgb9gByA7x2jcVz+UKYznOKL6ymf3gOoXOyqSWN5Bq37 5S+KHpwpu8yqScBTkQH3HxSEM2CIaeIsR8yc+lpywkxUznvMNYIt9GR9sLS3evRO lNLaXxOlhRvyb5hot8VVOWarxVEywslQvwQjqNN5k3euDgsYY6bKpz1qZ8vFQyKf UxyosVPaImWhOvnG6Uk80UsayEl5SslF891rJKnng== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrjeehgdeilecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfffhffvufgtsegrtderreerredtnecuhfhrohhmpedfuehrohhnucfi ohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmqeenuc ggtffrrghtthgvrhhnpefhjeehkeejkeehveeutdejteeihffffeduiedttdejhfelteev ueehudeltdeuffenucffohhmrghinhepihgvthhfrdhorhhgnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhl thgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 10A1536005C; Thu, 18 Feb 2021 23:20:29 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-141-gf094924a34-fm-20210210.001-gf094924a Mime-Version: 1.0 Message-Id: Date: Fri, 19 Feb 2021 15:20:08 +1100 From: "Bron Gondwana" To: dispatch@ietf.org Cc: "Ujjwal Sharma" , "Shane Carr" Content-Type: multipart/alternative; boundary=15fbc2ced37e4e9094ff73bb7b6ceeaf Archived-At: Subject: [dispatch] Proposed charter for extended date format X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2021 04:20:33 -0000 --15fbc2ced37e4e9094ff73bb7b6ceeaf Content-Type: text/plain I've asked the chairs for space on the next dispatch agenda to talk about dispatch for https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-extended/ The authors have taken on board the idea that we should extract the "obsolete RFC3339" and either remove it entirely, or separate it into a document which does nothing but update RFC3339 with support for a wider range of year values. There will be an updated version of this draft soon. The dispatch chairs also asked me for some proposed charter text if we were to spin up a working group for this topic. Here's that text. Cheers, Bron. Serialising Extended Data About Times and Events (SEDATE) ---- RFC3339 defines a format that can reliably express an instant in time, either in UTC or in a local time along with the offset against UTC, however datetime data often has additional context, such as the timezone or calendar system that was in use when that instant was recorded. Particularly when using times for interval, recurrence, or offset calculations, it's necessary to know the context in which the timepoint exists. It is valuable to have a serialisation format which retains this context and can reliably round-trip the additional context to systems which understand it, via intermediate systems which only need to know about the instant in time. The TC39 working group at ECMA have developed a format which is a good basis for this work. It is anticipated that this document would be a companion to RFC3339 rather than a replacement, embedding an un-altered RFC3339 instant along with the contextual data. It is also within scope for this group to consider a minor update to RFC3339 to allow larger than 4 digit signed years, to enable representing times further into the past and future. Once this work is done it is anticipated that this working group will be short-lived, and once the one or two documents are published the working group will close down. Milestones: * April 2021: Adopt draft describing a serialisation format for extended datetimes. * July 2021: Submit the serialisation document to the IESG. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --15fbc2ced37e4e9094ff73bb7b6ceeaf Content-Type: text/html Content-Transfer-Encoding: quoted-printable
I've asked the chairs for space on the next dispatch agend= a to talk about dispatch for
=

The aut= hors have taken on board the idea that we should extract the "obsolete R= FC3339" and either remove it entirely, or separate it into a document wh= ich does nothing but update RFC3339 with support for a wider range of ye= ar values.  There will be an updated version of this draft soon.

The dispatch chairs also asked me for some proposed charter= text if we were to spin up a working group for this topic.  Here's= that text.

Cheers,

Bron.

Serialising Extended Data About Times an= d Events (SEDATE)
----

= RFC3339 defines a format that can reliably express an instant= in time, either in UTC or in a local time along with the offset against UTC, however dateti= me data often has additional context, such as the timezone or calendar system th= at was in use when that instant was recorded. Particularly when using times for i= nterval, recurrence, or offset calculations, it's necessary to know the context i= n which the timepoint exists.

It is valuable to have a serialisation format which = retains this context and can reliably round-trip the additional context to systems which understand i= t, via intermediate systems which only need to know about the instant in time.<= /span>

The= TC39 working group at ECMA have developed a format which is a good basi= s for this work.

It is anticipated that this document would be a companion to RF= C3339 rather than a replacement, embedding an un-altered RFC3339 instant along= with the contextual data.

It is also within scope for this group to consi= der a minor update to RFC3339 to allow larger than 4 digit signed years, to enable representing times fur= ther into the past and future.

Once this work is done it is anticipated that this wo= rking group will be short-lived, and once the one or two documents are p= ublished the working group will close down.
=

Milestones:
* April 20= 21: Adopt draft describing a serialisation format for extended datetimes= .
* July 20= 21: Submit the serialisation document to the IESG.

--
  Bron = Gondwana, CEO, Fastmail Pty Ltd
 = brong@fastmailteam.com


--15fbc2ced37e4e9094ff73bb7b6ceeaf-- From nobody Fri Feb 19 08:31:08 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443CD3A1105 for ; Fri, 19 Feb 2021 08:31:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVgAUIK_6VN6 for ; Fri, 19 Feb 2021 08:31:02 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91DA83A110F for ; Fri, 19 Feb 2021 08:31:02 -0800 (PST) Received: from [192.168.217.118] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4DhxsJ5QgpzyTH; Fri, 19 Feb 2021 17:31:00 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 635445060.312825-ffd18e3da51b218d919df293b6567e73 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 19 Feb 2021 17:31:00 +0100 Message-Id: <0DA2C70A-AF06-4629-BA3C-D22F942526AE@tzi.org> To: dispatch@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [dispatch] draft-bormann-core-media-content-type-format X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2021 16:31:06 -0000 In the CoRE working group, we noticed that we were stumbling over = terminology around media-types, content-types, content-codings, = content-formats (a CoAP term), etc.; essentially creating rather = imprecise documents as a result. We also noted that we needed some ABNF that we can import into = specifications such as draft-ietf-core-senml-data-ct [1]. So at some point we broke down and wrote it up: = https://datatracker.ietf.org/doc/draft-bormann-core-media-content-type-for= mat/ But the CoRE WG cannot really adopt this document on its own, as (most = of) these are not CoRE terms, and the CoRE WG is not chartered to fix up = IETF-wide terminology (and ABNF). I would like to bring this document up at the IETF110 meeting, and would = welcome a list discussion here leading up to that. Gr=C3=BC=C3=9Fe, Carsten [1]: https://datatracker.ietf.org/doc/draft-ietf-core-senml-data-ct/ From nobody Sat Feb 20 14:14:54 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1841B3A0E95 for ; Sat, 20 Feb 2021 14:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0arfvS3FZPvA for ; Sat, 20 Feb 2021 14:14:49 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45BFF3A0E94 for ; Sat, 20 Feb 2021 14:14:48 -0800 (PST) Received: from [192.168.217.118] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4DjjRV6TJ5zyd3; Sat, 20 Feb 2021 23:14:46 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: Date: Sat, 20 Feb 2021 23:14:46 +0100 Cc: dispatch@ietf.org, Ujjwal Sharma , Shane Carr X-Mao-Original-Outgoing-Id: 635552086.302768-6a5724c5d53ff90f21cdda179a8e5b64 Content-Transfer-Encoding: quoted-printable Message-Id: <512F250C-DE04-4F31-BD1E-5B283B058D14@tzi.org> References: To: Bron Gondwana X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [dispatch] Proposed charter for extended date format X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2021 22:14:52 -0000 On 2021-02-19, at 05:20, Bron Gondwana wrote: >=20 > The TC39 working group at ECMA have developed a format which is a good = basis for this work. I assume you are talking about: https://tc39.es/proposal-temporal/docs/iso-string-ext.html What is the stage of this proposal? (Re the draft: It is weird to end on a leap second table that stops in = 1998. Not many have happened since, but the omission is jarring. Also, = ISO 8601 has evolved since 1988, now as a two-part standard etc. Even = the IETF has done some work, e.g., see RFC 7164.) Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Feb 22 11:25:03 2021 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9F23A1E3F; Mon, 22 Feb 2021 11:24:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dispatch@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.26.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dispatch@ietf.org Message-ID: <161402189826.5209.1738972714044519921@ietfa.amsl.com> Date: Mon, 22 Feb 2021 11:24:58 -0800 Archived-At: Subject: [dispatch] I-D Action: draft-ietf-dispatch-javascript-mjs-08.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2021 19:24:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dispatch WG of the IETF. Title : ECMAScript Media Types Updates Authors : Matthew A. Miller Myles Borins Mathias Bynens Bradley Farias Filename : draft-ietf-dispatch-javascript-mjs-08.txt Pages : 27 Date : 2021-02-22 Abstract: This document updates the ECMAScript media types, replacing the existing registrations for "application/javascript" and "text/ javascript" with information and requirements aligned with implementation experiences. This document obsoletes RFC4329, "Scripting Media Types". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dispatch-javascript-mjs-08 https://datatracker.ietf.org/doc/html/draft-ietf-dispatch-javascript-mjs-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dispatch-javascript-mjs-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 25 06:43:23 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275103A1AC3; Thu, 25 Feb 2021 06:43:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.671 X-Spam-Level: X-Spam-Status: No, score=-2.671 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.57, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ncsc.gov.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ljie-H20kzQr; Thu, 25 Feb 2021 06:43:19 -0800 (PST) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100138.outbound.protection.outlook.com [40.107.10.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E65563A1ACC; Thu, 25 Feb 2021 06:43:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZiM3MuKrocisiKFIQTnZNWqvC8cFW0FWQ2Fxjb73VpMMl23UcOoIQAMK9w2OioUQb6R0WbdIl9Vao3CCpfgV8EiRZdSECw0PTiIfmeWb53PUCYtKrlv83zgvLPfQVFlPFvWeXl4X7uQUxGfghqwfG4IDsOnjtlfN/SSuqgqvJ69v1ipIpJiu//Fjsz2rYdDl5t+E6Nr27EakAWYknIbJ5RpW18L8/iWvrpI1ej7hyCHXjr4ZWDBqhZr59Ur6wHY/fETeF2eFC2Cu0x4Kw09qA1oWtISFTJvPcoU0osh/dOO/KOSlBzIW5eVAWQ0yaAoKJuto6h4yMG8mQKCsqCHVEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vEicQ+HADIol9KzbfpuOqwEDeduHf37DrKZIBVwjSv4=; b=PvmDju2TMBbxX1H7K4BJDNj1lzTKHfSfLtX+wgLzED1nWaXt7JrkD3ksPraps5eeAEvgbM/+NjHJI/y9tMmLPAqc/nbhmXXkMJdpGthQWmW9GGwQyXEUiJdH4KGJEV213932WC88hfjIcC3+rEDlSdJRQTsXswN2cjIQAnPHBXd2VWYOq9xXsHk7kLV8hz6l/L++BKMkiycG2zRrxPGOFIPtNhlmaim2ZVUSNV0SjiDqAhuQ6hDO7LrNoR7JLsSmy7HHPT7OZHFnV+Dm1yPScB5Ja3VmG03Ifq2pKmolKhAeEVwRhkFSKyVYXju71KCQkcgRxRygU0VqJ7ZzggJxTQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ncsc.gov.uk; dmarc=pass action=none header.from=ncsc.gov.uk; dkim=pass header.d=ncsc.gov.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vEicQ+HADIol9KzbfpuOqwEDeduHf37DrKZIBVwjSv4=; b=Eq5erQBl7EPZwXONx5kMJvXEUt278oAHb+jfXoEbdxjqXsPXU4w28DFThbS4lJ9sGEDjS4nFE+EIVuRBkNZ4d2eeez/I66gqVLJW1myECgcobzdZwYqMaRMm+4VQElo8qHWHxKzhnbYwqQYS/RnCEGLq+qYIBVd/scrqKzbgcxhtDLHPbKvqKSBAFULRwZ85SJoZR2062uDAGye8VgBbncjz4RQbIibWlRIMZuzgJ2EUsBKwavZVD32MymXj1gHt5kW6SSY6O7+WLPv3fx3/r4z63BYPz2fGURyAu/VAINIJ4kstHEBJrRkIkcGYS9FG/7kDZ2TpUBf+0d940ZgiZw== Received: from LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:12c::10) by LO2P123MB4649.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1c7::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.31; Thu, 25 Feb 2021 14:43:14 +0000 Received: from LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM ([fe80::49b6:9d28:3e21:7045]) by LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM ([fe80::49b6:9d28:3e21:7045%7]) with mapi id 15.20.3868.034; Thu, 25 Feb 2021 14:43:14 +0000 From: Kirsty P To: "dispatch@ietf.org" CC: dispatch chairs Thread-Topic: IETF 110 DISPATCH Draft Agenda Thread-Index: AQHXC4PmW33ZuxFGgkO3HIlVRJNdaw== Date: Thu, 25 Feb 2021 14:43:14 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ncsc.gov.uk; x-originating-ip: [20.49.216.121] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cba5a7ad-21ec-406b-890c-08d8d99bae5b x-ms-traffictypediagnostic: LO2P123MB4649: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: d1S+9GqpiGtFSrS0ySDUVRy0omd1I5BXRBQu8vaQiCxfkT7WhT49ctgxcZZvaKXHLZPkkgRtEdF0L3rJ3IcqnY0zhXRsKVLYc15/5Ix1jHt/L++S2sohh9/gvcgJJv8amiiITvwGSgbDjiHluuhVH8Ce+PU7tVwvLM8PLCKgAssO/Q5/U/Ddm/6ddI2iijq3dCZKdy5doT7dzJ1eE5E2OBb9FYDCWzgNUBeluBM5xiKGbDlY4WY3Y3TkeNYGAUaNYf7JTJsB1OEyFIapdl2prJqc/BZq649005mXQAOSERuwwpHEriJBbVtLXXaYap6Q2mnd7LTjbz/27i0NwxoodQYlLFfpy30Y2dmcL+CLUsHywaL1ZD5MIx9MRJOYEkIokwzDSAHjMsE/Na3Me2AyM92aBcezBz0kIyL4l0lzggVyrff5lbbtsXEqL00t/uiwhv0ld6jWy9Vzp2wKtF5TIXzuChKRUIwmMBygR1rzAm41Gq1K7Va+o8bCjmbnlB1hXisgHIgcmsy59VfL8aTSeMqeMnrMz+hbsOFDWfaAaeKUZ6Tog8gGJ6mVANI2xcCvFna0g/xqaeqE/dLrwNyErtU0l8TU5u/O+U2EFAmQt3Q= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(366004)(136003)(396003)(346002)(376002)(2906002)(6916009)(83380400001)(55016002)(19627405001)(8676002)(478600001)(4744005)(966005)(450100002)(26005)(76116006)(71200400001)(66476007)(186003)(5660300002)(8936002)(66556008)(66946007)(64756008)(316002)(33656002)(4326008)(6506007)(86362001)(7696005)(66446008)(9686003)(52536014); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?kczKuVhwtfKhA4erGPloxa5eEuHO+J+nsrZI5Hy62aQgqyVNEv9R2TC5Tq?= =?iso-8859-1?Q?mpYwHaP9xzfoKdyzdfenXO2vwqx0icnCeMwrPcJCzJCkCiietluk22UIyE?= =?iso-8859-1?Q?g6EpaFzS1syr6DA0EIT69f3nVKKQpELoRiExgE8Jkw1zz9Ss2H3FUf1kaW?= =?iso-8859-1?Q?rl5PirHRHN5vWx+8TWsi7CE8WmtexGFgQemR+zHXkkrKmwNwGzFFHrNsvH?= =?iso-8859-1?Q?87VYEB1nFRbpgCKTXZcDi6mTvi61+fwcWi6Sa8b3Mk4FIz1SHW4YcZu38i?= =?iso-8859-1?Q?MQGrusxZnQ4k2vTVuP41dvIHOEqEKRFJXPlinz0QEvwKXOBYEBiIsw0ly+?= =?iso-8859-1?Q?k8JC/gR2AepySKQHfMxgYrNycLjnrjPeAN264IC9uBmo9A9K2yCgpR+5Rl?= =?iso-8859-1?Q?YAUIcplQ0AWGO2r5aj8VJoovoZBdVR5cHXPKXUyR8wL4/kUblHEOOIDuP0?= =?iso-8859-1?Q?CDDC2R3mScASSY1Duf33sS2olEaCjiYy6sAPmI1DwBmuC8PahMO65oHXyK?= =?iso-8859-1?Q?xSkpBVPRB5Kpvn0JCUCLtzMR1qktCpEogX5hSVQFHec/0fqANj+3S/fLGp?= =?iso-8859-1?Q?jWiTaFNCg9abLmZtLS2OVG05QT5v7cnWE1gqYNwuXHGYP0iXMyBjHzdxKY?= =?iso-8859-1?Q?f0Ae6wybei4bvYR49XcNwTcEXSDbbEd6TIqMh4KSjFcaWtjO3b/7WYsxkl?= =?iso-8859-1?Q?k1ndl6v8EkVWMhldvCjRb05HK/bQubcPpNhieGeNISHSpGC+8LGI2q/cfl?= =?iso-8859-1?Q?fvlMQg0eCodAIGnP1WYNgFrWYe9iPsLZlDM/MVbaIFQTtSyBr3oX8EdnwT?= =?iso-8859-1?Q?x+HCGFvN8ELFHmk27/Q8iCMUAggn1exQvrr9DjvdnzqtlfD+KonpTHIBjQ?= =?iso-8859-1?Q?KHoCg4d7ja1S8zUgYzG+5yAUhtdsZFxul93Qy3rUm06PbMvUKjdA45xq2g?= =?iso-8859-1?Q?dU7xi8CmH/HtNWEKeOYQ8hHNvRQ3xo+faUlBRqMplHdXDZRoqEtPh9QxZI?= =?iso-8859-1?Q?CiUarK/oQOf62V7BcE7mb22yeqd+xaD5wfsEE0BoC+emH1CPLA38ay935R?= =?iso-8859-1?Q?UTFfkmhdWKoFRafaR6IbEiWWU/CCJ8ewrOdtxTwhDjCh2AeEZ0dp7dyYKs?= =?iso-8859-1?Q?fThj1J6fNdVLdAH+dvAZnD8m06jHPEfsTmckPnQ3jbrls+7aO+UY8J3PVs?= =?iso-8859-1?Q?1Sb9rEtX2+7eE6GY+TfFHnLKNKgsP877G6q7+7H9cYsfEFtsMLRkLGELM3?= =?iso-8859-1?Q?AyZ1nTT/sNxXQm3XCi0lxJJBsHJnNiSSkvQFtNseLwdV+AGhFx5SlKdbck?= =?iso-8859-1?Q?1r8PqLXyjkTlSq4CSVdB8JpEyRiSqIGlmSu4DlAPt6tTUJIdGjI8/6sW2i?= =?iso-8859-1?Q?J2SUegE/vF?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LO2P123MB3599D4E098590BDEB66E23E9D79E9LO2P123MB3599GBRP_" MIME-Version: 1.0 X-OriginatorOrg: ncsc.gov.uk X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LO2P123MB3599.GBRP123.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: cba5a7ad-21ec-406b-890c-08d8d99bae5b X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2021 14:43:14.0431 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: I/vl01t4dwPuZ/IT8BUGhyUGLsu9bon9yLUuXW0fv3fhiPGQhJg66x5uoAjCPw0z2VMHrJ1lDXgZhiUF9lqo1Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P123MB4649 Archived-At: Subject: [dispatch] IETF 110 DISPATCH Draft Agenda X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2021 14:43:21 -0000 --_000_LO2P123MB3599D4E098590BDEB66E23E9D79E9LO2P123MB3599GBRP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi dispatchers, Our draft agenda for IETF 110 is now up - please let the chairs know of any= corrections or omissions: https://datatracker.ietf.org/meeting/110/materials/agenda-110-dispatch-00.t= xt We'll update the list if it's updated, but if you want to check for your ow= n peace of mind, you can always find the latest agenda at: https://datatrac= ker.ietf.org/doc/agenda-110-dispatch/ Kirsty & Patrick This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =A9 --_000_LO2P123MB3599D4E098590BDEB66E23E9D79E9LO2P123MB3599GBRP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi dispatchers,

Our draft agenda for IETF 110 is now up - please let the chairs know of any= corrections or omissions:
https://datatracker.ietf.org/meeting/110/materials/agenda-110-dispatch-00.t= xt

We'll update the list if it's updated, but if you want to check for your ow= n peace of mind, you can always find the latest agenda at: https://dat= atracker.ietf.org/doc/agenda-110-dispatch/

Kirsty & Patrick
This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk. All material is UK Crown Copyright =A9 --_000_LO2P123MB3599D4E098590BDEB66E23E9D79E9LO2P123MB3599GBRP_-- From nobody Thu Feb 25 08:17:49 2021 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1363A1D36 for ; Thu, 25 Feb 2021 08:17:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uhasselt.be Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YGrQmt5YrNU for ; Thu, 25 Feb 2021 08:17:38 -0800 (PST) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 750FC3A1D07 for ; Thu, 25 Feb 2021 08:17:23 -0800 (PST) Received: by mail-wr1-x42e.google.com with SMTP id r3so5800442wro.9 for ; Thu, 25 Feb 2021 08:17:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uhasselt.be; s=google; h=mime-version:from:date:message-id:subject:to; bh=q05YeCu0npdmdfoCb06sre4gsWBtXEFoyv9murHplQA=; b=Qam3F2SZp5RvM+0Oc6hnSvt6D7LIOKQyD5xSNTrSQDP6myD8Y3likNfajf1b/HT2SQ oskdWusrSqXnsoAHvvc+Y7XZXfOnJKMTu5trq15CThzQvn1bQ022nj7w3it4rVeCYkUY ZIDcWQiWUt9/rrK75Xmdx0CYQtDT0ViV62yak= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=q05YeCu0npdmdfoCb06sre4gsWBtXEFoyv9murHplQA=; b=hob+X83M1BBLCZOtnBWXS1DHiI80UfL14o6VV+TkI5tsOLJhX5VI0IgYQetNix/QPw Fj5pIOCZrGSjzwafGkBssYHoOamaMXHfTKKyE+30TlBZcIRRc58yMhHyWOFJ9pJnCzNz aaJ5h7DKYkcwyxkjpBGdiWNBz2jaCvR2G1VSFmPUL90icLnrRj9TM9Zyaqsmp25lsUr1 wxYm2/xZ+6TItP7ygr9yDVP7rwwgqEyUehhoAl7Bu2IJBLktd+KC7bx33NVsDG2i+0rC EkQ32LhsmZW2Zy78HdSFGb8amtsf964VsV/PE7PnyP3DFAhSfjdWaNVm0zhYflwE2R7K rCQA== X-Gm-Message-State: AOAM533PaBQd8zDkFhNqaNbKLCF2gRPW0Imt3XldzeV+sDF7vl6kp1Bn 5qWzwUk+Y6eVhl+lqOZ9TQaL2PTa4WBW3iMZGiG7fNdYyXY/Yg== X-Google-Smtp-Source: ABdhPJyrhZMrS2SzheW11L9yURyGQHqeqT54XCdNOt46lAXPYOCJ81uAicvEecLgvxSdYqEXFHVduoeqNyKcTJB/Qk0= X-Received: by 2002:adf:f750:: with SMTP id z16mr4393389wrp.108.1614269842213; Thu, 25 Feb 2021 08:17:22 -0800 (PST) MIME-Version: 1.0 From: Robin MARX Date: Thu, 25 Feb 2021 17:17:10 +0100 Message-ID: To: dispatch@ietf.org Content-Type: multipart/alternative; boundary="00000000000084633c05bc2b7c54" Archived-At: Subject: [dispatch] Introduction to qlog X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2021 16:17:47 -0000 --00000000000084633c05bc2b7c54 Content-Type: text/plain; charset="UTF-8" Hello Dispatch, In two weeks I have a slot during the meeting to talk with you about the qlog project. Since this is the first time this is discussed in this wg, your chairs asked me to do a small introduction via the mailing list in preparation. qlog [1][2] started off as a way to do logging for HTTP/3 and QUIC (hence Quic LOGging). As QUIC encrypts almost all of its metadata, utilizing packet captures for analysis almost always requires full decryption of application (user) data as well, leading to potential scalability and especially privacy issues. As such, qlog instead proposes logging protocol metadata at the "endpoints"/implementations directly (e.g., client, server, load balancer, ...), where only the necessary (and properly anonymized) metadata can be recorded. This approach additionally allows the inclusion of events typically not seen on the wire, such as congestion control behaviour. All events are recorded in a structured format (currently JSON) using a fixed schema to make it easier to write cross-implementation tooling. This approach has since found some success for QUIC and HTTP/3, with the majority of implementations supporting the format [3] (or something similar) and actively using its associated qvis tooling [4] to debug and analyse implementations and deployments. As such, the qlog drafts are on track to be adopted by the QUIC wg following their re-charter after delivering QUIC v1 in the coming months. However, it is clear that qlog's basic principles (mainly: structured logging at endpoints) can be useful for many other (encrypted) protocols besides QUIC and HTTP/3 as well. As such, while for practical reasons the continued qlog work will happen in the QUIC wg, the goal is to define it as a protocol-agnostic framework, complete with guidelines to add event definitions for new protocols. This can already be seen in the current split in two drafts: the first defines a general-purpose schema with the format and high-level metadata [1], while the QUIC and HTTP/3-specific events are in the second document [2]. The idea would be to have different documents for additional protocols added in the future. In order to make sure qlog can indeed eventually be used as a substrate for many different protocols and use cases, we are now already soliciting feedback and insights from the wider IETF community. My presentation on qlog in two weeks will give a bit more details on qlog, how it has been used in practice and about the main open challenges we hope you can help us with. It will hopefully also entice some of you to join the later discussions in the QUIC wg as well, of course ;) See you all in two weeks! With best regards, Robin [1]: https://datatracker.ietf.org/doc/draft-marx-qlog-main-schema/ [2]: https://datatracker.ietf.org/doc/draft-marx-qlog-event-definitions-quic-h3/ [3]: https://qlog.edm.uhasselt.be/anrw/files/DebuggingQUICWithQlog_Marx_final_21jun2020.pdf [4]: https://qvis.quictools.info -- dr. Robin Marx Postdoc researcher - Web protocols Expertise centre for Digital Media T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94 www.uhasselt.be Universiteit Hasselt - Campus Diepenbeek Agoralaan Gebouw D - B-3590 Diepenbeek Kantoor EDM-2.05 --00000000000084633c05bc2b7c54 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Dispatch,

In two weeks I have a s= lot during the meeting to talk with you about the qlog project.=C2=A0
=
Since this is the first time this is discussed in this wg, your chairs= asked me to do a small introduction via the mailing list in preparation.

qlog [1][2] started off as a way to do logging for = HTTP/3 and QUIC (hence Quic LOGging).
As QUIC encrypts almost all= of its metadata, utilizing packet captures for analysis almost always requ= ires full decryption of application (user) data as well, leading to potenti= al scalability and especially privacy issues.=C2=A0

As such, qlog instead proposes logging protocol metadata at the "end= points"/implementations directly (e.g., client, server, load balancer,= ...), where only the necessary (and properly anonymized)=C2=A0metadata can= be recorded.=C2=A0
This approach additionally allows the inclusi= on of events typically not seen on the wire, such as congestion control beh= aviour.=C2=A0
All events are recorded in a structured format (cur= rently JSON) using a fixed schema to make it easier to write cross-implemen= tation tooling.=C2=A0

This approach has since foun= d some success for QUIC and HTTP/3, with the majority of implementations su= pporting the format [3] (or something similar) and actively using its assoc= iated qvis tooling [4] to debug and analyse implementations and deployments= .
As such, the=C2=A0qlog drafts are on track to be adopted by the= QUIC wg following their re-charter after delivering QUIC v1 in the coming = months.=C2=A0

However, it is clear that qlog's= =C2=A0basic principles (mainly: structured logging at endpoints) can be use= ful for many other (encrypted) protocols besides QUIC and HTTP/3 as well.= =C2=A0
As such, while for practical reasons the continued qlog wo= rk will happen in the QUIC wg, the goal is to define it as a protocol-agnos= tic framework, complete with guidelines to add event definitions for new pr= otocols.
This can already be seen in the current split in two dra= fts: the first defines a general-purpose schema with the format and high-le= vel metadata [1], while the QUIC and HTTP/3-specific events are in the seco= nd document [2].=C2=A0
The idea would be to have different docume= nts for additional protocols added in the future.=C2=A0

In order to make sure qlog can indeed eventually be used as a substra= te for many different protocols and use cases, we are now already solicitin= g=C2=A0feedback and insights from the wider IETF community.
My pr= esentation on qlog in two weeks will give a bit more details on qlog, how i= t has been used in practice and about the main open challenges we hope you = can help us with.=C2=A0
It will hopefully also entice some of you= to join the later discussions in the QUIC wg as well, of course ;)=C2=A0

See you all in two weeks!
With best regar= ds,
Robin

[1]: https://datatracker.ietf.org/do= c/draft-marx-qlog-main-schema/
[2]: https://datatracker= .ietf.org/doc/draft-marx-qlog-event-definitions-quic-h3/
[3]:=C2=A0= https://qlog.edm.uhasselt.be/anrw/files/DebuggingQU= ICWithQlog_Marx_final_21jun2020.pdf
[4]: https://qvis.quictools.info

--
<= div dir=3D"ltr">

= <= td>=C2=A0=
dr. Robin= =C2=A0Marx
Postdoc researcher - Web protocols
Expertise centre for Digital Media
= T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94
=C2=A0
www.uhasselt.be
Universiteit Hasse= lt - Campus Diepenbeek
Agoralaan Gebouw D - B-3590 Diepenbeek
Kantoor=C2=A0EDM-2.05
=C2=A0
3D""
--00000000000084633c05bc2b7c54--