Negotiating Human Language in Real-Time Communications
draft-ietf-slim-negotiating-human-language-24

== Section 7 ==

"In
   addition, if the 'hlang-send' or 'hlang-recv' values are altered or
   deleted en route, the session could fail or languages
   incomprehensible to the caller could be selected; however, this is
   also a risk if any SDP parameters are modified en route."

Given that one of the primary use cases for the attributes defined here is for emergency calling, it seems worthwhile to call out the new specific threat that these attributes enable in that case, namely the targeted manipulation/forgery of the language attributes for the purposes of denying emergency services to a caller. This general class of attacks is contemplated in Section 5.2.2 of RFC 5069, although there may be a better reference to cite here for what to do if you don't want your emergency calls subject to that kind of attack (I can't recall another document off the top of my head).

== Section 8 ==

This seems weak for not including some words to indicate what to do to mitigate the risks of exposing this information.

Thanks for writing an interesting document!

Given that this document doesn’t mandate the behavior in the case of not having languages in common, why does it matter if the combination is “difficult to match together” or not?  I’m wondering about this piece of text (from 5.2):

   ...The
   two SHOULD NOT be set to languages which are difficult to match
   together (e.g., specifying a desire to send audio in Hungarian and
   receive audio in Portuguese will make it difficult to successfully
   complete the call).

I don’t understand how “difficult to match” can be enforced from a normative point of view.  Difficulty seems to be a subjective criteria -- the example shows a pair that I would consider difficult too (I don't speak Hungarian!), but other pairings could still be difficult for me but easy for others.  Using “SHOULD NOT” (instead of “MUST NOT”) implies that there are cases in which it is ok to do it (again, probably subjectively).  It seems to me that the “SHOULD NOT” could be a simple “should not”.

BTW, that reminds me: please use the template text from rfc8174 (instead of rfc2119).

Nit:  It would be nice to expand SPD in the abstract and put a reference to rfc4566 in the Introduction.

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.)

One question: I can't really imagine cases where the send and recv would be used to indicate different things. Can you provide an example (and better explain in the document why this 'complexity' was added)?

One purely editorial note: I think section 5.1 could simply be removed before final publication as part of the reasoning is given in the intro already.