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

From: Gunnar Hellström <[email-masked]>
Date: Tue, 13 Jun 2017 07:51:08 +0200

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.

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
[email-masked]
+46 708 204 288

---

From: Brian Rosen <[email-masked]>
Date: Tue, 13 Jun 2017 09:46:25 -0400

This has to have occurred in the SDP parameters.  We should do what is usually done for a similar circumstance.

> On Jun 13, 2017, at 1:51 AM, Gunnar Hellström <[email-masked]> wrote:
> 
> 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
> 
> 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.
> 
> 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.)
> 
> 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)
> 
> 
> _______________________________________________
> SLIM mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/slim

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Jun 2017 11:53:46 -0400

> easier to insert a number of complete attributes.

I think I also slightly prefer (a).

I would also be ok with (c). As things stand I think any plausible usage 
will be able to fit all on one line and still have something that still 
works ok in published examples where line length can be limited. But if 
later extended with parameters there then might be an advantage to 
breaking things out for examples.

> anyway talking about what was in the offer)

I agree that (a) is fine. As long as it is considered a legal answer 
then how it is used is really out of scope anyway.

	Thanks,
	Paul

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 13 Jun 2017 19:16:27 +0200

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

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

---

From: Randall Gellens <[email-masked]>
Date: Tue, 13 Jun 2017 11:53:26 -0700

I'm not sure we should model anything on the 'lang' attribute, since 
as discussed it is not used in offer/answer.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
The only normal people are the ones you don't know very well.
    --Joe Ancis

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 13 Jun 2017 22:34:42 +0200

> as discussed it is not used in offer/answer.
I don't think that it matters.
Our use of the offer/answer model is very flexible and without any real 
requirements. We may answer with languages that are not mentioned in the 
offer etc.
So it matches Lang quite closely even if you think that Lang is only 
declarative.

Another example of additive attribute values is the t=
"

t=<start-time> <stop-time>

    The "t=" lines specify the start and stop times for a session.
    Multiple "t=" lines MAY be used if a session is active at multiple
    irregularly spaced times; each additional "t=" line specifies an
    additional period of time for which the session will be active. "

Most other attributes are of a form where it is not of interest with more than one line.
And then it is not mentioned what happens if more than one is specified.

Conclusion: additive use exists, and we can use it.
But if you feel strong about not being specific about it, you can do as it is done
  for most other attributes and not mention the use in multiple lines.

/Gunnar