Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg

[Paul Kyzivat <[e-mail]>]

In my opinion we should start out assuming that the existing attribute 
registries are consolidated into one, with an extra column, as has been 
planned.

Then we consider how to build on that.

My thought is that "dcsa" simply becomes another context, alongside 
"session", "media", and "source". A given attribute could be valid in 
any combination of those.

And then the reference section of that entry should get a reference to 
every document that pertains to that attribute.

That does leave the issue Juergen raises: you might need to read a bunch 
of documents to find which ones pertain to usage in dcsa, and to a 
particular subprotocol.

We could consider further enhancements to the registry to make that sort 
of query easier. Or we could just assume it won't be a problem often 
enough to bother.

	Thanks,
	Paul

On 3/9/16 7:32 AM, Juergen Stoetzer-Bradler wrote:
> Hello Christian,
>
> Thanks for your reply.
> Please find my comments inserted below.
>
> Thank you,
> Juergen
>
>
> On 09.03.2016 01:53, EXT Christian Groves wrote:
>> Hello Juergen,
>>
>> What I was thinking was that:
>> - If a subprotocol (datachannel) reuses media or session attributes a
>> reference to the subprotocol RFC is added to the IANA registration for
>> the attribute only I there was some specific behaviour change or
>> consideration.
>
> Here, do you have the existing "att-field (both session and media
> level)" and "att-field (media level only)" registries in mind? Thus do
> you think then the "Reference" field of the attribute's existing row in
> the "att-field (both session and media level)" or "att-field (media
> level only)" table would be extended?
> In such a case I assume that multiple data channel subprotocol RFC
> references might be added to an existing attribute's "Reference" field,
> e.g. if two different data channel subprotocol RFCs reuse the same
> attribute and if both contain specific (but different, subprotocol
> depending) considerations for this attribute.  Should then also the
> corresponding subprotocol ids be added to the subprotocol document
> references? Would that be possible at all in the existing registries?
> (Otherwise somebody searching for a subprotocol specific meaning might
> need to review several documents until finding the one for the
> subprotocol he is interested in.)
>
> [As an example, the msrp-usage-data-channel document describes data
> channel transport specific aspects of the "setup" attribute, hence the
> "Reference" field for the "setup" attribute in table "att-field (both
> session and media level)" would be extended with a reference to this
> msrp-usage-data-channel document. The "setup" attribute is also
> specifically mentioned in RFC 4583 for BFCP. Potentially, a future
> version of draft-schwarz-mmusic-bfcp-usage-data-channel might also
> describe BFCP and data channel transport specific aspects for the
> "setup" attribute. In that case I'd assume that a reference to
> draft-schwarz-mmusic-bfcp-usage-data-channel would then also be added to
> the "Reference" field of the existing "setup" related row in table
> "att-field (both session and media level)".]
>
> And if a data channel subprotocol reuses an existing attribute and keeps
> this attribute's original meaning, then this attribute's "att-field
> (both session and media level)" or "att-field (media level only)" table
> entry would not be modified, would it?
>
>> - If a subprotocol RFC defines a data channel specific attribute (i.e.
>> cannot be used at the media or session level) then this would go into
>> a new global IANA "data channel level" registry.
>> - The data channel level attribute could be reused by multiple data
>> channels so it should be possible to include multiple references (my
>> understanding of Flemming's point).
>>
>> I guess this is your (A)(i) below?
>
> Actually, as far as I understand your description, I think that would be
> a variant of (A)(ii), which would use different registries - depending
> on whether an already existing attribute is reused for one or more data
> channel subprotocols (in which case the already existing attribute row
> is updated), or a new attribute is introduced by a data channel
> subprotocol specifying document (in which case the attribute would be
> added to an "att-field (data channel level)" table.
>
>>
>> If it is then I don't think its possible for a registry entry to be
>> associated with zero document, i.e. there must always be a document
>> reference.
>
> I agree that there would at least always be one document reference.
> (That's why I think that your description may be more related with
> (A)(ii)). When I wrote (A)(i) I was thinking of a registry containing
> all already existing attributes (like the merged registry which Paul
> mentioned), and where then (most of the) attributes would then not be
> associated with (a) data channel subprotocol defining document(s).
>
>>
>> Option B(i) seems to be a summary of what the RFC defining the
>> sub-protocol would say. People can find out what attributes are used
>> by reading the RFC itself rather than an IANA registry. So I'm not
>> particularly in favour of that.
>>
>> Option B(ii) seems to be the same as A(i) with the lookup key being
>> the sub-protocol id rather than an attributeID. It seems the
>> convention applied to SDP is lookup based on attribute rather than
>> protocol. E.g. there are other protocols that use multiple media or
>> session level attributes but they don't have their own registry.
>
> Yes, agree, in both (B)(i) and (ii) the lookup keys would be the
> subprotocol id. And also agree that both (B) options seem to be rather
> new attribute registration approaches, which would primarily be based on
> subprotocol ids, rather than on the attribute names.
>
>>
>>
>> Regards, Christian
>>
>> On 9/03/2016 12:51 AM, Juergen Stoetzer-Bradler wrote:
>>> Flemming, Paul, Christian,
>>>
>>> Trying to summarize, as per my understanding following three main
>>> options (A), (B) and (C) have been discussed in this email thread
>>> regarding the IANA registration of SDP attributes.
>>>
>>> (A) "One new global IANA registry for data channel subprotocol
>>> attributes, common for all data channel subprotocols":
>>> Similar to IANA's RTP source level attribute registry a global IANA
>>> "data channel level" attribute registry could be created.
>>>     (i) Either, this registry could list all existing (and potential
>>> future) attributes, and for each attribute could state if it could
>>> also be used as dcsa embedded attribute associated with certain data
>>> channel subprotocols. Each attribute within this registry might then
>>> be associated with zero, one or multiple document references, where
>>> each referenced document should describe this attribute's semantic
>>> and usage for a specific subprotocol. (Which would not exclude one
>>> document describing an attribute's semantic and usage for more than
>>> just one data channel subprotocol.)
>>>     (ii) Or, this registry could list only those existing (and
>>> potential future) attributes, which have already been identified as
>>> data channel subprotocol attributes. All such already identified data
>>> channel subprotocol attributes could be listed in that registry,
>>> regardless of whether or not the usage of these attributes is
>>> specific for data channel transport. Each attributes listed in this
>>> registry could be associated with one or multiple document
>>> references. Each such a reference could point to a document which
>>> could either describe the data channel transport specific usage of
>>> this attribute for one or several data channel subprotocols. Or such
>>> a reference could point to the document, which defines this attribute
>>> in a data channel independent / generic way (if usage of this
>>> attribute does not have data channel transport specific aspects).
>>>     (iii) Or, this registry could only list those existing (and
>>> potential future) attributes, which have already been identified as
>>> data channel subprotocol attributes, and whose usage is indeed data
>>> channel transport specific. Similar as in (ii) each attribute listed
>>> in this registry could be associated with one or multiple document
>>> references. Each such reference could point to a document which could
>>> describe the data channel transport specific usage of this attribute
>>> for one or several data channel subprotocols.
>>>
>>> (B) "For each data channel subprotocol one new dedicated attribute
>>> registry":
>>> The document, which requests to add the data channel subprotocol's
>>> identifier to the IANA WebSocket subprotocol name registry, could
>>> additionally request to create a new IANA registry, specific for this
>>> subprotocol, which could list all attributes, which can be used as
>>> a=dcsa embedded attributes for this data channel subprotocol. Similar
>>> as in (A) there seem to be (at least) two sub-options:
>>>     (i) Either, this subprotocol specific registry could list all
>>> attributes, which could be used for this subprotocol (and have
>>> already been identified as such) in case of data channel transport.
>>> Each such attribute could then be associated with exactly one
>>> document reference, where this reference either could point to a
>>> document, which describes the data channel transport specific usage
>>> of this attribute for this specific subprotocol, or could point to a
>>> document, which specifies this attribute in a data channel
>>> independent way.
>>>     (ii) Or, this subprotocol specific registry could only list those
>>> attributes, which could be used for this subprotocol, and which have
>>> a data channel transport specific semantic. Each such attribute could
>>> then be associated with a document describing this data channel
>>> transport specific semantic for this subprotocol.
>>>
>>> (C) "No data channel specific registry(s) - re-use of the already
>>> existing session and media level or media level only registries":
>>> The document, which requests to add the data channel subprotocol's
>>> identifier to the IANA Websocket subprotocol id registry, could
>>> additionally describe the usages of those attributes, which may be
>>> used for this data channel subprotocol, and whose usages and/or
>>> semantics have data channel transport specific aspects. However, if
>>> those attributes did already exist prior to the creation of this data
>>> channel subprotocol document, then the already existing IANA
>>> registrations of those attributes would not be modified. If this data
>>> channel subprotocol describing document introduced new subprotocol
>>> specific attributes, then it could request these to be added to the
>>> exiting media level only attribute registry. Subsequently, if a later
>>> document introduces new attributes, which could also be used for that
>>> subprotocol in the data channel transport case, then that later
>>> document could describe this data channel subprotocol specific usage,
>>> and could also add these attributes to the existing session and media
>>> level or media level only attribute registry.
>>>
>>>
>>> If I am not mistaken then (A)(i) was the option which Paul initially
>>> mentioned in this email thread. And Paul also mentioned a variant,
>>> where the already existing attribute registries could be merged into
>>> just one, where a new field could be added describing the attribute's
>>> scope (which then could contain more than just one scope), and where
>>> also 'data channel level' could be an attribute's scope. In such a
>>> case different scopes might potentially refer to different documents.
>>> In his last email Christian did also refer to option (A), I think.
>>> Option (B) was mentioned by Flemming, where he expressed a preference
>>> for (B)(i), as far as I understood.
>>> Option (C) is the one which is (to the most part) described in
>>> current version 08 of draft-ietf-mmusic-data-channel-sdpneg.
>>>
>>> Would there be another option, which I haven't described above?
>>>
>>> Would there be one (sub-)option, everybody could live with?
>>>
>>> Based on this discussion, if option (C) isn't agreeable, then I
>>> myself would prefer option (B), with a tendency to (B)(ii), as this
>>> might provide more flexibility for implementations, which want to use
>>> an attribute for a data channel subprotocol with its original (data
>>> channel transport independent) semantic, also if this attribute has
>>> not been added to the data channel subprotocol specific attribute
>>> registry. And as I still think that most of those attributes would be
>>> used transport protocol stack independently.
>>>
>>> Thanks again,
>>> Juergen
>>>
>>>
>>>
>>> On 08.03.2016 04:04, EXT Flemming Andreasen wrote:
>>>>
>>>>
>>>> On 3/6/16 7:04 PM, Christian Groves wrote:
>>>>> Hello Flemming and Juergen,
>>>>>
>>>>> ..snip..
>>>>>>> I agree that in such cases such new attributes could indeed be
>>>>>>> added to corresponding data channel subprotocol specific
>>>>>>> attribute registries, which then could refer to the document
>>>>>>> introducing this new attribute.
>>>>>> Right - and for consistency I think it then makes sense to have
>>>>>> all subprotocol-specific attributes registered there.
>>>>>>
>
>>>>>>> An alternative might be to only add such a new SDP attribute to
>>>>>>> the generic IANA SDP attribute registry (which probably would be
>>>>>>> done anyhow). I assume that the generic SDP attribute registry
>>>>>>> would also refer to the document introducing this new attribute.
>>>>>>>
>>>>>> Either would work, however my preference would be a complete
>>>>>> listing of attributes that have subprotocol specific meaning.
>>>>>>
>>>>>> I'd be interested in what other people think though
>>>>>
>>>>> From looking at the existing IANA registry
>>>>> http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml
>>>>>
>>>>> It feels like we should take the approach for att-field (source
>>>>> level) and define att-field (data channel).
>>>>>
>>>> Thanks for the feedback Christian. Just to be clear: We would need
>>>> to allow for multiple entries per attribute, since different
>>>> sub-protocols could each define sub-protocol specific behavior for
>>>> an attribute.
>>>>
>>>> Thanks
>>>>
>>>> -- Flemming
>>>>
>>>>
>>>>> Regards, Christian
>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> -- Flemming (with my individual hat on)
>>>>>>
>>>>>
>>>>> .
>>>>>
>>>>
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>