Re: [Gen-art] Review of draft-ietf-slim-negotiating-human-language-06

[Randall Gellens]

Hi Dale,

Thank you for your review, I appreciate it.  Please see inline.

At 6:32 PM -0800 2/17/17, Dale Worley wrote:


 Reviewer: Dale Worley
 Review result: Ready with Nits

 I am the assigned Gen-ART reviewer for this draft.  The General Area
 Review Team (Gen-ART) reviews all IETF documents being processed
 by the IESG for the IETF Chair.  Please treat these comments just
 like any other last call comments.

 For more information, please see the FAQ at
 .

 Document:  draft-ietf-slim-negotiating-human-language-06
 Reviewer:  Dale R. Worley
 Review Date:  2017-02-17
 IETF LC End Date:  2017-02-20
 IESG Telechat date:  [unknown]

 Summary:
This draft is basically ready for publication, but has nits
that should be fixed before publication.

 * Technical comments

 A. Call failure

 If a call fails due to no available language match, in what way(s)
 does it fail?  Section 5.3 says

If such an offer is received, the receiver MAY
reject the media, ignore the language specified, or attempt to
interpret the intent

 But I suspect it's also allowed for the UAS to fail the call at the
 SIP level.  Whether or not that is allowed (or at least envisioned)
 should be described.  And what response code(s)/warn-code(s) should
 be
 used for that?


The text you quote has been deleted.  The draft does not mandate if 
the call should proceed or fail if there is no language match 
possible, although the draft does provide an optional mechanism to 
indicate the caller's preference that the call not fail, and the 
draft does mention that in the emergency services case, the call will 
likely proceed, but that's a matter of policy not protocol.




 B. Audio/Video coordination

5.2.  New 'humintlang-send' and 'humintlang-recv' attributes

Note that while signed language tags are used with a video stream
 to
indicate sign language, a spoken language tag for a video stream
 in
parallel with an audio stream with the same spoken language tag
indicates a request for a supplemental video stream to see the
speaker.

 And there's a similar paragraph in 5.4:


A spoken language tag for a video stream in conjunction with an

 audio

stream with the same language might indicate a request for
supplemental video to see the speaker.


 I think this mechanism needs to be described more exactly, and in
 particular, it should not depend on the UA understanding which
 language tags are spoken language tags.  It seems to me that a
 workable rule is that there is an audio stream and a video stream and
 they specify exactly the same language tag in their respective
 humintlang attributes.  In that case, it is a request for a spoken
 language with simultaneous video of the speaker, and those requests
 should be considered satisfied only if both streams can be
 established.


The text you quote has been deleted.  A media stream for supplemental 
purposes can be negotiated without a language tag, as normal.




 * The following three items are adjustments to the design which I'd
 like to know have been considered.

 C. "humintlang" seems long to me

 Given the excessive length of SDP in practice, it seems to me that a
 shorter attribute name would be desirable.  E.g., "humlang" as was
 used in some previous versions.  Or is there a coordinated usage with
 other names in the "hum*lang" pattern?


There is no intent for a coordinated pattern.  The name was chosen 
years ago to avoid potential confusion with the 'lang' attribute.  Is 
it worth reopening the issue to potentially save three characters per 
SDP line with a language?




 D. Use the Accept-Language syntax

 It seems to me that it would better to use the Accept-Language syntax
 for the attribute values.  This allows (1) specifiying the quality of
 language experience, allowing clear description of bilingualism, (2)
 a
 unified method of specifying whether or not arbitrary languages are
 acceptable, and (3) abbreviating SDP descriptions.

 In a way, the fact that the current proposal seems to require (but
 does not directly specify) the coordinated absence/presence of an
 asterisk on all of the repetitions of humintlang-send or
 humintlang-recv is a warning that the syntax doesn't represent the
 semantics as well as it might.


The group considered multiple proposals to permit specifying quality, 
preference, q-values, etc. but decided to keep things simple for this 
draft.  There is no intent to require the use of an asterisk (to 
indicate a preference by the caller to not fail the call).  The 
asterisk is a very mild mechanism with no normative effects.  It 
merely conveys the preference of the caller, and is not binding on 
the answerer.



 E. Have an attribute to abbreviate the bidirectionally-symmetric case

 Note that all examples are bidirectionally symmetric, and the text
 says that requests and responses SHOULD be bidirectionally symmetric.
 So it would be a 

