On Sun, Dec 07, 2014 at 04:07:54PM -0500, John Cowan wrote:
> However, I grant that mentioning UTF-8 only in an ABNF comment is not
> really prominent enough. Proposed wording change:
>
> For:
>
>In prose: a series of octet strings, each containing any octet other
>than a record separato
On Sun, Dec 07, 2014 at 11:37:58PM -0800, Tim Bray wrote:
> I agree 100% that the fact that JSON Text Sequences MUST BE UTF-8 should be
> highlighted. Both the ASCII and Unicode names of 30/0x1e/0000 should,
> for completeness, be provided. It would be inappropriate to omit ASCII,
> because w
[I've been traveling, please excuse my late responses.]
On Sun, Dec 07, 2014 at 07:55:41PM +0100, Patrik Fältström wrote:
> > On 7 dec 2014, at 19:05, John Cowan wrote:
> > Patrik Fältström scripsit:
> >
> >> But it also reference RFC7159, which doesn't require UTF-8 but instead
> >> for some w
On Fri, Dec 05, 2014 at 02:51:04PM +, Black, David wrote:
> This is a combined Gen-ART and OPS-Dir review. Boilerplate for both follows
> ...
Thanks you.
> Minor issues:
>
> [A] Section 2.1:
>
>If parsing of such an octet string as a JSON text fails, the parser
>SHOULD nonetheless
On Mon, Dec 08, 2014 at 11:20:25PM -0500, John Cowan wrote:
> Patrik Fältström scripsit:
> > This implies the whole thing is a UTF-8 encoded text that is to be
> > parsed like this:
>
> No, this is a misunderstanding. There is no requirement that the sequence
> *as a whole* is well-formed UTF-8 t
On Tue, Dec 09, 2014 at 06:03:33AM +0100, Patrik Fältström wrote:
>
> > On 9 dec 2014, at 04:37, Nico Williams wrote:
> >
> >> and add a suitable reference to UTF-8.
> >
> > Oh, eh, RFC7159 lacked such a thing. At least this one should be
> > non-co
On Tue, Dec 09, 2014 at 04:41:12PM +, Black, David wrote:
> [A] JSON text parse failures
> > [...]
>
> Your alternative wording "whenever the JSON text parse fails, ..." is fine.
OK.
> [D] Truncation
>
> > A missing terminating LF is not a problem for strings, arrays, or
> > objects. I see
On Tue, Dec 09, 2014 at 06:49:35PM +, Black, David wrote:
> > So I think we really do need to say something about top-level numbers
> > (and true, false, and null), namely: that they must be delimited by
> > whitespace, that '1234' is not a valid sequence element because
> > the number may have
On Wed, Dec 10, 2014 at 10:52:22AM +1000, Matthew Kerwin wrote:
> On 10 December 2014 at 10:49, Nico Williams wrote:
> > (yes, I think this should be a 'should', not a 'SHOULD').
>
> Not an 'ought to'?
I'll take that.
__
I'll submit a -11 ASAP.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
On Thu, Dec 11, 2014 at 10:29:16AM -0800, Paul Hoffman wrote:
>
> > Item [F] about the text in the IANA Considerations
> > (Section 4) remains open - if the intent is to not deal with replacing
> > that text until after IESG approval, an RFC Editor Note to that effect
> > should be added to Secti
On Fri, Dec 12, 2014 at 09:50:53AM +1100, Manger, James wrote:
> >With John Cowan's change ("an ASCII Line Feed character (0x1E)"
> >instead of "an ASCII Record Separator (0x1E)"), that would indeed be
> >clearer.
>
> Please no. That would give an even worse mix of UTF-8 and ASCII, bytes
> and cha
On Thu, Dec 11, 2014 at 08:04:18PM -0500, John Cowan wrote:
> Paul Hoffman scripsit:
>
> > > JSON text sequences MUST use UTF-8 encoding; other encodings of JSON
> > > (i.e., UTF-16 and UTF-32) MUST NOT be used.
> >
> > That seems like a good clarifying addition as well.
>
> I continue to th
On Thu, Dec 11, 2014 at 08:41:40PM -0500, John Cowan wrote:
> Nico Williams scripsit:
>
> > RS cannot accidentally result from truncating a multi-byte UTF-8
> > encoded codepoint.
>
> I realize that. But because such truncations are possible, we can't
> ass
RFC 8615 (and RFC 5785 before it) says that .well-known should be at the
root of the URI local-part. Appendix A explains the rationale.
However, I'm seeing multi-tenancy in OpenID, with URI local-parts of the
form /${tenant}/.well-known/openid-configuration, which is not the
intended usage. /.we
On Fri, May 01, 2020 at 09:32:27AM +1000, Mark Nottingham wrote:
> (a) (b) Appendix A already talks about it some:
>
> """
>Why aren't per-directory well-known locations defined?
> Allowing every URI path segment to have a well-known location
> (e.g., "/images/.well-known/") would
16 matches
Mail list logo
