(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 ietf(_at_)ietf(_dot_)org, 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