Re: [Gen-art] Review of draft-ietf-slim-negotiating-human-language-06

[Randall Gellens]

I am almost done with my reply.  I wasn't ignoring Dale, I've been 
working on his comments.


At 11:28 PM + 2/21/17, Natasha Rooney wrote:

 Hi Dale! Many thanks for these comments, as one of the SLIM chairs 
I'll work on getting some answers to you or I'll request the author 
or one of the SLIM active participants to respond.


 Bernard, Randall and SLIM - see below re Dale's points. 



  A. Call failure 
 Randall or Bernard can you respond to this? I imagine the UA call 
failure method is UA specific, but if there is a clash with SIP 
level call fail then this should be addressed.


  B. Audio/Video coordination 
 I believe the theory behind the current draft is that the spoken 
and video streams will be different in the cases of such things as 
sign language. Video could therefore be sign and audio would be a 
spoken language. I'm not sure if the suggestion he satisfies this 
case?


  C. "humintlang" seems long to me 
 Bernard - I don't see the issue with shortening humintlang, but the 
group might. I suggest we throw this to the group for discussion.


  D. Use the Accept-Language syntax 
 Randall and Bernard - is this an acceptable change? Or one we need 
to discuss further. Seems like a reasonable request, but also a 
larger change, which is why I ask!


  E. Have an attribute to abbreviate the 
bidirectionally-symmetric case 
 I do not remember us having this discussion within the group, 
although it may have occurred before I became chair.
 Randall, Brian or Bernard - has this idea been discussed before? If 
so, can one of you respond with an explanation as to why we haven't 
done this?


  Editorial comments and nits *
 Randall - can you take a look through Dale's editorial comments and 
shout if there is any problems with these suggestions; if 
everything is ok please make the changes.


 Thanks all!

 Natasha Rooney | Internet Engineering Director | Internet and Web 
Team | Technology | GSMA 
| nroo...@gsma.com | +44 (0) 7730 219 765 
| @thisNatasha | Skype: nroo...@gsm.org


 On 18 Feb 2017, at 02:32, Dale Worley 
<wor...@ariadne.com> wrote:


 Reviewer: Dale Worley
 Review result: Ready with Nits

 I am the assigned Gen-ART reviewer for this draft.  The General Area
 Review Team (Gen-ART) reviews all IETF documents being processed
 by the IESG for the IETF Chair.  Please treat these comments just
 like any other last call comments.

 For more information, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

 Document:  draft-ietf-slim-negotiating-human-language-06
 Reviewer:  Dale R. Worley
 Review Date:  2017-02-17
 IETF LC End Date:  2017-02-20
 IESG Telechat date:  [unknown]

 Summary:
   This draft is basically ready for publication, but has nits
   that should be fixed before publication.

 * Technical comments

 A. Call failure

 If a call fails due to no available language match, in what way(s)
 does it fail?  Section 5.3 says

   If such an offer is received, the receiver MAY
   reject the media, ignore the language specified, or attempt to
   interpret the intent

 But I suspect it's also allowed for the UAS to fail the call at the
 SIP level.  Whether or not that is allowed (or at least envisioned)
 should be described.  And what response code(s)/warn-code(s) should
 be
 used for that?

 B. Audio/Video coordination

   5.2.  New 'humintlang-send' and 'humintlang-recv' attributes

   Note that while signed language tags are used with a video stream
 to
   indicate sign language, a spoken language tag for a video stream
 in
   parallel with an audio stream with the same spoken language tag
   indicates a request for a supplemental video stream to see the
   speaker.

 And there's a similar paragraph in 5.4:


   A spoken language tag for a video stream in conjunction with an


 audio


   stream with the same language might indicate a request for
   supplemental video to see the speaker.



 I think this mechanism needs to be described more exactly, and in
 particular, it should not depend on the UA understanding which
 language tags are spoken language tags.  It seems to me that a
 workable rule is that there is an audio stream and a video stream and
 they specify exactly the same language tag in their respective
 humintlang attributes.  In that case, it is a request for a spoken
 language with simultaneous video of the speaker, and those requests
 should be considered satisfied only if both streams can be
 established.

 * The following three items are adjustments to the design which I'd
 like to know have been considered.

 C. "humintlang" seems long to me

 Given the excessive length of SDP in practice, it seems to me that a
 shorter attribute name would be desirable.  E.g., "humlang" as was
 used in some previous versions.  Or is there a coordinated usage