On Thu, May 20, 2021 at 1:56 AM Viktor Dukhovni
wrote:
> On Wed, May 19, 2021 at 10:29:43PM +, Salz, Rich wrote:
>
> > I support limiting it.
>
> I concur. These are not strings used between users to communicate in
> their native language. They are machine-to-machine protocol
> identifiers,
For better or worse, these identifiers are being used in places outside the TLS
handshake -- for example, in HTTP header fields, as Erik mentioned. That brings
the encoding / conversion concerns he mentioned. It would be simpler (and
likely safer) to only allow ASCII strings in those uses (at le
Look at RFC 701, it says: the precise set of octet values that identifies the
protocol. This could be the UTF-8 encoding of the protocol name.
So I changed my mind and think it's okay to leave as-is but wouldn't mind if it
became less general or more specific. For example, what if a protocol str
On Thu, May 20, 2021 at 6:30 AM Salz, Rich wrote:
> Look at RFC 701, it says: the precise set of octet values that identifies
> the protocol. This could be the UTF-8 encoding of the protocol name.
>
> So I changed my mind and think it's okay to leave as-is but wouldn't mind
> if it became less ge
SVCB's syntax would need us to not only exclude non-ASCII characters but
also avoid random delimiters like commas, right? I think that's going a bit
too far. As Ryan notes, complex definitions for allowed strings result in
ambiguities around who is responsible for validating what and subtle
variati
On Thu, May 20, 2021 at 03:06:06AM -0400, Ryan Sleevi wrote:
> On Thu, May 20, 2021 at 1:56 AM Viktor Dukhovni
> wrote:
>
> > On Wed, May 19, 2021 at 10:29:43PM +, Salz, Rich wrote:
> >
> > > I support limiting it.
> >
> > I concur. These are not strings used between users to communicate i
On Thu, May 20, 2021 at 11:23:15AM -0400, David Benjamin wrote:
> SVCB's syntax would need us to not only exclude non-ASCII characters but
> also avoid random delimiters like commas, right? I think that's going a bit
> too far. As Ryan notes, complex definitions for allowed strings result in
> amb
On 5/20/2021 5:28 AM, Viktor Dukhovni wrote:
On Thu, May 20, 2021 at 11:23:15AM -0400, David Benjamin wrote:
SVCB's syntax would need us to not only exclude non-ASCII characters but
also avoid random delimiters like commas, right? I think that's going a bit
too far. As Ryan notes, complex def
+1 what Ryan said. Especially the point that added restrictions aren’t a viable
path to better interoperability.
ALPN IDs are byte strings; the fact that some of them can be displayed as ASCII
character strings merely reflects the fact that those ALPN IDs were chosen by
humans😊.
Cheers,
Andre
On Thu, May 20, 2021 at 04:45:23PM +, Andrei Popov wrote:
> ALPN IDs are byte strings; the fact that some of them can be displayed
> as ASCII character strings merely reflects the fact that those ALPN
> IDs were chosen by humans😊.
That's fine when they're just private signalling between a hom
On Thu, May 20, 2021 at 1:03 PM Viktor Dukhovni
wrote:
> On Thu, May 20, 2021 at 04:45:23PM +, Andrei Popov wrote:
>
> > ALPN IDs are byte strings; the fact that some of them can be displayed
> > as ASCII character strings merely reflects the fact that those ALPN
> > IDs were chosen by humans
On Thu, May 20, 2021 at 01:46:38PM -0400, Ryan Sleevi wrote:
> > It is fine for the TLS protocol to not care, but the *standard* ALPN
> > values in the IANA registry (that might then also appear in DNS
> > zone files, configuration files, ...) a more restricted character
> > set would actually be
On Thu, May 20, 2021 at 11:19 AM Viktor Dukhovni
wrote:
> On Thu, May 20, 2021 at 01:46:38PM -0400, Ryan Sleevi wrote:
>
> > > It is fine for the TLS protocol to not care, but the *standard* ALPN
> > > values in the IANA registry (that might then also appear in DNS
> > > zone files, configuration
On Thu, May 20, 2021 at 11:52:50AM -0700, Nick Harper wrote:
> > Since the likelihood of actually adding exotic ALPN values to the
> > registry appears slim, why not say so. That would leave the exotic
> > values for private on-the-wire use, while allowing DNS and other
> > configuration serialis
On Thu, May 20, 2021 at 3:56 PM Viktor Dukhovni
wrote:
> I agree it is a straight-forwarding encoding for machines, and it is
> well suited for the GREASE code points.
>
> But, it makes for a fairly terrible user interface for the human
> operator. Compare:
>
> * managesieve
> * 6d616e61
On Thu, May 20, 2021 at 04:15:27PM -0700, Nick Harper wrote:
> > But, it makes for a fairly terrible user interface for the human
> > operator. Compare:
> >
> > * managesieve
> > * 6d616e6167657369657665
> >
> > Typos in hex values are easy to make and hard to recognise.
>
> I agree that
16 matches
Mail list logo
