Subject: Re: [jose] Ted Lemon's No Objection on draft-ietf-jose-json-web-key-33: (with COMMENT)

From: Mike Jones <[email-masked]>
Date: Sat, 10 Jan 2015 04:52:26 +0000

Hi Ted,

In reviewing the JOSE drafts in preparation for them being approved, I was looking at https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-key/ballot/#ted-lemon and saw that you'd filed a NO OBJECTION ballot (with COMMENT) that for some reason wasn't delivered to my e-mail.  Since I hasn't seen it until today, I hadn't previously responded.  My apologies!  Your comment was:
Comment (2014-10-02 for -33)
I'm not sure whether I need to complain about this, but the following seems
underspecified:

   UTF8(STRING) denotes the octets of the UTF-8 [RFC3629] representation
   of STRING.

   ASCII(STRING) denotes the octets of the ASCII [USASCII]
   representation of STRING.

The issue is that we don't know what STRING is.   Is it 32-bit unicode?   Is it
ASCII?   What does it mean to have ASCII(unicode string)?   Is ASCII(STRING) an
assertion that STRING is representable as ASCII?

These are fair questions.  The STRING in this notation is always a sequence of characters with an unspecified representation.  The notations UTF8(STRING) and ASCII(STRING) are used to represent the character string as an octet sequence with a particular character encoding.

You're right that ASCII(Unicode string) isn't meaningful in the general case; it's only used when the character set of STRING is constrained to containing only ASCII characters.  I suppose that you're right you could think of ASCII(STRING) as an assertion that STRING is representable in ASCII, but it means more than that; it specifies a particular octet sequence that represents those characters.

For instance, while both ASCII("Abc") and UTF8("Abc") result in the octet sequence [65, 98, 99], if we were to have a related UTF16BitEndian() function (which we don't), UTF16BitEndian("Abc") would represent the octet sequence [0, 65, 0, 98, 0, 99] and EBCDIC("Abc") would represent the octet sequence [193, 130, 131].  But now I'm off into esoterica... ;-)

Back to the topic at hand, the notation UTF8(STRING) was adopted to replace the much more verbose notation "the octets of the UTF-8 representation of STRING" which used to appear repeatedly throughout the drafts and in particular, the notation BASE64URL(UTF-8(STRING)) replaces the also previously very common notation "the Base64url encoding of the octets of the UTF-8 representation of STRING".  This was an improvement suggested by Jim Schaad in one of his review comments.

If you think that the current notation is unclear, we should sort out how to clarify it.  The best I've come up with is to add the phrase ", where STRING is a sequence of zero or more Unicode characters" to these definitions.  (The language "sequence of zero or more Unicode characters" comes from the introduction to RFC 7159.)  Do you think that would address your questions, or do you have an alternate suggestion?

Sorry again for you not receiving a reply to this until now!

                                                            Best wishes,
                                                            -- Mike

---

From: Ted Lemon <[email-masked]>
Date: Sat, 10 Jan 2015 08:09:05 -0500

On Jan 9, 2015, at 11:52 PM, Mike Jones <[email-masked]> wrote:
> If you think that the current notation is unclear, we should sort out how to clarify it.  The best I’ve come up with is to add the phrase “, where STRING is a sequence of zero or more Unicode characters” to these definitions.  (The language “sequence of zero or more Unicode characters” comes from the introduction to RFC 7159.)  Do you think that would address your questions, or do you have an alternate suggestion?

You could add a note that says something like this:

The specific encoding, ASCII(string) or UTF8(string) specifies how string is encoded as a sequence of octets.   The original encoding of string is unspecified, although the specific encoding does also constrain the set of characters that can appear in string.

> Sorry again for you not receiving a reply to this until now!

I thought you had, but it's no problem either way.   Thanks for checking back on it!

---

From: Mike Jones <[email-masked]>
Date: Sat, 10 Jan 2015 22:04:11 +0000

Hi Ted,

Rather than adding a clarification/disclaimer clause, how about this wording, which keeps things simple and inline?

   UTF8(STRING) denotes the octets of the UTF-8 [RFC3629] representation of STRING, where STRING is a sequence of zero or more Unicode characters.

   ASCII(STRING) denotes the octets of the ASCII [RFC20] representation of STRING, where STRING is a sequence of zero or more ASCII characters.

In particular, I'd rather avoid the description "unspecified" in the specs, which could raise more questions than it answers for implementers.  Also, I believe that the new clauses accomplish the constraining of the character sets that your wording included.

Does that work for you?

				Thanks again,
				-- Mike

---

From: Mike Jones <[email-masked]>
Date: Wed, 14 Jan 2015 02:10:05 +0000

Ted, this resolution has been incorporated into the -40 documents.  Thanks again for your useful review!

				-- Mike

-----Original Message-----
From: jose [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Saturday, January 10, 2015 2:04 PM
To: Ted Lemon
Cc: Kathleen Moriarty; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [jose] Ted Lemon's No Objection on draft-ietf-jose-json-web-key-33: (with COMMENT)

Hi Ted,

Does that work for you?

				Thanks again,
				-- Mike

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Saturday, January 10, 2015 5:09 AM
To: Mike Jones
Cc: [email-masked]; [email-masked]; Kathleen Moriarty; [email-masked]; [email-masked]
Subject: Re: Ted Lemon's No Objection on draft-ietf-jose-json-web-key-33: (with COMMENT)

_______________________________________________
jose mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jose

---

From: Ted Lemon <[email-masked]>
Date: Tue, 13 Jan 2015 19:21:01 -0800

> In particular, I'd rather avoid the description "unspecified" in the specs, which could raise more questions than it answers for implementers.  Also, I believe that the new clauses accomplish the c…

This wording makes me happy.   Thanks for working it through!