Re: [MMUSIC] Roman Danyliw's Discuss on draft-ietf-mmusic-sdp-uks-06: (with DISCUSS and COMMENT)

[Roman Danyliw <[e-mail]>]

Hi Martin!

Thanks this pull request.  It addresses my discuss points so I've cleared my discuss.

Regards,
Roman

> -----Original Message-----
> From: Martin Thomson [mailto:[e-mail]]
> Sent: Tuesday, August 6, 2019 3:43 AM
> To: Roman Danyliw <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; mmusic <[e-mail]>;
> [e-mail]
> Subject: Re: [MMUSIC] Roman Danyliw's Discuss on draft-ietf-mmusic-sdp-
> uks-06: (with DISCUSS and COMMENT)
> 
> I've combined the changes with Ben's.  See
> https://github.com/martinthomson/sdp-uks/pull/11
> 
> On Tue, Aug 6, 2019, at 12:24, Roman Danyliw via Datatracker wrote:
> > (1) Section 3.2.  There are a few places where further clarity on
> > error handling would be helpful:
> 
> Added requirement to use illegal_parameter.
> 
> > (2) I support Ben’s DISCUSS on the clarity of Section 3.2. I would add
> > a few additional observations:
> >
> > ** Per the sentence, “The resulting string is then encoded using
> > UTF-8”, shouldn’t this JSON text already be UTF-8 per Section 8.1 of
> > RFC8259 -- what’s the new encoding to be done?
> 
> A JSON text is a string of tokens, not octets, by my reading.  The UTF-8
> encoding is something that happens to JSON text to produce a sequence of
> octets, so you have to say that.
> 
> I realize that isn't clear from RFC 8259, but the risk I'm hedging against is the
> UTF-8 encoding not happening, not that it might happen twice (which is a
> nonsensical operation in many contexts, but I will concede still possible in
> some).  At least I hope that someone will realize that encoding twice is not a
> sensible option.