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

["Cullen Jennings (fluffy)" <[e-mail]>]

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. 

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

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. 

Given then is meant to be read by humans, why wouldn't you make it so it can be read by human. 


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