> what about the attached?
Remaining/new issues:
- "per EBCS" should be "per EBCS traffic stream"
- "EBCS request using the URL indicated in the EBCS Info frame." should not have a full stop
and for consistency with the cells above be "EBCS request by STAs that might or
might not be associated with the broadcaster [right?], using the URL indicated in the EBCS Info frame".
Or even better:
1
Request using EBCS Request frames
EBCS request by STAs that are associated with the broadcaster
2
Request using EBCS Request ANQP-elements
EBCS request by STAs that might or might not be associated with the broadcaster
3
Request using
IP requestthe URL indicated in the EBCS Info frameEBCS request by STAs that might or might not be associated with the broadcaster
> Regarding the lat comment
> > Also, new one: aren't similar fixes needed in Table 9-397d—Request Method
> > subfield encoding (in D1.02) and in references to "Request Method" in
> > 11.22.3.3.1 General and 11.100.5 EBCS Termination Notice Procedure?
> Probably yes, but these are other comments so a different resolution will be needed, I have not gone through that
So you mean this will be resolved in a different submission and/or
under a different CID?
Thanks,
Mark
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601
ROYAUME UNI WWW: http://www.samsung.com/uk
From: ANTONIO DE LA OLIVA DELGADO <aoliva@xxxxxxxxxx>
Sent: Tuesday, 13 April 2021 13:39
To: Mark Rison <m.rison@xxxxxxxxxxx>
Cc: STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBC] CR 1091
Hi Mark, what about the attached?
Regarding the lat comment
Also, new one: aren't similar fixes needed in Table 9-397d—Request Method
subfield encoding (in D1.02) and in references to "Request Method" in
11.22.3.3.1 General and 11.100.5 EBCS Termination Notice Procedure?
Probably yes, but these are other comments so a different resolution will be needed, I have not gone through that
Br
Antonio
El mar, 13 abr 2021 a las 11:22, Mark Rison (<m.rison@xxxxxxxxxxx>) escribió:
Hello Antonio,
thanks for the quick response ahead of the meeting
added your modifications to the attached doc, answering other comments:
- "is an
bit maskoctet that " is duplication of the figure defining the element.Delete
- What does "IP" mean in "Out of band IP request"? The abbreviation does not
appear in Subclause 3.4. In any case, it's not clear to me what it's
telling me, even if it means "Internet Protocol" (does it mean it has
to be IPv4 or IPv6?)
It means IPv4/IPv6, the EBCS Info frame contains an URL that you can use to do this.
I see. In that case wouldn't it be clearer to say something like
"EBCS request using the URL indicated in the EBCS Info frame"?
What is the point of explicitly referring to IP?
- "Note" should be "NOTE"
- "one Negotiation Method" should be "one negotiation method"
- Do we have some general comment to deal with the fact that
"an EBCS" needs to be expanded to "an EBCS traffic stream" (or
better "an EBCS stream" or "an EBCS flow") throughout?
Not sure about it, said so, I think in this case the phrase does not intend to mean EBCS traffic stream, since this is talking about the service itself and not the frames... This is the phrase for the others to consider
"request the transmission of an EBCS identified by the content ID contained in the Content ID subfield"
Hm, I don't think transmission of a service makes sense. Similarly
"Only one negotiation method can be selected per service" should probably be
"per EBCS <something>".
- Does "EBCS request by STAs that are not associated with the broadcaster" imply that you
shall not use this method if you are associated? (It doesn't imply
that you shall use this method if you are not associated, since
otherwise methods 0 and 3 could never be used.) Do we have some
behavioural text associated with this?
As I understand this field, you are indicating if the service can be requested by associated or not associated STAs. So to me value 1 means that you need to be associated to request it, value of 2 means you can request it either associated or not associated and value of 3 means that you need to use another method maybe through another link. This is my understanding though, I did not write this.
So maybe 2 should be something like
EBCS request by STAs that might or might not be associated with the broadcaster
?
Also, new one: aren't similar fixes needed in Table 9-397d—Request Method
subfield encoding (in D1.02) and in references to "Request Method" in
11.22.3.3.1 General and 11.100.5 EBCS Termination Notice Procedure?
Thanks,
Mark
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601
ROYAUME UNI WWW: http://www.samsung.com/uk
From: ** STDS-802-11-TGbc -- Enhanced Broadcast Service ** <STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx> On Behalf Of ANTONIO DE LA OLIVA DELGADO
Sent: Tuesday, 13 April 2021 08:03
To: STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBC] CR 1091
Dear all,
I have committed a new version of the contribution addressing the conflict between CR 1091 and 1451 (https://mentor.ieee.org/802.11/dcn/21/11-21-0581-02-00bc-conflict-1091-1451.docx) and the excel with the resolution for CR 1091 (https://mentor.ieee.org/802.11/dcn/21/11-21-0661-00-00bc-cr-1091.xlsx), no need to modify resolution for 1451.
Marc, if possible we can have a look at the AC.
Br
Antonio
--
Antonio de la Oliva
Associate Professor
Telematics Department
Universidad Carlos III de Madrid
E-mail: aoliva@xxxxxxxxxx
Phone: +34 91 624 8803
Fax: +34 91 624 8749
To unsubscribe from the STDS-802-11-TGBC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBC&A=1
--
Antonio de la Oliva
Associate Professor
Telematics Department
Universidad Carlos III de Madrid
E-mail: aoliva@xxxxxxxxxx
Phone: +34 91 624 8803
Fax: +34 91 624 8749
--
Antonio de la Oliva
Associate Professor
Telematics Department
Universidad Carlos III de Madrid
E-mail: aoliva@xxxxxxxxxx
Phone: +34 91 624 8803
Fax: +34 91 624 8749