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

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Mon, 1 Oct 2012 13:28:17 +0000

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. 

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.

On Sep 29, 2012, at 1:34 AM, Miguel A. Garcia <[email-masked]> 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: [email-masked] [mailto:[email-masked]] On Behalf Of Cullen Jennings (fluffy)
>> Sent: 28. september 2012 16:47
>> To: mmusic WG
>> Cc: Flemming Andreasen (fandreas); [email-masked]
>> 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 <[email-masked]> wrote:
>> 
>>> This is to announce a 2 week Working Group Last Call for
>>> 
>>>      draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt
>>> 
>>> as Proposed Standard. Please review and provide any comments you may have on the document by September 21, 2012. Comments should be sent to the document authors and the MMUSIC WG list.
>>> 
>>> 
>>> Thanks
>>> 
>>>        Flemming
>>> 
>>> 
>>> 
>>> 
>>> Draft Info:
>>>  This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.
>>> 
>>> 	Title           : Miscellanoues Capabilities Negotiation in the Session Description Protocol (SDP)
>>> 	Author(s)       : Miguel A. Garcia-Martin
>>>                           Simo Veikkolainen
>>>                           Robert R. Gilman
>>> 	Filename        : draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt
>>> 	Pages           : 19
>>> 	Date            : 2012-08-27
>>> 
>>> Abstract:
>>>    SDP has been extended with a capability negotiation mechanism
>>>    framework that allows the endpoints to negotiate transport protocols
>>>    and attributes.  This framework has been extended with a media
>>>    capabilities negotiation mechanism that allows endpoints to negotiate
>>>    additional media-related capabilities.  This negotiation is embedded
>>>    into the widely-used SDP offer/answer procedures.
>>> 
>>>    This memo extends the SDP capability negotiation framework to allow
>>>    endpoints to negotiate three additional SDP capabilities.  In
>>>    particular, this memo provides a mechanism to negotiate bandwidth
>>>    ('b=' line), connection data ('c=' line), and titles ('i=' line for
>>>    each session or media).
>>> 
>>> 
>>> The IETF datatracker status page for this draft is:
>>> 
>>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscellaneous-c
>>> aps
>>> 
>>> 
>>> There's also a htmlized version available at:
>>> 
>>> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-miscellaneous-caps-01
>>> 
>>> 
>>> A diff from the previous version is available at:
>>> 
>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-miscellaneous-c
>>> aps-01
>>> 
>>> 
>>> 
>>> Internet-Drafts are also available by anonymous FTP at:
>>> 
>>> ftp://ftp.ietf.org/internet-drafts/
>>> 
>>> _______________________________________________
>>> mmusic mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>> 
>> _______________________________________________
>> mmusic mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mmusic
>> _______________________________________________
>> mmusic mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mmusic
>> 
> 
> -- 
> Miguel A. Garcia
> +34-91-339-3608
> Ericsson Spain
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 1 Oct 2012 16:15:59 +0200

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

You could say that you support clause 3.1.1.  Bandwidth Capability,
3.1.2.  Connection Data Capability, or 3.1.3.  Title Capability.

The draft also defines three separate option tags bcap-v0",  "ccap-v0",
and "icap-v0", for those capabilities defined that you could refer to.

I hope this is good enough?

Thomas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext Cullen Jennings (fluffy)
Sent: Monday, October 01, 2012 3:28 PM
To: Miguel A. Garcia
Cc: Flemming Andreasen (fandreas); mmusic WG;
[email-masked]
Subject: Re: [MMUSIC] WGLC for
draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt

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. 

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.

On Sep 29, 2012, at 1:34 AM, Miguel A. Garcia
<[email-masked]> wrote:

> 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.
>> 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.
>> Group Function Technology and Portfolio Management Ericsson
>> 
>> 
>> Cc: Flemming Andreasen (fandreas); 
>> [email-masked]
>> Subject: Re: [MMUSIC] WGLC for 
>> 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.
>>> as Proposed Standard. Please review and provide any comments you may
have on the document by September 21, 2012. Comments should be sent to
the document authors and the MMUSIC WG list.
>>> 	Filename        :

---

From: Andrew Allen <[email-masked]>
Date: Mon, 1 Oct 2012 16:41:50 +0000

I have been following this work closely for the past 18 months and did a thorough review of the 00 version and the only changes since then are a couple of reference updates.

So I don't have any comments and believe this draft should go forward.

Andrew

From: [email-masked] [mailto:[email-masked]] On Behalf Of Atle Monrad
Sent: Tuesday, September 25, 2012 3:57 AM
To: Flemming Andreasen; mmusic
Cc: [email-masked]
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt

Flemming

The draft has been on the 3GPP dependency list since Rel-8.

I have reviewed the draft and have no comments.

3GPP would be grateful if the draft could progress in a bundle with draft-ietf-mmusic-sdp-media-capabilities and draft-ietf-mmusic-sdp-cs as soon as possible.

thanks
/atle

Atle Monrad
3GPP CT Chairman

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Flemming Andreasen
Sent: 24. september 2012 05:41
To: mmusic
Cc: [email-masked]
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt
The WGLC for the Miscellaneous Capabilities draft is now over and we will be proceeding with a publication request.

