all it out as the way this is most
likely to fail. I can't see that being more explicit could hurt in any
way, and if there's a bad thing that defeats the entire purpose of the
XEP and is likely to happen, it seems worth calling out.
—Sam
On 2024-05-08 10:29, Marvin W wrote:
On Wed, 20
ly secure hash function to generate the occupant identifier
from the real bare JID and that secret key."
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmp
ve any security concerns related to this specification?
5. Is the specification accurate and clearly written?
Your feedback is appreciated!
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org
3. Do you plan to implement this specification in your code? If not,
why not?
4. Do you have any security concerns related to this specification?
5. Is the specification accurate and clearly written?
Your feedback is appreciated!
___
Standards mailing li
ards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org
--
Sam Whited
s...@samwhited.com
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org
ation?
5. Is the specification accurate and clearly written?
Your feedback is appreciated!
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org
--
Sam Whited
s...@samwhited.com
_
f a Last Call for comments on
XEP-0392.
Title: Consistent Color Generation
…
URL: https://xmpp.org/extensions/xep-0392.html
This Last Call begins today and shall end at the close of business on
2024-03-25.
--
Sam Whited
s...@samwhited.com
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org
operability.
Regards,
Matthew
___
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-le...@xmpp.org
--
Sam Whited
s...@samwhited.com
___
Standards mailing list -- standards@xmpp.org
To unsubscribe
aking the lead on this initiative.
>
> Regards, Matthew
> ___
> Standards mailing list -- standards@xmpp.org Info: Unsubscribe: %(real_name)s-
> unsubscribe@%(host_name)s
> ___
--
Sam Whited
_
idely used, so
I think we can probably shut it down safely as well without too much loss.
What do you think?
—Sam
--
Sam Whited
___
Standards mailing list -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___
> 1. It is impossible to guarantee that an identifier is "globally
>unique", thus this requirement should not end up in any
>specification.
The term "globally unique" is a widely understood term of art that is
perfectly acceptable to use. We don't need to worry about the fact that
it's tec
ion before then!
If you haven't tried it, head over to https://community.xmpp.net/ and
sign up for an account!
—Sam
--
Sam Whited
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
xmpp.org/extensions/xep-0300.html
[2]:
https://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xhtml
--
Sam Whited
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
I have submitted the following to try and remedy this issue:
https://github.com/xsf/xeps/pull/1194
Though I don't think we came to consensus in this thread, I get the
impression that not mixing and matching normal form and multi-item form
elements was the original intent.
For users that want to
h the
> reported form.
>
> It does not add complexity and is useful to provide some context with
> the form.
>
> So if we limit the usage of the XEP lets not throw the baby out with
> the bathwater.
>
> Regards Philipp
>
> Am Di., 19. Juli 2022 um 21:47 Uhr schrieb Flori
not sure where we'd put this text.
—Sam
--
Sam Whited
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
Just that forms with fields and multi-item forms can't be mixed. Ie you can
have or but not
.
On Sun, Jul 17, 2022, at 19:02, Peter Saint-Andre wrote:
> Could you clarify what you mean by a separate data type?
___
Standards mailing list
Info: https:/
a84c8134c2c6f566cb094/aioxmpp/forms/xso.py#L615-L617
[2]:
https://dev.gajim.org/gajim/python-nbxmpp/-/blob/master/nbxmpp/modules/dataforms.py#L710
[3]:
https://github.com/igniterealtime/Smack/blob/ef003bbc5c8c47fb6f32ac78631168d4b197fe0a/smack-extensions/src/main/java/org/jivesoftware/smackx/xdat
s in existing specs.
Option 2 and 3 it would just work.
Your thoughts would be appreciated.
—Sam
[1]: https://logs.xmpp.org/xsf/2022-06-07?p=h#2022-06-07-50bc9a07d99ec16a
[2]: https://logs.xmpp.org/jdev/2022-07-17#2022-07-17-d81ddc5a53cd0080
--
Sam Whited
___
.co.uk/uploads/xeps/xep-0431.html
>
> Feedback welcome, including from Dave (document's author) who I
> haven't consulted about these changes. If there are no objections,
> I'll raise a PR soon.
>
> Regards, Matthe
in the
default community!
https://community.xmpp.net/c/main
Or check out a list of communities to join:
https://community.xmpp.net/communities
See you on the fediverse!
—Sam
--
Sam Whited
___
Standards mailing list
Info: https://mail.jabber.org/m
elated to this specification?
It is probably worth mentioning in the security considerations that the
context of a conversation can appear to be changed if you don't include
a tombstone in the client as well to show that something was removed.
> 5. Is the specification accurate and
s in
the future, and there will be plenty of time for questions! The session
will be recorded.
We hope to see you there!
*What:* Overview of Open Collective and Fiscal Hosting
*Where:* https://socialcoop.meet.coop/sam-pku-dud-niv
*More info:* https://wiki.xmpp.org/web/Office_Hours_Checklist
apologies for the spam if you were already aware. I hope
this will be useful to XMPP projects trying to reach more donors!
—Sam
--
Sam Whited
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr
Seems like we might as well use the element name since that has to be
unique; one less unique ID to store. Also if you have a schema, structs,
etc. in your language of choice you now don't have to go update them for
every possible element to add an id attribute, there aren't conflicts
with anything
I may have misunderstood, but if we're only fetching the last message
the first time, do you start out with no history? Also, why set "before"
at all if it's only one message, the direction won't matter, no?
—Sam
On Fri, Aug 27, 2021, at 09:34, Thilo Molitor wrote:
> When the user first sets up a
Thanks JC!
You're right, I should have mentioned gaps. It's still possible to
have them in a desktop client because it could always close before it
finishes paging through catching up on history. I had planned to solve
that by either switching to committing the entire query in one
transaction, or
In case anyone else is interested in documenting their MAM strategy,
please consider editing this page:
https://docs.modernxmpp.org/client/sync/
Thanks!
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: sta
We've had this discussion before but for context in this thread: I
ignore that as it doesn't make any sense (and follow the second thing
and just decide myself how I want to connect). I know at least one or
two others do to, but I don't know which strategy is more wide spread.
—Sam
On Thu, Aug 12
In my experience it's widely supported these days.
Out of the 119 providers on the jabber.at server list 74 of them (62%)
have xmpps records (though I did not test whether these resulted in a
successful connection with a reasonable TLS configuration). I also don't
know if clients prioritize these
ge was pulled
from the DB before we send initial presence).
If the user scrolls to the top of the history, query in reverse order
with before-id: . Fetch the next page for as long as they
continue to scroll up.
Thanks,
Sam
--
Sam Whited
___
Standards
On Fri, Jul 16, 2021, at 10:49, Jonas Schäfer wrote:
> The "immediately after resource binding" was which was led me to
> believe that this was about enabling carbons, well, *after* resource
> binding, not before.
Ah yes, I see; thanks! Will fix.
> From (4) onward, it is exactly the same as if
On Fri, Jul 16, 2021, at 08:55, Jonas Schäfer wrote:
> How is a nonza different from an IQ, if both happen post-resource-
> binding, as I understand from your text?
This is not what the PR says (see next section). I would be curious what
made it sound like that though, this should be fixed but r
s adoption slower
(though hopefully still relatively fast).
In the mean time I'd like to suggest that carbons just add a simple
stream feature and call it a day so that we can stop dealing with the
race condition.
I've proposed some text here:
https://github.com/xsf/x
Another thought:
Any spec that triggers traffic to a third party JID based on other
incoming traffic can be used for DOS amplification attacks. This one
seems only somewhat vulnerable (max payload size of the pubsub element +
max JID size bytes) but any of them can also become worse if
implementat
e next two weeks whether to accept this
> proposal as an official XEP.
> ___
> Standards mailing list Info:
> https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: Standards-
> unsubscr...@xmpp.org
> ______
r stuff."
—Sam
On Tue, Jun 22, 2021, at 13:23, Kevin Smith wrote:
> On 22 Jun 2021, at 17:51, Sam Whited wrote:
> > * MattJ: bind2 needs new author
>
> I was under the impression no-one had much interest in me driving
> bind2 and the associated bits
three of us, so more
discussion on list would be great!
—Sam
--
Sam Whited
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
gt; Standards mailing list Info:
> https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: Standards-
> unsubscr...@xmpp.org
> ___
>
--
Sam Whited
___
Standards mailing list
Info: https://mail
Thank you, thinking about it more that makes perfect sense. I've
submitted an overhaul based on the list feedback that Zash
reminded me of.
—Sam
On Mon, Jun 21, 2021, at 02:55, Dave Cridland wrote:
>
>
> On Sat, 19 Jun 2021 at 12:35, Sam Whited wrote:
> > Can we undefer XEP-
oops, thanks, I'll have to go back through those.
—Sam
On Sat, Jun 19, 2021, at 13:16, Kim Alvefur wrote:
> Hi Sam,
>
> On Sat Jun 19, 2021 at 9:34 AM CEST, Sam Whited wrote:
> > Can we undefer XEP-0377: Spam Reporting? I don't have any changes that
> > need to
y for advancement, but it definitely
shouldn't be deferred.
—Sam
--
Sam Whited
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
__
> Standards mailing list Info:
> https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: Standards-
> unsubscr...@xmpp.org
> ___
>
> Attachments:
> * signature.asc
--
Sam Whited
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
org/p/XSF_Modernization_Working_Group_Recommendations
I hope to see you there!
Where: https://socialcoop.meet.coop/sam-pku-dud-niv
More info: https://wiki.xmpp.org/web/XMPP_Office_Hours
—Sam
--
Sam Whited
___
Standards mailing list
Info: https://mail.jabber.org/mailman/lis
that allows you to register on an associated XMPP
server, giving Mastodon communities easy self-provisioning on a related
chat network.
It is just an example and doesn't look good, but it should "work" (if
any servers used the new protoXEP).
—Sam
On Sun, Jun 6, 2021, at 08:51, Sam Whi
> Note also that this is not intended to mean that any XMPP developer's
> behaviour will be scrutinised constantly - using, for example, racist
> language in a talk about your XMPP project would be problematic here,
> but using sexualised language in an unrelated setting is likely to be
> irrelevan
>
> > > ___
> > > Standards mailing list Info:
> > > https://mail.jabber.org/mailman/listinfo/standards Unsubscribe:
> > > standards-unsubscr...@xmpp.org
> > > __
Hi all,
I bumped this to the 15th since I forgot to send out the reminder
messages on Monday and then ended up having a busy day yesterday. Sorry
for the lack of advanced warning, but we'll do the next office hours on
the 15th instead.
—Sam
On Fri, May 28, 2021, at 10:29, Sam Whited wrote:
I've gone ahead and submitted the PR, but I wanted to start the
discussion before council votes on it as a way to determine where (and
if) this functionality should exist.
What do you think?
—Sam
[1]: https://github.com/xsf/xeps/pull/1068
--
Over XMPP
XEP-0334: Message Processing Hints
XEP-0385: Stateless Inline Media Sharing (SIMS) (Dedup with OOB?)
XEP-0423: XMPP Compliance Suites 2020
--
Sam Whited
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo
u there!
https://wiki.xmpp.org/web/XMPP_Office_Hours
—Sam
--
Sam Whited
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
On Sat, May 29, 2021, at 15:40, Dave Cridland wrote:
> "Working Group" does have a particular meaning in the standards world,
> but I was more concerned with the "XSF" prefix, yes.
Oops, didn't realize that was in there, I've changed the title.
> It does not, and as noted, I didn't say the words
solutely don't need permission
form the board or council to go ahead as planned.
We're going to go ahead and discuss some XEPs. Naturally, the council
doesn't have to take any recommendations we come up with.
—Sam
On Sat, May 29, 2021, at 05:47, Dave Cridland wrote:
>
>
> On
SF here?
>
> Dave.
>
> On Fri, 28 May 2021 at 15:31, Sam Whited wrote:
> > Hi all,
> >
> > I'm doing another experiment with the office hours. Sometime in the
> > near future (currently 2021-06-08, but this may change) we're going
> > to try havin
e it).
If this sounds fun to anyone, please submit your ideas of XEPs that need
discussion and work before 08 June to the following list:
https://pad.disroot.org/p/XSF_Modernization_Working_Group_Recommendations
Consider setting a name for yourself b
g/web/XMPP_Office_Hours
Signup and Schedule: https://calc.disroot.org/jek96xaqjvlb
—Sam
--
Sam Whited
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
Reminder that tomorrow is the XMPP Office Hours! We hope to see you there for
"Intro to JMAP" by Daniel Gultsch.
When: 2021-04-27 1600 UTC
Where: https://socialcoop.meet.coop/sam-pku-dud-niv
More info: https://wiki.xmpp.org/web/XMPP_Office_Hours
—Sam
--
Absolutely; it will be recorded!
—Sam
On Tue, Apr 20, 2021, at 09:29, Bill Munyan wrote:
> Hello,
> Would it be possible to make this presentation available on whatever
> youtube channel you've posted to before? I'd like to attend this
> presentation but unfortunately have conflicts that can'
TC
Where: https://socialcoop.meet.coop/sam-pku-dud-niv
Info: https://wiki.xmpp.org/web/XMPP_Office_Hours
Signups/schedule: https://calc.disroot.org/jek96xaqjvlb
--
Sam Whited
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standa
ssion!
* When: 2021-03-13 16:00 UTC
* Where: https://socialcoop.meet.coop/sam-pku-dud-niv
* More info: https://wiki.xmpp.org/web/XMPP_Office_Hours
--
Sam Whited
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubs
oop/sam-pku-dud-niv
* More info: https://wiki.xmpp.org/web/XMPP_Office_Hours
* Signup and schedule: https://calc.disroot.org/jek96xaqjvlb
See you there!
—Sam
--
Sam Whited
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standa
ernatively, we could move this functionality into MAM, or
find a way for the server to detect MAM and just implicitly disable
offline messages. And of course all of this could be in a new XEP if
necessary.
Any thoughts on what should be done here?
—Sam
--
Sam Whited
___
ku-dud-niv
See you there!
—Sam
--
Sam Whited
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
o far, and thanks to everyone who filled out the time
slot survey!
—Sam
On Tue, Mar 16, 2021, at 08:38, Sam Whited wrote:
> If you've missed my constant pestering about trying to get a series
> of short talks together recently, see here first for the signup sheet
> and agenda!
>
Join us Friday March 26th at 17:00 UTC, for the XMPP Office Hours!
This week we have a talk by Mellium developer Sam Whited (me!) on
"Designing Message Styling"!
More info at https://wiki.xmpp.org/web/XMPP_Office_Hours
Meeting room: https://socialcoop.meet.coop/sam-pku-dud-niv
See
Join us tomorrow, March 19th, for a talk by Conversations developer
Daniel Gultsch on verifying A/V calls with OMEMO at 17:00 UTC!
More info at https://wiki.xmpp.org/web/XMPP_Office_Hours
See you there!
—Sam
--
Sam Whited
___
Standards mailing list
On Tue, Mar 16, 2021, at 16:20, Jonas Schäfer wrote:
> This message constitutes notice of a Last Call for comments on
> XEP-0313.
Thank you!
> 1. Is this specification needed to fill gaps in the XMPP protocol
>stack or to clarify an existing protocol?
Yes, this specification is already wid
riday time slot.
Assume dates are the day of the week, not the specific date listed in
the poll please. Also be sure to select the correct timezone at the top.
Your name isn't actually needed if you don't want. Thanks!
https://whenisgood.net/kr97tfy
—Sam
--
Sam Whited
_
Thanks Paul!
And don't forget to sign up to give a talk! ;)
—Sam
On Fri, Mar 12, 2021, at 08:20, Paul Schaub wrote:
> Hi Sam,
>
> that's a great initiative! I'll note it down in my calendar :)
>
> Paul
___
Standards mailing list
Info: https://mail.ja
sroot.org/jek96xaqjvlb
Please sign up for topics and fill the slots; see you there!
—Sam
--
Sam Whited
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
> Standards mailing list Info:
> https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: Standards-
> unsubscr...@xmpp.org
> _______
>
> Attachments:
> * signature.asc
--
Sam Whited
a
better choice) or just sending it to LC again if the editors would be
so kind. Thanks!
—Sam
--
Sam Whited
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
provided as a convenience (ie. the
"BlockQuoteEnd" style doesn't apply to any actual text, but is included
after quotes so you know where they should end).
Let me know if you notice anything that appears to be broken or wrong.
—Sam
--
Sam Whited
match. Lazy matching
> means take the first match you find, i.e. find the shortest.
>
> In the form of regular expressions, we have:
> * greedy = /\*.+\*/
> * lazy = /\*.+?\*/
>
> The text is already correct.
--
Sam Whited
___
check me on this? If we make this change to the text
it won't break any of the examples as far as I can see, and I think this
was just a simple typo on my part, but I wanted to follow up and ask
here first.
—Sam
--
Sam Whited
___
Standards mailing
I believe this is only allowed between first-level elements elements per
RFC 6120 § 11.7, so it will likely break something if used elsewhere
(outside of nodes that are meant to contain text, that is).
On Wed, Feb 17, 2021, at 10:50, drew.var...@ninefx.com wrote:
> Whitespace in between elements.
Copied from a draft of an upcoming blog post. Further reading moved to the
front for easy access:
- Docs: https://pkg.go.dev/mellium.im/xmpp@master
- Website: https://mellium.im/xmpp
- A Message Styling retrospective:
https://blog.samwhited.com/2020/11/message-styling/
- An overview of the Melli
On Wed, Feb 3, 2021, at 13:42, Sonny Piers wrote:
> Because the XEP is not for me.
>
> My goal is to let xmpp(.js) users say this is the service (as domain)
> I want to connect to - I don't care how just establish an XMPP
> connection there.
This doesn't seem consistent with your previous statem
In that case, why have an XEP at all? If you're doing anything like
this you don't need the defaults to be standardized across services to
aid in interop, you just know what your servers default is and can just
connect to it.
—Sam
On Wed, Feb 3, 2021, at 12:29, Sonny Piers wrote:
> I agree with t
Making some integration tests easier without a concrete use case for
real world XMPP seems like a bad reason to increase complexity and make
a large change to websocket discovery and fallback. If this is just for
integration tests, why does it need to be standardized and added to
everything else's
A question since I know nothing about web development:
If we accept it as true for the sake of argument that you might want to
run an XMPP server but not have access to run an HTTP server on the
domain you want to use, can you not use the TXT record format from
JavaScript land to get the records s
Oops, this is not true, I copied over my last paragraph into a new email
and then right as I was about to send it realized it couldn't possibly
work at all.
—Sam
On Wed, Feb 3, 2021, at 08:20, Sam Whited wrote:
> Alternative coming in a separate email since I think it might be a
&g
ir
domains. If anything let's use "/xmpp-websocket" which is used in all
the examples in RFC 7395 so that we at least sort of "namespace" the
endpoint to XMPP land and make it obvious what it's for / make conflicts
less likely.
Alternative coming in a separate email since I think it might be a separate
thread.
—Sam
--
Sam Whited
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
ould be used here ? I think it's
> doing live streaming now, and we can pre-record talks and have a
> questions sessions over a MUC room. Other option would be of course
> Jitsi Meet, depending of number of attendees.
>
> I can write also a paragraph about what I'm working on, a
On Thu, Jan 14, 2021, at 19:07, Mathieu Pasquet wrote:
> thhus projects not publishing the file would be less accessible, which
> is the current status).
This is one of the reasons I am furious that we're seriously
considering adopting this format for use on the website. This is
absolutely not o
bsite
so that I can't list my client if I don't write this garbage format.
On Thu, Jan 14, 2021, at 16:25, Jonas Schäfer wrote:
> On Mittwoch, 13. Januar 2021 22:59:23 CET Sam Whited wrote:
> > I hate to go down the rabbit trail of what "widely used means" but
> >
On Thu, Jan 14, 2021, at 16:23, Jonas Schäfer wrote:
> Will you also go ahead and rewrite the code which has already been
> written for DOAP integration [1]? Will you also go ahead and port the
> projects which already have DOAP files? Will you also continue to put
> effort in this?
A handful of
I hate to go down the rabbit trail of what "widely used means" but we
seem to have different definitions of that too. The vast majority of
projects on the web do not appear to use this format. Some do, but they
seem to be a very small minority (albeit from a very very small sample
of me searching s
I disagree, this is a handful of simple strings that need to be defined,
we could document everything we need in an XEP and have it reference
able from a single place trivially. If the council is worried about bike
shedding they could shut that down easily because the absolute specifics
of how ever
nd I don't know where I would
even start to find out.
On Wed, Jan 13, 2021, at 20:27, Matthew Wild wrote:
> On Wed, 13 Jan 2021, 19:43 Sam Whited, wrote:
> > I do not believe this is an appropriate technology whether it's an
> > existing specification or not. It's j
I do not believe this is an appropriate technology whether it's an
existing specification or not. It's just too complicated.
—Sam
On Wed, Jan 13, 2021, at 19:35, Dave Cridland wrote:
>
>
> On Wed, 13 Jan 2021 at 18:24, Sam Whited wrote:
> > I'd like to recommend th
cification defines how
> XMPP projects can provide a machine- readable description of their
> abilities, and how external entities can interact with it.
>
> URL: https://xmpp.org/extensions/inbox/doap-usage-in-xmpp.html
--
Sam Whited
_
That makes sense, thanks. I'll think about how the examples can be
clarified going forward.
—Sam
On Tue, Dec 22, 2020, at 16:18, Kim Alvefur wrote:
> On Tue, Dec 22, 2020 at 03:17:04PM +0000, Sam Whited wrote:
> >I'm not actually sure what this means, do you have more specifi
I'm not actually sure what this means, do you have more specific
feedback about the XEP that I can fix? Thanks!
—Sam
On Tue, Dec 22, 2020, at 14:55, Kim Alvefur wrote:
> With the number of entities that can be involved in multiplexing it
> can quickly become confusing and hard to keep track of ev
I believe this is a mischaracterization of my argument. My argument is
"everything will have a way to get at the underlying bytes, not
everything will have them pre-converted into code points". Also "this
gives us the option to do certain optimizations on systems that support
them, but using code p
I don't think this is true. XML is defined as UTF-8 (in this case),
which is a collection of bytes. They don't have to be separated out and
transformed into some higher representation of code points. Just because
Python et al. convert things into UTF-32 strings first doesn't mean
everything has to.
e it would give me []byte, not a string) which makes it even less
practical and the third example isn't a convenience that exists in eg.
C, so generally it's worth just ignoring.
If I'm having to pick between the code in the first and second example,
please let me pick the first.
—S
The XML library I use does not give me a string or slice of code points,
it gives me a slice of bytes because that's the level I'm operating at.
Even at the higher level if I decode the bytes into a string (A Go
string in this case), that is still just a slice of UTF-8 bytes (it does
not decode the
Oh yes, of course. I see what you're saying now.
—Sam
On Sat, Dec 5, 2020, at 01:24, Andrew Nenakhov wrote:
> сб, 5 дек. 2020 г. в 05:12, Sam Whited :
> >
> >
> >
> > On Fri, Dec 4, 2020, at 23:34, Andrew Nenakhov wrote:
> > > 4. Start = first chara
On Fri, Dec 4, 2020, at 23:34, Andrew Nenakhov wrote:
> 4. Start = first character (inclusive) and length = length of a
>substring.
This is the same as "1. Start = first character (inclusive), end = last
character (exclusive);"
—Sam
___
Standards
1 - 100 of 708 matches
Mail list logo
