[Slim] Eric Rescorla's No Objection on draft-ietf-slim-negotiating-human-language-19: (with COMMENT)

[Eric Rescorla <[e-mail]>]

Eric Rescorla has entered the following ballot position for
draft-ietf-slim-negotiating-human-language-19: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Document: draft-ietf-slim-negotiating-human-language-17.txt

1. I'm not marking this first point DISCUSS, but I do think it's
important it be addressed and I trust the AD will ensure that it is.
This document is ambiguous about the contents of the answer
attribute. Specifically, it says:

   In an answer, 'hlang-send' is the language the answerer will send if
   using the media for language (which in most cases is one of the
   languages in the offer's 'hlang-recv'), and 'hlang-recv' is the
   language the answerer expects to receive if using the media for
   language (which in most cases is one of the languages in the offer's
   'hlang-send').

However, the next paragraph permits >1 tag, as does the ABNF in S 6.1.

   Each value MUST be a list of one or more language tags per BCP 47
   [RFC5646], separated by white space.  BCP 47 describes mechanisms for
   matching language tags.  Note that [RFC5646] Section 4.1 advises to
   "tag content wisely" and not include unnecessary subtags.

So, how am I supposed to interpret an answer with >1 tag? Is this
forbidden? I can imagine a number of semantics, but it's important
it be clear in the document.


2. The negotiation structure here does not match that which is
conventionally used with SDP, where each side indicates the formats it
is prepared to receive and the other side can send any of them. Why
did you use this structure? One reason you might is that you expect
the answer to resolve which language is in use, however because SIP
supports early media (i.e., media which is delivered prior to the
answer.)