We did not receive any comments on the draft during the WGLC. If you reviewed the document but did not have any comments on it, please let that the chairs now.

Thanks

-- Flemming

On 9/6/12 4:37 PM, Flemming Andreasen wrote:
This is to announce a 2 week Working Group Last Call for

Thanks

       Flemming

Draft Info:

                          Simo Veikkolainen

                          Robert R. Gilman

 Pages           : 19

 Date            : 2012-08-27

Abstract:

   each session or media).

https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-miscellaneous-caps

http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-miscellaneous-caps-01

mmusic mailing list

[email-masked]<mailto:[email-masked]>

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Andrew Allen <[email-masked]>
Date: Mon, 1 Oct 2012 18:07:35 +0000

I think it is possible. The statement just needs to identify the sections of the draft or functionality suppported - this is quite common practice in the industry.

Maybe rather than a last minute delay to this work the best approach would be for another draft to be written under RTCweb that specifies the SDP extensons needed for RTCweb (is the title capability really the only one?) - a kind of RTCweb hitchikers guide for SDP and then vendors can claim compliance to that.

Andrew

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Mon, 1 Oct 2012 23:22:59 +0200

Hi Cullen:

I am writing as an author of this draft.

This draft has been hanging around for years, and it was always presented 
as a collection of small capabilities that could be used independently, 
but, due to similarities, and in order to avoid the explosion of 
internet-drafts, could be documented together.

At IETF 73 the draft was already presented indicating that "This new 
draft collects these miscellaneous capabilities into a single document." 
You can check the slide #3 at:
http://www.ietf.org/proceedings/73/slides/mmusic-6.pdf

At that point in time, while there were questions about the intention of 
the various capabilities defined in the document, none raised the 
question of the documentation of these capabilities in the same document. 
I don't recall anyone having a problem because we were specifying three 
independent capabilities in the same document.

At some point in time, I consulted 3GPP, because I knew this draft was a 
dependency, and I was told that 3GPP was only using one of the 
capabilities, but was OK with documenting the other two in the same draft.

If we apply the same logic to most of our documents, we will need to 
revise other drafts that we are specifying and we should trim 
capabilities or attributes that are somehow independent of the others. I 
think this is a tedious task at this stage.

I therefore propose to continue with the existing document as is.

BR,

      Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 01 Oct 2012 21:56:36 -0400

> 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. C…
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 ?

> 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) ?

Thanks

-- Flemming

> .

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 4 Oct 2012 22:29:50 +0000

On Oct 1, 2012, at 7:56 PM, Flemming Andreasen <[email-masked]> wrote:

> I think the draft is pretty clear in not requiring all of it to be implemented, e.g. as described in the Introduction:
> 
> <quote>
>    time.  Instead, it is expected that applications will choose their
>    needed capability for their specific purpose.  Due to this, we are
>    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. 

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

>>>> From: 
>>>> [email-masked] [mailto:[email-masked]
>>>> ] On Behalf Of Cullen Jennings (fluffy)
>>>> On Sep 6, 2012, at 2:37 PM, Flemming Andreasen 
>>>> <[email-masked]>
>>>>  wrote:

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 4 Oct 2012 22:29:45 +0000

> Maybe rather than a last minute delay to this work the best approach would be for another draft to be written under RTCweb that specifies the SDP extensons needed for RTCweb (is the title capabilit…

OK, as long a the folks in the music WG view that as reasonable thing for me to do, I'll submit something.

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 05 Oct 2012 14:51:30 -0400

> OK, as long a the folks in the music WG view that as reasonable thing for me to do, I'll submit something.
Sounds good to me.

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 05 Oct 2012 15:05:49 -0400

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

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.

> 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 diffe…
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…
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

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 7 Oct 2012 21:35:04 +0200

Hi,

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

I think we have other such examples.

For example, RFC 6223 (SIP keep-alive) assumes support of RFC 5626 (SIP Outbound), but only the keep-alive part.

Regards,

Christer

---

From: Andrew Allen <[email-masked]>
Date: Mon, 8 Oct 2012 00:28:53 +0000

Yes and also RFC 5627 (GRUU) uses the +sip.instance header field parameter from RFC 5626 but implementing GRUU does not also require that you also implement all of Outbound.

GRUU and outbound also were being developed at the same time and we did not decide to split +sip.instance into a separate draft back then.

----- Original Message -----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Sunday, October 07, 2012 02:35 PM Central Standard Time
To: Cullen Jennings (fluffy) <[email-masked]>; Flemming Andreasen	(fandreas) <[email-masked]>
Cc: mmusic WG <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-miscellaneous-caps-01.txt

Hi,

Regards,

Christer

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Mon, 8 Oct 2012 22:51:57 +0000

> For example, RFC 6223 (SIP keep-alive) assumes support of RFC 5626 (SIP Outbound), but only the keep-alive part.

Yes, Agree.  

PS - as a side note, Christer you wanted the keep alive take out of outbound and I argued against that on the basis it was done but it's one of theses things where I think you were right and I wish we had done that.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 25 Oct 2012 18:08:26 +0000

Just to close out this thread…. 

I think I am in the rough part of the rough consensus on i18n so I have no objection to this draft going forward as is. Thanks to the folks who replied to me.