Re: [Standards] Clarification for XEP-0054: private fields

2019-09-20 Thread Peter Saint-Andre 
On 9/19/19 1:01 AM, Wichert Akkerman wrote:


> I am looking for a clarification on XEP-0054. The history description
> for the XEP mentions that it essentially encapsulates
> draft-dawson-vcard-xml-dtd-01 over XMPP, with changes to using
> xuppercase for elements and adding JABBERID and
> DESC. draft-dawson-vcard-xml-dtd-01 also documents private fields [1],
> with a basic example:
> 
>            VERSION="3.0"
>         PRODID="-//HandGen//NONSGML vGen v1.0//EN">
>    Frank Dawson
>      Dawson
>         Frank
>    +1-617-693-8728
>    O+
>    
> 
> Unfortunately it forgot to include this in the DTD. This was extended
> later in draft 2 [2], and fully defined in the DTD for RFC 2426.

The vcard-temp namespace has always been a mess and its origins are hazy
(it was cooked up even before I joined the project in November 1999). I
would not rely too much on whatever was documented in draft-dawson-* or
described in XEP-0054.

> My question is: are implementation of XEP-0054 supposed to a) strictly
> use the DTD from XEP-0054, and thus required throw away any extra
> elements not mentioned there, b) support private fields since they are
> mentioned in draft-dawson-vcard-xml-dtd-01, or c) be liberal and
> preserve unknown elements?

Sadly, I don't think we can say definitively what to do. Typically we
don't consider DTDs and schemas to be normative and we have often not
strictly documented extension points such as the private field you've
noted in draft-dawson-vcard-xml-dtd-01.

Personally I think it's best for us to migrate to vCard4 (which as
Matthew notes has a better-defined extension mechanism) and I would
favor discarding unknown elements in the context of vcard-temp because
there's a possibility of abuse.

Peter
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Clarification for XEP-0054: private fields

2019-09-20 Thread Peter Saint-Andre 
On 9/19/19 1:24 AM, Matthew Wild wrote:

> Prosody also historically preserved everything (it basically treated
> the vcard as an XML blob). However now we have moved to vcard4, our
> compatibility code can obviously only convert fields it knows and
> understands - therefore any custom fields would also get discarded.
> However I also see that there is a defined way to handle unknown
> fields in conversion ( https://tools.ietf.org/html/rfc6351#section-6
> ), so it's not impossible to preserve them.
> 
> That said, our vcard4 implementation largely handles the submitted
> vcard as an XML blob also - putting stuff into a custom namespace is
> totally possible.

Perhaps it's time to move forward with XEP-0292?

Peter

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Clarification for XEP-0054: private fields

2019-09-19 Thread Matthew Wild 
On Thu, 19 Sep 2019 at 08:10, Wichert Akkerman  wrote:
> My question is: are implementation of XEP-0054 supposed to a) strictly use 
> the DTD from XEP-0054, and thus required throw away any extra elements not 
> mentioned there, b) support private fields since they are mentioned in 
> draft-dawson-vcard-xml-dtd-01, or c) be liberal and preserve unknown elements?
>
> This appears to be a fairly common question for ejabberd, which allowed 
> unknown fields up to 16.11, after which it started throwing them away.

Prosody also historically preserved everything (it basically treated
the vcard as an XML blob). However now we have moved to vcard4, our
compatibility code can obviously only convert fields it knows and
understands - therefore any custom fields would also get discarded.
However I also see that there is a defined way to handle unknown
fields in conversion ( https://tools.ietf.org/html/rfc6351#section-6
), so it's not impossible to preserve them.

That said, our vcard4 implementation largely handles the submitted
vcard as an XML blob also - putting stuff into a custom namespace is
totally possible.

Regards,
Matthew
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Clarification for XEP-0054: private fields

2019-09-19 Thread Wichert Akkerman 
Hi everyone,

I am looking for a clarification on XEP-0054. The history description for the 
XEP mentions that it essentially encapsulates draft-dawson-vcard-xml-dtd-01 
over XMPP, with changes to using xuppercase for elements and adding JABBERID 
and DESC. draft-dawson-vcard-xml-dtd-01 also documents private fields [1], with 
a basic example:

  
   Frank Dawson
 Dawson
Frank
   +1-617-693-8728
   O+
   

Unfortunately it forgot to include this in the DTD. This was extended later in 
draft 2 [2], and fully defined in the DTD for RFC 2426.

My question is: are implementation of XEP-0054 supposed to a) strictly use the 
DTD from XEP-0054, and thus required throw away any extra elements not 
mentioned there, b) support private fields since they are mentioned in 
draft-dawson-vcard-xml-dtd-01, or c) be liberal and preserve unknown elements?

This appears to be a fairly common question for ejabberd, which allowed unknown 
fields up to 16.11, after which it started throwing them away.

Regards,
Wichert.


1: https://tools.ietf.org/html/draft-dawson-vcard-xml-dtd-01#section-4.2 

2: https://tools.ietf.org/html/draft-dawson-vcard-xml-dtd-02#section-4 

3: https://tools.ietf.org/html/rfc2426#section-4 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___