Re: [Slim] Multi-lines and offer/answer questions on draft-ietf-slim-negotiating-human-language

[Gunnar Hellström <[e-mail]>]

Den 2017-06-13 kl. 15:46, skrev Brian Rosen:
> This has to have occurred in the SDP parameters.  We should do what is usually done for a similar circumstance.
You are right.   For both cases we can find good advice in previous work.

The Lang attribute is additive   ( also c= and t= )
For Lang, there is the following description:
"

    Multiple lang attributes can be provided either at session or media
    level if the session or media has capabilities in more than one
    language, in which case the order of the attributes indicates the
    order of preference of the various languages in the session or media,
    from most preferred to least preferred.
"

Most attribute specifications do not tell what happens if they occur multiple times in the same media description.

I suggest that we include wording inspired by 'Lang'

e.g.

--------------------text proposal------------------------
    Multiple hlang attributes for the same media and direction can be provided in which case the specified
languages in these attributes are added to specify the total language capability per media and direction.
--------------------------------------------------------

>
>> On Jun 13, 2017, at 1:51 AM, Gunnar Hellström <[e-mail]> wrote:
>>
>> A couple of questions on draft-ietf-slim-negotiating-human-language.
>>
>> 1. How would inclusion of more than one hlang attribute of the same kind in a media description be handled.
>>
>> a) should it be seen as an addition, so the language tags are collected and any asterisk governs.
>>
>> b) should it replace earlier attributes of same kind in same media description
>>
>> c) should it be "illegal"
>>
>> I have a slight preference for a). Some applications might find it easier to insert a number of complete attributes.
>>
>>
>> 2. How would inclusion of hlang attributes in an answer be handled if no one was included in the offer.
The Content attribute specified in RFC 4796 that we have a lot in common 
with in the way it influences the session, , has in chapter 6 the 
following paragraph:
"

    The 'content' attribute describes the data that the application
    generating the SDP session description intends to send over a
    particular media stream.  The 'content' values for both directions of
    a media stream do not need to be the same.*Therefore, an SDP answer MAY contain 'content' attributes even if none 
were present in the offer. *  Similarly, the answer MAY contain no 'content' attributes
    even if they were present in the offer.  Furthermore, the values of
    'content' attributes do not need to match in an offer and an answer.
"

Following that pattern I suggest that we add:

---------proposed text---------------------------

An SDP answer MAY contain 'hlang-' attributes even if none were present in the offer.
---------end of proposal--------------------------

Other SDP attributes, such as the group attribute specified in RFC 5888, have more strict requirements
that say that they MUST NOT appear in an answer if they do not appear
in the offer. But we do not have the same strict protocol requirements on us.



>>
>> This assumes that the offering party supports hlang attributes bu did not bother to add any.
>>
>> a) The offering party would act on the attributes in the answer as usual. (A re-Invite would be needed to get full negotiation in place if that was desired.)
>>
>> b) The offering party would ignore it.
>>
>> c) It would be seen as "illegal"
>>
>> I think a) is the natural choice and is also how the current draft can be interpreted. In 5.2, there is a paragraph starting "In an answer..", not exactly requiring that attributes were included in an offer (but anyway talking about what was in the offer)
>>
>>
>> I suggest that some wording is included for clarification of these cases.
>>
>>
>> /Gunnar
>>
>>
>> -- 
>> -----------------------------------------
>> Gunnar Hellström
>> Omnitor
>> [e-mail]
>> [phone]
>>
>> _______________________________________________
>> SLIM mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/slim

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[e-mail]
[phone]