Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt

[Flemming Andreasen <[e-mail]>]

On 10/4/12 6:29 PM, Cullen Jennings (fluffy) wrote:
> On Oct 1, 2012, at 7:56 PM, Flemming Andreasen <[e-mail]> wrote:
>
>> On 10/1/12 9:28 AM, Cullen Jennings (fluffy) wrote:
>>> I think the issues is how does a manffacture says on a spec sheet that they want support half of it but not all of it. I know that does not matter for 3GPP usage but it sort of useful for others. Clearly this is not a huge technical issues but a small procedural thing so I leave it up to the chairs what they want to do.
>> I think the draft is pretty clear in not requiring all of it to be implemented, e.g. as described in the Introduction:
>>
>> <quote>
>>     Since the three added capabilities are highly unconnected, it is not
>>     expected that implementations will support all of them at the same
>>     time.  Instead, it is expected that applications will choose their
>>     needed capability for their specific purpose.  Due to this, we are
>>     writing the normative part pertaining to each capability in a self-
>>     contained section: Section 3.1.1 describes the bandwidth capability
>>     extension, Section 3.1.2 describes the connection data capability
>>     extension, and Section 3.1.3 describes the title capability
>>     extension.  Separate option tags are defined for each capability.
>> </quote>
>>
>>
>> and carried through in the main part of the doc itself (btw; there seems to be an error in the "conn-config-list" inasmuch as it does not include the "["+"]" prefix to indicate mandatory extensions).
>>
>> With the separate option tags in mind, the above text, and also inclusion of the "mandatory" prefix in the various configurations, do you still have concerns around the granularity of the draft ?
> The upside of combining these are roughly, as Miguel said in his email, we can combine multiple random small stuff into one draft. The downside is that if you do half some but not all of them, you can't say you implement RFC 1234. Personally, I don't see that reviewing it in one draft is greatly simpler than a few drafts but really, this is not a big deal to me. As long as the  MMUSIC WG if fine with the RTCWeb WG having drafts that say do part of RFC XXXX, but not all of it - I don't see any problem with leaving it all in one draft. If there not OK with that, then we need split it apart but it sounds like folks are fine with keeping it as one.

In the future, I'm fine either way. The reason I'd prefer to keep them 
together in this draft is because we are at the WGLC stage and 3GPP is 
anxiously waiting for us to complete this work. Given that we have 
individual option tags for each of the extensions defined in this draft, 
we have a well-defined way of splitting them up as it is, so I think we 
are fine with proceeding with a single draft in this case, even if 
RTCWeb or others only want to use a subset.

>>> Any thoughts on making the changes so this works in world with more than english? That was my far more relevant comment that is likely to also be raised by IESG.
>>>
>>>
>> Can you elaborate on how this differs from the native SDP use of the "i=" field, which is simply being carried over here (maybe there should be some text talking about "a=charset" interactions though, per RFC 4566) ?
> The "i=" field was defined before the IETF was trying to seriously support i18n and there is no easy backwards compatible way to fix it. Also, the "i=" is more or less not used. This is a bit different - it's new and people are saying it would be used by 3GPP.
Not sure I follow - the title capability defined in the draft is defined 
as mapping directly to the RFC 4566 "i=" field.


>
> Making it support multiple languages would probably not be hard - you could do it with a set of strings where each string also had a language tag and the strings were UTF8 then encoded with base64 to represent them in SDP.
Ok, but it would no longer correspond to the "i=" field then, right ? 
Are you looking for an internationalized version of the "i=" field 
instead (could define an attribute for that, which would then 
automatically be representable as an attribute capability) ? If so, I 
think that's above and beyond what this draft is trying to do (which is 
not to say we don't need another draft to solve this, but it's not just 
as a capability then) ?

> Given then is meant to be read by humans, why wouldn't you make it so it can be read by human.
>
The draft is just trying to map existing SDP into capabilities.

-- Flemming

>>
>> Thanks
>>
>> -- Flemming
>>
>>> On Sep 29, 2012, at 1:34 AM, Miguel A. Garcia
>>> <[e-mail]>
>>>   wrote:
>>>
>>>
>>>> Cullen,
>>>>
>>>> The draft is written as an independent collection of "objects". This is avoid having three separate drafts.
>>>>
>>>> It is possible to refer to parts of this draft. For example, I believe 3GPP only needs the connection data capability, but not the others, and still they are fine with this draft.
>>>>
>>>> Couldn't the same principle be applied by RTCweb?
>>>>
>>>> /Miguel
>>>>
>>>> On 28/09/2012 17:02, Atle Monrad wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> Is it really necessary to chop the draft up in pieces because others may want to use just parts of it?
>>>>>
>>>>> I find it more constuctive to finish this draft as is and let other be able to build on and refer to the RFC if and when possible.
>>>>>
>>>>> /atle
>>>>>
>>>>> ________________________________
>>>>>
>>>>>
>>>>> Atle Monrad
>>>>> 3GPP CT Chairman
>>>>> Standardization and Regulation,
>>>>> Group Function Technology and Portfolio Management
>>>>> Ericsson
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From:
>>>>> [e-mail] [mailto:[e-mail]
>>>>> ] On Behalf Of Cullen Jennings (fluffy)
>>>>> Sent: 28. september 2012 16:47
>>>>> To: mmusic WG
>>>>> Cc: Flemming Andreasen (fandreas);
>>>>> [e-mail]
>>>>>
>>>>> Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt
>>>>>
>>>>>
>>>>> Major comment
>>>>>
>>>>> I think the title stuff should be split out to a separate draft. The main reason is that you might want to build a dvicd that supported title but did not supper the others and still be able to say what you were doing was RFC X. For example, the RTC Web folks may want to use this.
>>>>>
>>>>> Given the Title is meant to be human readable, I think it needs to be extended to have normal i18n support.
>>>>>
>>>>> Cullen
>>>>>
>>>>>
>>>>>
>>>>> On Sep 6, 2012, at 2:37 PM, Flemming Andreasen
>>>>> <[e-mail]>
>>>>>   wrote:
> .
>