t check the schemas (even you had the nice attention to
provide them directly, cf appendix B). I reviewed the 33 version
(so at the exception of spelling errors I gave the 33.txt page numbers)
and verified the 33-34 diff.
Regards
francis.dup...@fdupont.fr
--
Randall Gellens
Opinions
;signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail
Attachment converted: TiLand:signature 637.asc (/) (02AA4317)
--
Randall Gellens
Opinions are personal;facts are suspect;I
072 need to be Informative References.
EU eCall requirements are referenced in the eCall draft, which this
draft normatively references, and are not directly used in this
draft, so I don't see that it's useful to add them here.
2. Add an informative reference for Bluetooth mention
ot;package to accommodate"
-[Page 17], "how it it used"->"how it is used"
-[Page 17], "when it is is required"->"when it is required"
-[Page 18], "it is is required"->"it is required" (two occurrences)
-[Pa
dopt other data formats, a multi-region vehicle might need to
support those as well.
I think this text is better than the added sentences, and I agree
with you that the added text introduced its own ambiguity.
--Randy
On Thu, Jan 5, 2017 at 9:11 PM, Randall Gellens
<<mailto:rg+i...@r
ter would be
... the language (and by implication the media modality) would be
negotiated using SIP, and then the specific media (which
inherently
include the modalities and formats) would be negotiated at a
different level ...
[END]
This email and its attachments are in
have mismatches (such as where
the media modality negotiated in SIP don't match what was
negotiated
using SDP).
"the media modality and language would be negotiated using SIP" isn't
quite the right way to say it because SIP isn't explicitly
negotiating
the mod
At 11:57 AM +0100 2/22/17, Gunnar Hellström wrote:
A few comments inline,
Den 2017-02-22 kl. 02:44, skrev Randall Gellens:
Hi Dale,
Thank you for your review, I appreciate it. Please see inline.
At 6:32 PM -0800 2/17/17, Dale Worley wrote:
Reviewer: Dale Worley
Review result
s that it would be useful
for the draft to suggest (not require) that a
session rejected due to lack of
mutually-supported languages use 488 or 606, and
also include a Warning header field with the
suggested 308 code that the draft would register.
--
Randall Gellens
Opinions are personal;
At 10:34 AM -0500 2/23/17, Dale R. Worley wrote:
Randall Gellens writes:
Thanks, Dale. It seems that it would be useful
for the draft to suggest (not require) that a
session rejected due to lack of
mutually-supported languages use 488 or 606, and
also include a Warning header field
py to
expand others. Are there particular ones that you suggest expanding?
2) In S3, may be a good idea to provide a reference for
IMAP and Message Submission in the first sentence of the
opening paragraph.
OK.
3) S4, second paragraph: s/marjup/markup
Fixed in -05.
Thank you
haracters that are encoded with a percent symbol. That would make
the text:
and single quote characters have special meaning and
so MUST themselves be percent encoded.
^^^
This comment also applies to the last paragraph in Section 4.2.
OK
Agree.
Hi Pete,
I don't see this as a new protocol. It is a new service tag that is
optional to use. Not using it won't break anything that wouldn't be
broken without the tag being defined. Using it is an optimization. I
see the draft as only adding a new tag, not defining a new protocol.
--Ran
n "optimization" of an existing protocol,
that makes it a protocol. I can't see any other way of describing
section 3.
pr
On 8 Mar 2020, at 14:27, Randall Gellens wrote:
Hi Pete,
I don't see this as a new protocol. It is a new service tag that is
optional to use. Not
it any less a protocol. Indeed, if it is an "optimization" of an
existing protocol, that makes it a protocol. I can't see any other
way of describing section 3.
pr
On 8 Mar 2020, at 14:27, Randall Gellens wrote:
Hi Pete,
I don't see this as a new protocol. It is a new s
worthy of standards track. If you truly want simply a
registration, make the reference and it will be a perfectly reasonable
Informational document.
pr
On 8 Mar 2020, at 15:22, Randall Gellens wrote:
Hi Pete,
The document adds a tag. It also contains informational text that
explains how
Thank you for your review and positive comments, Suhas.
--Randall
On 19 Mar 2021, at 7:03, Suhas Nandakumar via Datatracker wrote:
> Reviewer: Suhas Nandakumar
> Review result: Ready
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF
(1) I'm fine with the Abstract as it is, I don't think it needs to be
shortened, but if Russ' suggestion is taken, I'd want his new text "This
extension is applicable when the location information in the
request uses the Basic Civic profile as described in RFC
5222" deleted, as the extension c
18 matches
Mail list logo
