Re: [MMUSIC] draft-gellens-negotiating-human-language-01

[Randall Gellens <[e-mail]>]

[[[ resending without Cc list ]]]

Hi Dale,

At 11:00 AM -0500 2/25/13, Dale R. Worley wrote:

>  (It's not clear to me what the proper mailing list is to discuss this
>  draft.  From the headers of the messages, it appears that the primary
>  list is [e-mail], but the first message in this thread about that
>  draft already has a "Re:" in the subject line, so the discussion
>  started somewhere else.)

There has been some discussion among those listed in the CC header of 
this message.  I think the mmusic list is probably the right place to 
continue the discussion and was planning on doing so more formally 
with the next revision of the draft.

By the way, the draft was updated and is now at -02: 
http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human-language-02.txt

There is a face-to-face discussion Thursday 11:30-1:00 at The 
Tropicale (the cafe in the Caribe Royal).  Please let me know if you 
can make it.

>  (Also, it's not clear why Randall's messages are coming through in
>  HTML.)

My apologies; I have gotten in the habit when replying to messages 
that have style to allow Eudora to send my reply styled as well.


>  But onward to questions of substance:
>
>  - Why SDP and not SIP?
>
>  I'd like to see a more thorough exploration of why language
>  negotiation is to be handled in SDP rather than SIP.  (SIP, like HTTP,
>  uses the Content-Language header to specify languages.)  In principle,
>  specifying data that may be used in call-routing should be done in the
>  SIP layer, but it's well-accepted in the SIP world that call routing
>  may be affected by the SDP content as well (e.g., media types).

I think it fits more naturally in SDP since the language is related 
to the media, e.g., English for audio and ASL for video.


>  And some discussion and comparison should be done with the SIP/HTTP
>  Content-Language header (used to specify the language of the
>  communications) and the SIP Accept-Language header (used to specify
>  the language of text components of SIP messages), particularly given
>  that Accept-Language has different set of language specifiers and a
>  richer syntax for specifying preferences.  In any case, preference
>  should be given to reusing one of the existing syntaxes for specifying
>  language preferences.

I think the semantics of Content-Language and Accept-Language are 
different from the semantics here, especially when setting up a 
session with, as an example, an audio stream using English and a 
video stream using ASL.  (But I can see clients using a default value 
to set both the SDP language attribute and the HTTP Content-Language, 
unless configured differently.)

As for reusing existing mechanisms, the draft does contain two 
alternative proposals, one to re-use the existing 'language' SDP 
attribute, and one to define a new attribute.

>  - Dependency between media descriptions?
>
>     Another example would be a user who is able to speak but is deaf or
>     hard-of-hearing and requires a voice stream plus a text stream
>     (known as voice carry over).  Making language a media attribute
>     allows the standard session negotiation mechanism to handle this by
>     providing the information and mechanism for the endpoints to make
>     appropriate decisions.
>
>  This scenario suggests that there might be dependency or interaction
>  between language specifications for different media descriptions.
>  Whether this is needed should be determined and documented.
>
>  - Specifying preference levels?
>
>     For example, some users may be able to speak several languages, but
>     have a preference.
>
>  This might argue for describing degrees of preference using "q"
>  parameters (as in the SIP Accept-Language header).
>
>  - Expressing multiple languages in answers
>
>     (While it is true that a conversation among multilingual people
>     often involves multiple languages, it does not seem useful enough
>     as a general facility to warrant complicating the desired semantics
>     of the SDP attribute to allow negotiation of multiple simultaneous
>     languages within an interactive media stream.)
>
>  Why shouldn't an answer be able to indicate multiple languages?  At
>  the least, this might provide the offerer with useful information.

You raise good questions that I think need more discussion.  I am 
hoping to keep the work as simple as possible and not add additional 
complexity, which argues for not solving every aspect of the problem, 
but only those that must be solved immediately.

>
>  - Reusing a=lang
>
>  Searching, I can only find these descriptions of the use of
>  "a=lang:...":
>
>      RFC 4566
>      draft-saintandre-sip-xmpp-chat
>      draft-gellens-negotiating-human-language
>
>  So it looks like "a=lang:..." is entirely unused at the present and is
>  safe to be redefined.





-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
An economist is an expert who will know tomorrow why the things he
predicted yesterday didn't happen today.       --Laurence J. Peter