Hi, > PS: Embedded devices, M2M, Internet of Things implementation (whatever > you want to call them) use all sorts of encodings, including XML and > JSON. In fact the most "heavy" part of the code will not be the XML/JSON JSON's compactness advantage over XML cannot make big difference, then.
> (which will most likely be uses as a template anyway) but the security > functionality. Agree! In the last meeting at Vancouver, many discussions on the PAWS framework are actually on security, typically authentication by certificate and pre-shared secret, crypto-binding of protocols in distinct layers, etc. Even more need to be discussed yet. Best Regards, Yang ================== Yang Cui, Ph.D. Huawei Technologies [email protected] > -----邮件原件----- > 发件人: [email protected] [mailto:[email protected]] 代表 > Hannes Tschofenig > 发送时间: 2012年8月26日 15:35 > 收件人: Das, Subir > 抄送: [email protected]; Manikkoth Sajeev > 主题: Re: [paws] XML schema versus JSON, vCard & iCal > > Hi all, > > JSON and XML are very similar in terms of supported tools and > availability of code in languages. > > The only question to me that arises is whether you want to re-use > existing protocol work (such as LoST, vCard, GML, etc.). Do you know the > answer to this question? > > Ciao > Hannes > > PS: Embedded devices, M2M, Internet of Things implementation (whatever > you want to call them) use all sorts of encodings, including XML and > JSON. In fact the most "heavy" part of the code will not be the XML/JSON > (which will most likely be uses as a template anyway) but the security > functionality. > > On 08/26/2012 04:30 AM, Das, Subir wrote: > > It would be good if you can provide some specific examples where JSON is > > problematic but XML is easier. > > > > -Subir > > > > *From:*[email protected] [mailto:[email protected]] *On > Behalf > > Of *Manikkoth Sajeev > > *Sent:* Friday, August 24, 2012 11:14 PM > > *To:* [email protected]; [email protected]; > [email protected] > > *Cc:* [email protected] > > *Subject:* Re: [paws] XML schema versus JSON, vCard & iCal > > > > Hi, > > > > I would still support XML. JSON libraries are available for all > > languages. But interfacing and linking such libraries are problematic on > > embedded devices most of the time. And if an implementation vouch for > > multiple such non native language libraries then developers life is hell... > > > > /Best Regards,/ > > > > /Sajeev Manikkoth/ > > > > *From:*"[email protected] <mailto:[email protected]>" > > <[email protected] <mailto:[email protected]>> > > *To:* [email protected] <mailto:[email protected]>; > > [email protected] <mailto:[email protected]> > > *Cc:* [email protected] <mailto:[email protected]> > > *Sent:* Saturday, 25 August 2012, 0:38 > > *Subject:* Re: [paws] XML schema versus JSON, vCard & iCal > > > > WiFi world builds on mandating the implementation (and certification) of > > a base spec, and a set of optional features. If an optional feature is > > not supported by one of the peers, they can still talk, but not use that > > feature. That is basically option B) from Brain’s list. > > > > I’d like to suggest that we recognize that option A) and B) are valid > > options, while option C) is invalid, and we should stop debating it. > > > > I’d also like to add the obvious option D) to the list, which is that > > both the master devices and DBs support one and the same encoding ;) > > > > Option A) seems to be like a good compromise, and would cut discussions > > short, with the only caveat that if there is no strong technical > > argument for supporting and specifying two different encodings, then the > > iesg may send the document back to the wg to pick one of the two > > specified. As Robert mentioned in his email, this has happened in the > > past, so it is likely it would happen again. And frankly, I do not see a > > strong argument in favor of two different encodings. > > > > Is there anyone who has a technical argument against supporting only one > > encoding, being that either xml or json? > > > > Most people speak in favor of JSON, because it is compact and more > > efficient. I went through this thread and I saw 2 objections against > > picking JSON. One said that JSON requires native Java, which is wrong, > > the other objection gave no real reason. So I am wondering if there is > > really any valid technical reason against using JSON only? > > > > - Gabor > > > > *From:*[email protected] <mailto:[email protected]> > > [mailto:[email protected]] *On Behalf Of *ext Rosen, Brian > > *Sent:* Friday, August 24, 2012 10:43 AM > > *To:* Benjamin A. Rolfe > > *Cc:* [email protected] <mailto:[email protected]> > > *Subject:* Re: [paws] XML schema versus JSON, vCard & iCal > > > > Okay: > > > > So, I implement a database, and I implement XML > > > > You implement a device, and you implement JSON > > > > You query my database (let's not get into how you do that query without > > deciding XML vs JSON) and discover I implement XML only > > > > What do you do? > > > > Brian > > > > On Aug 24, 2012, at 1:38 PM, "Benjamin A. Rolfe" <[email protected] > > <mailto:[email protected]>> wrote: > > > > There are two ways to achieve interoperability when you have an option. > > > > There are many existence proofs of the third way that I mentioned below. > > 802.11 + WiFi provide many options and a means for devices to share > > information about what options each supports, without requiring that any > > device implement every option. It works. > > > > That said, I think (A) is the best choice, (B) is not as nice for me, > > and (C) is more work than either of the other two. > > > > One is that one end implements both choices and the other end > implements > > one or both. > > > > The other is that both ends implement one specific choice ("MUST > > implement") and both can optionally implement the other choice. Only if > > both ends implement the other choice would that be available. > > > > So, in this case we could do one of the following: > > > > A) Databases implement both XML and JSON, devices implement either > > > > B) Both Databases and devices implement one (say XML) and optionally > > implement the other (say JSON) > > > > You are advocating for A, Richard was suggesting B. > > > > I don't care, but choice C) Both databases and devices have a choice of > > what to implement doesn't work for me (or Richard). > > > > Brian > > > > On Aug 24, 2012, at 12:57 PM, Benjamin A. Rolfe <[email protected] > > <mailto:[email protected]>> wrote: > > > > Apparently I was unclear. I certainly an capable of being wrong as I > > practice often, but in this case it is quite unlikely :-). > > > > You do not need to choose only one form to achieve interoperability. > > If you have two, let the device implementer figure out which is best for > > their particular device requirements and trade-offs. This is > > *preferable* from my perspective. > > > > If you provide more than one form in the database, devices using the > > database need some means for figuring out which are available. It can't > > use it if it doesn't no about it. This is an observations, not an > > argument ;-). > > > > It is my *opinion* at the moment that if you provide options, to make > > those useful you need to provide a protocol by which devices can > > discover what options the database supports. If you have such a > > mechanism and all devices use it (a bootstrap protocol), everything > > else could be options. This requires additional functions in both > > database and device implementations. > > If on the other hand the device can "just know" that the database has > > two forms available, it won't need to dynamically figure it out. The > > device implementer has options and simplicity, so I like it. > > > > Since I am focused on the TVWS devices that need access to the database, > > and not a database implementer, shifting burden onto the database > > implementer (not me) to reduce the burden on the device implementer > (me) > > is preferred from my perspective. The database implementer may have > > another perspective. Should I point out that there will be a lot more > > devices than databases? That might sound like an argument, though, so I > > won't....:-j > > > > Ben > > > > Brian is right .. sorry but the rest of you are wrong. J > > > > This is why you have MUST and SHOULD in RFC 2119. > > > > This BTW is a classic argument in IETF terms .. but the argument “let > > the market decide” only holds so much validity. You actually have to > > choose SOMETHING to create a baseline of interoperability. > > > > A virtually identical argument is now playing out in discussions of > > mandatory audio and codec implementations for WEBRTC like things. > > > > IMHO XML MUST anything else defined SHOULD, but MUST on XML and > JSON > > could work as well. It just leads to a level of complexity in > > implementations. > > > > End of argument you now can go back to your regularly schedule > > programming. J > > > > *From:*[email protected] <mailto:[email protected]> > > [mailto:[email protected]] *On Behalf Of *[email protected] > > <mailto:[email protected]> > > *Sent:* Thursday, August 23, 2012 5:44 PM > > *To:* [email protected] <mailto:[email protected]>; > > [email protected] <mailto:[email protected]> > > *Cc:* [email protected] <mailto:[email protected]> > > *Subject:* Re: [paws] XML schema versus JSON, vCard & iCal > > > > I agree with Brian. > > > > There needs to be a default mandatory to implement option in order to > > achieve interoperability. > > > > And this applies to the device and database side of the protocol. > > > > -Raj > > > > *From: *"<ext Rosen>", "[email protected] > > <mailto:[email protected]>" <[email protected] > > <mailto:[email protected]>> > > *Date: *Thursday, August 23, 2012 2:43 PM > > *To: *Don Joslyn <[email protected] > > <mailto:[email protected]>> > > *Cc: *"[email protected] <mailto:[email protected]>" <[email protected] > > <mailto:[email protected]>> > > *Subject: *Re: [paws] XML schema versus JSON, vCard & iCal > > > > One of my favorite IETF expressions is "There are no protocol police". > > We apply that in lots of ways, but one of them is that if you don't > > implement what the document says, you may not get interoperability with > > other implementations. On the other hand, the whole point of a protocol > > document like ours is that two independent implementations who both > > follow the document will interwork. If that wasn't true, why do you > > need a standard? > > > > If you say "either" to both ends, then you don't get interoperability. > > > > By your argument, we should stop working, and the product managers will > > figure it out using proprietary protocols. The market will decide. > > > > So, I feel strongly that if one end is "either", the other end must be > > "both". It's also acceptable to say both ends implement one choice and > > the other is optional at both ends. Here, I think it's server does both > > and client does either. > > > > It's always possible to build an implementation of a server that only > > does one: there are no protocol police. > > > > Brian <as individual> > > > > On Aug 23, 2012, at 3:11 PM, Don Joslyn <[email protected] > > <mailto:[email protected]>> wrote: > > > > > > > > Hi Ben, > > > > That was my original suggestion, and I still think it makes the most sense. > > > > Thanks for supporting the proposal. > > > > Don > > > > *From:*[email protected] <mailto:[email protected]> > > [mailto:[email protected] <mailto:[email protected]>]*On Behalf > > Of*Benjamin A. Rolfe > > *Sent:*Thursday, August 23, 2012 3:05 PM > > *To:*[email protected] <mailto:[email protected]> > > *Subject:*Re: [paws] XML schema versus JSON, vCard & iCal > > > > Someone suggested that PAWS define both, and let the vendors decide > > which ones to implement. > > That makes the most sense for both DB and device vendors. Markets will > > probably drive DB vendors to do both. Device vendors will do what fits > > the market segment they're after. Why over-constrain (or argue when > > natural selection will take care of it for us?). > > B > > > > > > Sounds good to me. > > > > *From:*[email protected] > > <mailto:[email protected]>[mailto:[email protected]]*On > Behalf > > Of*[email protected] <mailto:[email protected]> > > *Sent:*Tuesday, August 21, 2012 12:42 AM > > *To:*[email protected] <mailto:[email protected]> > > *Subject:*Re: [paws] XML schema versus JSON, vCard & iCal > > > > Now I can’t see anymore any willingness to agree on one or the other > > encoding. > > > > To prevent endless discussions on this topic I’d suggest we move forward > > with supporting both in the DB and either one in the master device. > > > > Any objections? > > > > Gabor > > > > *From:*[email protected] > > <mailto:[email protected]>[mailto:[email protected]]*On > Behalf > > Of*ext Das, Subir > > *Sent:*Monday, August 20, 2012 2:50 PM > > *To:*Don Joslyn; Vincent Chen; Weixinpeng > > *Cc:*[email protected] <mailto:[email protected]>; Manikkoth Sajeev > > *Subject:*Re: [paws] XML schema versus JSON, vCard & iCal > > > > We have a half a dozen or more TVDB radio vendors that use/prefer JSON > > and we will vote for JSON if we had to pick one. > > > > Also I will copy the following two important points: > > > > o Simple-to-use libraries exist for all major languages/platforms > > o Don't need a tool chain to work with the data, as is typically > > needed for XML > > > > *From:*[email protected] > > <mailto:[email protected]>[mailto:[email protected]] > > <mailto:[mailto:[email protected]]>*On Behalf Of*Don Joslyn > > *Sent:*Monday, August 20, 2012 4:54 PM > > *To:*Vincent Chen; Weixinpeng > > *Cc:*[email protected] <mailto:[email protected]>; Manikkoth Sajeev > > *Subject:*Re: [paws] XML schema versus JSON, vCard & iCal > > > > Please see my comments below… > > > > Thanks, > > > > Don > > > > *From:*[email protected] > > <mailto:[email protected]>[mailto:[email protected]]*On > Behalf > > Of*Vincent Chen > > *Sent:*Monday, August 20, 2012 2:56 PM > > *To:*Weixinpeng > > *Cc:*[email protected] <mailto:[email protected]>; Manikkoth Sajeev > > *Subject:*Re: [paws] XML schema versus JSON, vCard & iCal > > > > * One of our goals is to strive to lower the cost and complexity for > > device manufacturers. This lowers the barrier for building a robust > > ecosystem. > > > > [DJ - The “cost” and complexity of using XML has not been an issue for > > the half dozen TVBD vendors that have already used XML. Maybe we need > to > > better define “cost”?] > > > > * To reduce complexity and cost for device makers, supporting 1 > > encoding is better than both, as Brian points out. WiFi access > > points that "just work" anywhere in the world serves as a good > model. > > > > [DJ - I proposed that the databases support both XML and JSON, devices > > only need to support one to talk to the database. Our current database > > supports XML and JSON, but if I’m forced to pick only one, then I will > > vote for XML because it’s the one that we currently use on all embedded > > devices.] > > > > * There's a trend for APIs on the web towards JSON (Twitter, > > FourSquare, Facebook, Google, etc.). One of the major reasons is > > that developers (client-side) prefer it for its simplicity: > > > > o Representation closely matches most data models (nested lists > > and maps) > > o Simple-to-use libraries exist for all major languages/platforms > > o Don't need a tool chain to work with the data, as is typically > > needed for XML. > > > > Apparently, the efficiency gains of JSON also matter to the scalability > > of serving systems. > > > > [DJ �C I can’t argue against these listed pros for JSON, especially when > > you’re dealing with a lot of data (like Twitter, FourSquare, Facebook > > and Google does). But I’m assuming that PAWS messages will not be > > exchanged nearly as often as the applications mentioned above. But > > again, I know JSON is more efficient, can’t argue with that.] > > > > * At the end of the day, it's the data model that matters, rather than > > the encoding. We (Google) are actually neutral on XML vs JSON, as > > long as we're clear on what device makers want. It would be good to > > get feedback from device makers (especially of embedded devices) > > regarding experiences supporting XML vs JSON. > > > > Don, can you elaborate on the types of devices that already support XML? > > > > [DJ - We currently support half a dozen TVDB radio vendors (embedded > > devices) using XML, non using JSON. XML has not been a burden, and the > > amount of data that needs to be exchanged between device and database > is > > not that much or exchanged that often.] > > > > On Fri, Aug 17, 2012 at 6:06 PM, Weixinpeng <[email protected] > > <mailto:[email protected]>> wrote: > > > > Considering of the design of database discovery protocol, the LoST > > protocol may be used and LoST is based on XML, so I think XML may be > > preferred. > > > > --Xinpeng Wei > > > > *From:*[email protected] > > <mailto:[email protected]>[mailto:[email protected] > > <mailto:[email protected]>]*On Behalf Of*Rosen, Brian > > > > > > *Sent:*Friday, August 17, 2012 9:26 PM > > > > *To:*Manikkoth Sajeev;[email protected] > > <mailto:[email protected]>;[email protected] > > <mailto:[email protected]>;[email protected] > > <mailto:[email protected]> > > > > > > *Cc:*[email protected] <mailto:[email protected]> > > *Subject:*Re: [paws] XML schema versus JSON, vCard & iCal > > > > I don't really care whether we use json or xml as a matter of protocol > > design or implementation, but I am a big fan of reusing standards rather > > than defining new ones, and I would not want to see the choice of json > > mean we then decide to roll our own versus using existing standards > > based on the idea there is no json representation of an existing > > standard. So, if choosing json means folks feel free to ignore existing > > xml based standards such as xCard and LoST, then I would not want to use > > json. > > > > I would prefer to not have "both", because of interoperability > > complications. If there is rough consensus for both, then I would > > assert that all servers have to implement both and the client can > > implement either. > > > > There are json validators, so I don't think that is a big deal. > > > > My experience in protocol design on the Internet is that decisions made > > solely or even largely because of compactness advantages rarely are good > > choices. If you like json because it is smaller, then I believe you > > need a much better reason. Binary doesn't work for me, at all. I have > > been involved in big binary vs text wars in protocol design. Text wins, > > binary loses, in my opinion. > > > > Brian <as individual> > > > > *From:*Manikkoth Sajeev <[email protected] > <mailto:[email protected]>> > > *Reply-To:*Manikkoth Sajeev <[email protected] > <mailto:[email protected]>> > > *Date:*Thu, 16 Aug 2012 22:37:38 -0400 > > *To:*"[email protected] <mailto:[email protected]>" > > <[email protected] <mailto:[email protected]>>, "Rosen, > Brian" > > <[email protected] <mailto:[email protected]>>, > > "[email protected] <mailto:[email protected]>" <[email protected] > > <mailto:[email protected]>>, "[email protected] > > <mailto:[email protected]>" <[email protected] > > <mailto:[email protected]>> > > *Cc:*"[email protected] <mailto:[email protected]>" <[email protected] > > <mailto:[email protected]>> > > *Subject:*Re: [paws] XML schema versus JSON, vCard & iCal > > > > Hi, > > > > Can it not be both JSON and XML supported? I would vote for that. Future > > implementations may prefer*XML as it is generic, omni present, easy to > > understand and validate.*For compactness may be a *binary xml > option*can > > also work. JSON I think will necessitate implementation to be native > > Java and may not be as friendly with other implementation languages. > > > > /Best Regards,/ > > > > /Sajeev Manikkoth > > Mobile:+918792292002 > > Email:[email protected] <mailto:[email protected]> > > http://www.linkedin.com/in/mksajeev/ > > > > *From:*"[email protected] <mailto:[email protected]>" > > <[email protected] <mailto:[email protected]>> > > *To:*[email protected] > > <mailto:[email protected]>;[email protected] > > <mailto:[email protected]>;[email protected] > > <mailto:[email protected]> > > *Cc:*[email protected] <mailto:[email protected]> > > *Sent:*Friday, 17 August 2012, 4:55 > > *Subject:*Re: [paws] XML schema versus JSON, vCard & iCal > > > > > > We have not heard any objections for using JSON encoding instead of XML. > > Therefore, let's go for JSON, and close this thread. > > > > - Gabor > > > > -----Original Message----- > > From:[email protected] > > <mailto:[email protected]>[mailto:[email protected] > > <mailto:[email protected]>] On Behalf Of ext Rosen, Brian > > Sent: Monday, August 13, 2012 3:14 PM > > To: 'Vincent Chen'; 'Peter Stanforth' > > Cc: '[email protected] <mailto:[email protected]>' > > Subject: Re: [paws] XML schema versus JSON, vCard & iCal > > > > json is okay with me. > > I'd prefer an ISO time stamp rather than a time in seconds since epoch. > > It's very easy to parse, and its simpler to use and debug. Don't care a > > whole lot about that > > > > Brian <as individual> > > > > > > > > -----Original Message----- > > From: Vincent Chen [mailto:[email protected] > <mailto:[email protected]>] > > Sent: Monday, August 13, 2012 06:04 PM Eastern Standard Time > > To: Peter Stanforth > > Cc: Rosen, Brian; Teco Boot; Benjamin A.Rolfe;[email protected] > > <mailto:[email protected]> > > Subject: Re: [paws] XML schema versus JSON, vCard & iCal > > > > XML vs JSON > > > > Between XML and JSON, JSON messages are more compact and easier to > > process (parsing, synthesis). As clarification, JSON does not require > > JavaScript or a Browser. It is a text-based representation of data that > > is language independent, yet well-matched to all major languages. > > JSON-handling libraries exist for numerous languages (see > > ofhttp://json.org/) and seem to be reasonably light weight. > > > > Timestamps > > > > As for timestamp specifications, should we consider just using seconds > > since the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the > > need for datetime-string parsing on devices, assuming devices already > > have native libraries that provide time in this format. Is that a valid > > assumption? Of course, this is less human-readable.... > > > > > > On Mon, Aug 13, 2012 at 6:49 AM, Peter Stanforth > > <[email protected] <mailto:[email protected]>> > wrote: > > > > > > Whenever we built mobile devices we never dealt with IETF, in our > > sensor > > days even an IP stack was a challenge,so I would defer to the > > device guys > > on that one. > > > > On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian" > > > > <[email protected] <mailto:[email protected]>> > wrote: > > > > >Our experience in the IETF over many years is that economizing > message > > >size and compromising utility and security in search of efficiency of > > >implementation on small devices is a poor trade off. I am not > > advocating > > >being wasteful of resources, but I don't think we should seriously > > >consider the overhead of XML or json to be significant. > > > > > >Assuming a json library can be loaded on a small device is > reasonable. > > > > > >Brian (as individual) > > > > > > > > > > > > -----Original Message----- > > >From: Peter Stanforth [mailto:[email protected] > > <mailto:[email protected]>] > > >Sent: Saturday, August 11, 2012 07:13 AM Eastern Standard Time > > >To: Teco Boot; Benjamin A.Rolfe > > >Cc: [email protected] <mailto:[email protected]> > > >Subject: Re: [paws] XML schema versus JSON, vCard & iCal > > > > > >Not all masters run over the core network. > > >Some of the Use cases have a master talking to another OTA > > >We should not assume that all Masters are attached to utility > > power so we > > >should be sympathetic to processing energy use also. > > > > > >On SatAug/11/12 Sat Aug 11, 5:30 AM, "Teco Boot" > <[email protected] > > <mailto:[email protected]>> wrote: > > > > > >> > > >>Op 10 aug. 2012, om 18:10 heeft Benjamin A. Rolfe het volgende > > >>geschreven: > > >> > > >>> Compactness of messages is important, but it is also important > > (to me > > >>>at least) to be realizable in an implementation with limited > > resources, > > >>>such as embedded devices in what are now popularly called > "M2M" > > >>>applications. A lot of these devices could use IP all the end > > to end, > > >>>but may have a very compact, simple stack and applications (i.e. > no > > >>>browser). Is JSON typically implemented when there is no > browser? > > >>>Would it be hard to do in a resource constrained device (i.e. > > where we > > >>>talk about memory size in Kilo-bytes still). > > >> > > >>In use cases and requirements document, there are no > requirements for > > >>protocol performance. I guess OS/IP/TCP/TLS code size supersedes > > needs > > >>for JSON or XML. > > >> > > >>Same for timing: TCP/TLS connection setup will take more than > the > > PAWS > > >>message exchange, I think. This may be of importance when using > > satcom > > >>links. > > >> > > >>Because PAWS runs between master and database, over core > network, > > >>performance is not our primary concern. But as always, it is good > > to keep > > >>an eye on efficiency. > > >> > > >>Teco > > >> > > >>> Thanks > > >>> Ben > > >>> > > >>> > > >>>> We had a discussion on XML vs. JSON. I prefer the one with > most > > >>>>compact messages. > > >>>> > > >>>> On vCard and JSON: what is the status of "A JavaScript Object > > Notation > > >>>>(JSON) Representation for vCard"? > > >>>>http://tools.ietf.org/html/draft-bhat-vcarddav-json-00 > > >>>> > > >>>> On valid times: can we use same format as certificates? They > have > > >>>>similar simple requirements: valid notBefore& notAfter. > > >>>>http://tools.ietf.org/html/rfc3280#section-4.1.2.5 > > >>>> > > >>>> Teco > > >>>> _______________________________________________ > > >>>> paws mailing list > > >>>>[email protected] <mailto:[email protected]> > > >>>>https://www.ietf.org/mailman/listinfo/paws > > >>>> > > >>> > > >>> _______________________________________________ > > >>> paws mailing list > > >>>[email protected] <mailto:[email protected]> > > >>>https://www.ietf.org/mailman/listinfo/paws > > >> > > >>_______________________________________________ > > >>paws mailing list > > >>[email protected] <mailto:[email protected]> > > >>https://www.ietf.org/mailman/listinfo/paws > > > > > >_______________________________________________ > > >paws mailing list > > >[email protected] <mailto:[email protected]> > > >https://www.ietf.org/mailman/listinfo/paws > > > > _______________________________________________ > > paws mailing list > > [email protected] <mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/paws > > > > > > > > > > > > -- > > -vince > > > > _______________________________________________ > > paws mailing list > > [email protected] <mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/paws > > _______________________________________________ > > paws mailing list > > [email protected] <mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/paws > > > > > > > > -- > > -vince > > > > > > > > > > > > _______________________________________________ > > > > paws mailing list > > > > [email protected] <mailto:[email protected]> > > > > https://www.ietf.org/mailman/listinfo/paws > > > > _______________________________________________ > > paws mailing list > > [email protected] <mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/paws > > > > > > > > _______________________________________________ > > > > paws mailing list > > > > [email protected] <mailto:[email protected]> > > > > https://www.ietf.org/mailman/listinfo/paws > > > > _______________________________________________ > > paws mailing list > > [email protected] <mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/paws > > > > > > _______________________________________________ > > paws mailing list > > [email protected] <mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/paws > > > > > > > > _______________________________________________ > > paws mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/paws > > > > _______________________________________________ > paws mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/paws
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
