Subject: Re: draft-gellens-negotiating-human-language-01

From: Randall Gellens <[email-masked]>
Date: Sat, 23 Feb 2013 00:18:22 -0800

Hi Doug,

Thanks very much.  So, if I understand, your suggestions
would be:

(1) Change the text for the possible new 'humintlang' attribute
from:

The "humintlang"
attribute value must be a single RFC 3066

[RFC3066] language tag in US-ASCII
[RFC3066].  It is not dependent

on the charset attribute.

To:

The "humintlang" attribute
value must be a single RFC 5646

[RFC5646] language tag from the IANA
registry [IANA-lang-

tags].  It is not dependent on the
charset attribute.

(2) Add RFC 5646 to the Normative References

Since the IANA registry referenced now was actually created by
RFC 5646 not RFC 3066, this is both better technically (for the
reasons you mention) and more correct.

Let me know if I've understood, and if so, I may be able to get
an update in before the cut-off.

At 9:09 AM -0700 2/22/13, Doug Ewell wrote:

Draft-gellens-negotiating-human-language-01, "Negotiating
Human Language Using SDP", says this about the source of values
for the SDP 'lang' attribute: > The "lang" attribute
value must be a single [RFC3066] language tag > in US-ASCII
[RFC3066]. Although this wording is quoted from RFC 4566, the
subsequent section proposing a new 'humintlang' attribute uses the
same wording. Any new format or protocol that employs language tags
should apply BCP 47 (RFC 5646), not RFC 3066, which was obsoleted in
2006. BCP 47 allows the use of more than 7300 additional language
subtags derived from ISO 639-3, as well as script subtags based on ISO
15924 and variant subtags, none of which are permitted in a generative
manner by RFC 3066. The draft says, "The attribute value should
be a language tag from the IANA registry [IANA-lang-tags]",
referencing www.iana.org/assignments/language-subtag-registry, but RFC
3066 does not use this registry; it references the core ISO standards
directly, which reduces stability, and it uses its own IANA registry
(also obsolete) only for a few dozen predefined variant tags, many of
which are deprecated in BCP 47. RFC 4647, also part of BCP 47,
provides guidelines for matching language tags, and may benefit the
SDP negotiation process described in the draft. -- Doug Ewell |
Thornton, CO, USA http://ewellic.org | @DougEwell °©

--

Randall Gellens

Opinions are personal;    facts are
suspect;    I speak for myself only

-------------- Randomly selected tag: ---------------

Two things are infinite: the universe and human stupidity;

and I'm not even sure about the universe.

--Albert Einstein

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 25 Feb 2013 11:00:34 -0500 (EST)

(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 [email-masked], but the first message in this thread about that
draft already has a "Re:" in the subject line, so the discussion
started somewhere else.)

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

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

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.

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

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

Dale