|
RE: draft-gellens-negotiating-human-language-01
2013-02-24 14:09:18
Hey Randy
SDP, defined in the MMUSIC WG (why isn't this
being discussed on that list? because it'll have
to go to that list before this draft progresses
anyway), isn't a negotiation protocol, it's an
offer/answer exchange (per RFC3264) - and even if
you didn't want SIP, there's not a back-and-forth
that typical "negotiations" have. You're already familiar with RFC 4566 (SDP).
SIP has a session layer language tag, from RFC 3261
20.3 Accept-Language
The Accept-Language header field is used in requests to indicate the
preferred languages for reason phrases, session descriptions, or
status responses carried as message bodies in the response. If no
Accept-Language header field is present, the server SHOULD assume all
languages are acceptable to the client.
The Accept-Language header field follows the syntax defined in
[H14.4]. The rules for ordering the languages based on the "q"
parameter apply to SIP as well.
Example:
Accept-Language: da, en-gb;q=0.8, en;q=0.7
RFC 4566 has an attribute (a=lang) that you
quote, but I'm confused why you first propose using it, then dismiss its use.
Now, your draft does say
For various reasons, including
the ability to establish multiple streams each using a different
media (e.g., voice, text, video), it makes sense to use a per-stream
negotiation mechanism, using SDP.
but there I have not found justification (or even
examples) for these "various reasons"... maybe I
missed them, but media level attributes are there
for those offers that have more than one m= line,
where the same attribute has a different value
per m= line. In your one example, you list 'en' &
'it' for the languages you want to receive in the
offer, and just 'it' in the answer. Why does this
have to be a media level attribute when you're
really after _the_one_language_for_all_m-lines_?
James
At 09:44 PM 2/23/2013, Doug Ewell wrote:
That means essentially the same thing. Check to
make sure your other reviewers feel that wording is OK.
--
Doug Ewell | Thornton, CO, USA
http://ewellic.org | @DougEwell
----------
From: <mailto:randy(_at_)qti(_dot_)qualcomm(_dot_)com>Randall Gellens
Sent: â??2/â??23/â??2013 20:34
To: <mailto:doug(_at_)ewellic(_dot_)org>Doug Ewell;
<mailto:randy(_at_)qti(_dot_)qualcomm(_dot_)com>Randall Gellens;
<mailto:ietf(_at_)ietf(_dot_)org>ietf(_at_)ietf(_dot_)org;
<mailto:rg+ietf(_at_)qualcomm(_dot_)com>rg+ietf(_at_)qualcomm(_dot_)com
Cc:
<mailto:ietf-languages(_at_)iana(_dot_)org>ietf-languages(_at_)iana(_dot_)org
Subject: RE: draft-gellens-negotiating-human-language-01
Hi Doug,
At 8:20 AM -0700 2/23/13, Doug Ewell wrote:
You might want to reference BCP 47 instead of
RFC 5646, but this is up to you.
When I reference RFC 5646, the actual reference
includes it as both RFC and BCP.
I would actually suggest leaving off the
reference to the Registry and just say the tag
must conform to 5646 (or BCP 47). That will imply the use of the Registry.
How about: "The 'humintlang' attribute value
MUST be a language tag per RFC 5646"?
----------
From: <mailto:randy(_at_)qti(_dot_)qualcomm(_dot_)com>Randall Gellens
Sent: 2/23/2013 1:18
To: <mailto:doug(_at_)ewellic(_dot_)org>Doug Ewell;
<mailto:ietf(_at_)ietf(_dot_)org>ietf(_at_)ietf(_dot_)org;
<mailto:rg+ietf(_at_)qualcomm(_dot_)com>rg+ietf(_at_)qualcomm(_dot_)com
Cc:
<mailto:ietf-languages(_at_)iana(_dot_)org>ietf-languages(_at_)iana(_dot_)org
Subject: Re: draft-gellens-negotiating-human-language-01
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
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly selected tag: ---------------
Things are more like they used to be than they are new.
|
|