|
Hi Mark,
I invite you to read through the comments received in LB201. Quite a few of them
request changes in language that seems clear to me but is obviously not to the
commenter. You are proposing a change in language not because it is incorrect
or ambiguous but because you feel it is too complex. And the reason it is so complex
is because of the people who find ambiguity in language that defines what is to
most people a simple procedure.
The problem, as I see it, is that your language would generate more comments
due to its stated ambiguities. I don't think it would be fruitful for the TG to accept
that language. You state below, "I fail to see the difference" in an example in
which I point out an ambiguity. Since that response seems to be satisfactory for
comments you receive on your text I will use that to respond to your comment
on my text. Your text does not mention M and N but is no less complex, at least I
fail to see the difference. Furthermore, it is much more ambiguous than mine.
I know that there are better ways to describe a fragmentation/reassembly
scheme than the one I have come up with and I earnestly request someone
(maybe you!) step forward and specify one. And whoever does it can own the text
and deal with the umpteen comments on fragmentation/reassembly. But I'm
not going to take your text and deal with the resulting fallout. Sorry.
Dan.
Hello Dan,
> The purpose of comment resolution is to improve the draft and ultimately
get the number of comments reduced. It is my contention that acceptance
of your proposed change would actually
increase the number of comments
the TG received (it would receive at least 3 from me). Therefore rejecting it
on that account is entirely valid.
Again, I think you need to address my comment, even if you disagree
with my proposed resolution.
> Well, your suggested text does not say "zero or more Fragment elements
with an information length of 255" it says "zero or more Fragment elements,
each containing the next chunk of information."
Yes it does.
> It also says that all Fragment
elements following the first are of length 255 so final fragment above violates
your description.
Again, it does not say that
"all" Fragment elements have "length 255",
it says that
"these" (i.e. the zero or more mentioned just before
(perhaps I should say immediately before)) have.
>
Exactly. If all fragments are of length 255, as your text says
Ditto.
> > I think I'm using "immediately following" in the same way as "immediately
following" is used 19 times in mc/D2.0 (though I admit I have not checked
them all).
> "You shall perform action X immediately following action Y" is not the same
as saying "A is in an immediately following B".
I fail to see the difference in this case.
> Does this mean you are going to produce and present a submission with your
suggested text or not?
As I previously stated, not at this stage.
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
Hello Dan,
> > "The information to be fragmented is divided into chunks, in order. The element into which the data would not fit is filled with the first chunk of data
and is termed the leading element. The length of the information in the leading element shall be 255. This element shall be immediately followed by zero or more Fragment elements, each containing the next chunk of information. The length of the information
in these elements shall also be 255. Finally, if there is a remaining chunk, this shall be contained in an immediately following Fragment element."
> Then I will, respectfully, reject your comment as your suggestion is what I
call "comment bait", i.e. text that, if included, will result in more comments.
If you are the comment resolver, then you are of course free to propose any
resolution. My understanding is that rejecting on this basis would not be
valid, however, because calling the proposed "change comment" bait does
not actually address the comment.
The purpose of comment resolution is to improve the draft and ultimately
get the number of comments reduced. It is my contention that acceptance
of your proposed change would actually
increase the number of comments
the TG received (it would receive at least 3 from me). Therefore rejecting it
on that account is entirely valid.
I will not include the words "comment bait" in the rejection text. That
was merely a convenient description of the reason cited above.
> Why would a fragmented element be followed by zero ("zero or more")
fragment elements? It wouldn't be fragmented in that case.
The leading element is followed by zero or more Fragment elements with
an information length of 255. Consider the case where information of
length 256 is to be transmitted -- this will be done as:
1 leading element with an information length of 255
0 Fragment elements with an information length of 255
1 Fragment element with an information length of 1
Well, your suggested text does not say "zero or more Fragment elements
with an information length of 255" it says "zero or more Fragment elements,
each containing the next chunk of information." It also says that all Fragment
elements following the first are of length 255 so final fragment above violates
Now, I will admit that your wording is a little ambiguous but that is part of
the problem. "You know what I mean" is not an acceptable response to
the inevitable comment on ambiguous text.
> And how can
all fragment elements following the first fragmented element be 255
in length when there may be a "remaining chunk"?
My proposed text does not say that "all" fragment elements following the leading
element have an information length of 255. My proposed text says that "these"
fragment elements (the zero or more ones immediately following the leading
element and before any Fragment element with an information length less than
255) have an information length of 255.
> How do we pad that
> final fragment element out to 255 if the size of the "remaining chunk" is
> less than 255?
There is nothing in my proposed text about padding.
Exactly. If all fragments are of length 255, as your text says, then the final
fragment element must be 255. If the actual data is less than 255 you have
> What is an "immediately following" fragment element and
> how does it differ from fragment elements that are not "immediately
> following"?
I think I'm using "immediately following" in the same way as "immediately
following" is used 19 times in mc/D2.0 (though I admit I have not checked
them all).
"You shall perform action X immediately following action Y" is not the same
as saying "A is in an immediately following B".
> Et cetera et cetera et cetera.
> Which isn't to say that your suggestion couldn't be cleaned up to remove its
"comment bait" characteristics, just that I'm not gonna do it because I don't
think the M+N stuff is overly complex, it's just correct and complete. If you
would like to clean it up and generate a submission please do so as I would
be happy to reassign this CID (and the others!) to you.
See above and below.
Does this mean you are going to produce and present a submission with your
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
CID 4741 is yours. In it you state that the fragmentation/reassembly scheme
described in section 9.41 and 9.42 of the TGai draft is overly complex.
No, in this CID I state that the description of the fragmentation/reassembly
scheme, in terms of M and N, is overly complex.
please generate a submission for TGai describing a simpler scheme because I'm
I provided this as a proposed change:
"The information to be fragmented is divided into chunks, in order. The element into which the data would not fit is filled with the first chunk of data
and is termed the leading element. The length of the information in the leading element shall be 255. This element shall be immediately followed by zero or more Fragment elements, each containing the next chunk of information. The length of the information
in these elements shall also be 255. Finally, if there is a remaining chunk, this shall be contained in an immediately following Fragment element."
Then I will, respectfully, reject your comment as your suggestion is what I
call "comment bait", i.e. text that, if included, will result in more comments.
Why would a fragmented element be followed by zero ("zero or more")
fragment elements? It wouldn't be fragmented in that case. And how can
all fragment elements following the first fragmented element be 255
in length when there may be a "remaining chunk"? How do we pad that
final fragment element out to 255 if the size of the "remaining chunk" is
less than 255? What is an "immediately following" fragment element and
how does it differ from fragment elements that are not "immediately
following"? Et cetera et cetera et cetera.
Which isn't to say that your suggestion couldn't be cleaned up to remove its
"comment bait" characteristics, just that I'm not gonna do it because I don't
think the M+N stuff is overly complex, it's just correct and complete. If you
would like to clean it up and generate a submission please do so as I would
be happy to reassign this CID (and the others!) to you.
Also, would you be willing to take ownership of the other 18 CIDs related to
these sections since you'd, effectively, be rewriting the whole thing?
Not at this stage, at least in part because I am not sure what my
or TGai's position is on some of them, e.g.:
CID 4513/5089: "Why has another fragmentation scheme been developed here?
Why not re-use the GAS fragmentation scheme design for pre-association
CID 4897: "It is better to have all data as self-describing rather than
relationally describing - that is, it would be better if the fragment IE
contained two more fields - the IE number of the IE being fragmented and
the fragment number of this fragment"
CID 4902: "An element contains fields. Even if the Fragmentatoin element
allows the element length to go beyond 255, fields cannot be fragmented
across elements. There is no description of how to fragment a field that
has been broken across elements. Furthermore, the length of the
fragmented element is not specified."
Well, it would require contacting the commenters and querying the TG.
Basically owning the text. But I guess I'll have to do it as the CIDs are still
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
-----Original Message-----
Subject: CID 4741 from LB201
CID 4741 is yours. In it you state that the fragmentation/reassembly scheme
described in section 9.41 and 9.42 of the TGai draft is overly complex. Would you
please generate a submission for TGai describing a simpler scheme because I'm
Also, would you be willing to take ownership of the other 18 CIDs related to
these sections since you'd, effectively, be rewriting the whole thing?
_______________________________________________________________________________
IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this
CLOSED reflector. We use this valuable tool to communicate on the issues at hand.
SELF SERVICE OPTION:
Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAI and
then amend your subscription on the form provided. If you require removal from the reflector
press the LEAVE button.
Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html
_______________________________________________________________________________
|