draft-siantandre-smpp-simple-07

This draft looks good - I could not find any relevant comments to  
send other than I like it  Thanks, Cullen

RE: [Geopriv] Proposed Resolution to thedraft-ietf-geopriv-common-policy issue.

7.1.3 needs to be renumbered as well; you show it as 1, 3, 4:

> NEW:
> 
>    1.  Translate percent-encoding for either string.
> 
>    3.  Convert both domain strings using the toASCII operation described
>        in RFC 3490 [2].
> 
>    4.  Compare the two domain strings for ASCII equality, for each
>        label.  If the string comparison for each label indicates
>        equality, the comparison succeeds.  Otherwise, the domains are
>        not equal.
> 
>    If the conversion fails in step (2), the domains are not equal.
> 

Thanks,
Martin
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

_______________________________________________
Simple mailing list

RFC 4479 on A Data Model for Presence

A new Request for Comments is now available in online RFC libraries.

        
        RFC 4479

        Title:      A Data Model for Presence 
        Author:     J. Rosenberg
        Status:     Standards Track
        Date:       July 2006
        Mailbox:    jdrosen <at> cisco.com
        Pages:      35
        Characters: 88399
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-simple-presence-data-model-07.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4479.txt

This document defines the underlying presence data model used by
Session Initiation Protocol (SIP) for Instant Messaging and Presence
Leveraging Extensions (SIMPLE) presence agents.  The data model
provides guidance on how to map various communications systems into
presence documents in a consistent fashion.  [STANDARDS TRACK]

This document is a product of the SIP for Instant Messaging and Presence 
Leveraging Extensions Working Group of the IETF.

This is now a Proposed Standard Protocol.

RFC 4482 on CIPID: Contact Information for the Presence Information Data Format

A new Request for Comments is now available in online RFC libraries.

        
        RFC 4482

        Title:      CIPID: Contact Information for the 
                    Presence Information Data Format 
        Author:     H. Schulzrinne
        Status:     Standards Track
        Date:       July 2006
        Mailbox:    hgs+simple <at> cs.columbia.edu
        Pages:      11
        Characters: 22157
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-simple-cipid-07.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4482.txt

The Presence Information Data Format (PIDF) defines a basic XML
format for presenting presence information for a presentity.  The
Contact Information for the Presence Information Data format (CIPID) is
an extension that adds elements to PIDF that provide additional
contact information about a presentity and its contacts, including
references to address book entries and icons.  [STANDARDS TRACK]

This document is a product of the SIP for Instant Messaging and Presence 
Leveraging Extensions Working Group of the IETF.

RFC 4480 on RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)

A new Request for Comments is now available in online RFC libraries.

        
        RFC 4480

        Title:      RPID: Rich Presence Extensions to 
                    the Presence Information Data Format (PIDF) 
        Author:     H. Schulzrinne, V. Gurbani,
                    P. Kyzivat, J. Rosenberg
        Status:     Standards Track
        Date:       July 2006
        Mailbox:    hgs+simple <at> cs.columbia.edu, 
                    vkg <at> lucent.com, 
                    pkyzivat <at> cisco.com,  jdrosen <at> cisco.com
        Pages:      37
        Characters: 74026
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-simple-rpid-10.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4480.txt

The Presence Information Data Format (PIDF) defines a basic format
for representing presence information for a presentity.  This format
defines a textual note, an indication of availability (open or
closed) and a Uniform Resource Identifier (URI) for communication.
The Rich Presence Information Data format (RPID) described here is an
extension that adds optional elements to the Presence Information
Data Format (PIDF).  These extensions provide additional information

RFC 4481 on Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals

A new Request for Comments is now available in online RFC libraries.

        
        RFC 4481

        Title:      Timed Presence Extensions to the 
                    Presence Information Data Format (PIDF) to 
                    Indicate Status Information for Past and 
                    Future Time Intervals 
        Author:     H. Schulzrinne
        Status:     Standards Track
        Date:       July 2006
        Mailbox:    hgs+simple <at> cs.columbia.edu
        Pages:      9
        Characters: 15549
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-simple-future-05.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4481.txt

The Presence Information Data Format (PIDF) defines a basic XML
format for presenting presence information for a presentity.  This
document extends PIDF, adding a timed status extension
(<timed-status> element) that allows a presentity to declare its
status for a time interval fully in the future or the past.  
[STANDARDS TRACK]

This document is a product of the SIP for Instant Messaging and Presence 

Re: "last call" on SIMPLE-XMPP interworking I-D

I have a few relatively broad comments on the draft.

1. MIME Types

    The document omits a discussion of MIME types. In particular, I
    think you'll find that many (or most) SIMPLE implementations use
    something slightly more sophisticated than text/plain for instant
    messaging (text/html, for example, seems quite popular).

    I'm not familiar with how XMPP handles rich message content,
    although RFC 3921 hints at the ability to embed XHTML message bodies
    in <message/> elements.

    I would suggest that the mapping document would be far more helpful
    if it contained a brief discussion of at least the mapping from
    SIMPLE messages with text/html bodies and XHTML content in XMPP
    messages.

    As far as I know, the only complete answer for other MIME types in
    general is the use of RFC 3923. The document should probably either
    explicitly rule non-text MIME types out of scope or mention RFC 3923
    as a solution for non-text MIME types.

2. Infinite Message Amplification

    If I read section 4.2 correctly: when the gateway receives an XMPP
    <presence/> stanza with type='subscribe', the gateway is responsible
    from that moment until the subscriber sends a <presence/> stanza
    with type='unsubscribe' (which may never happen) for maintaining not
    just the record of the subscription, but an actual live subscription

Re: "last call" on SIMPLE-XMPP interworking I-D

Hi Adam, thanks for the feedback. Comments inline.

Adam Roach wrote:
> I have a few relatively broad comments on the draft.
> 
> 1. MIME Types
> 
>    The document omits a discussion of MIME types. In particular, I
>    think you'll find that many (or most) SIMPLE implementations use
>    something slightly more sophisticated than text/plain for instant
>    messaging (text/html, for example, seems quite popular).

Yes, I was talking with an implementor recently and realized that the
draft needs to discuss handling of various MIME types. It would be
helpful to know which types are in broad use, since my understanding is
that any MIME type is allowed.

>    I'm not familiar with how XMPP handles rich message content,
>    although RFC 3921 hints at the ability to embed XHTML message bodies
>    in <message/> elements.

We've defined an XHTML 1.0 Integration Set for HTML message bodies:

http://www.jabber.org/jeps/jep-0071.html

>    I would suggest that the mapping document would be far more helpful
>    if it contained a brief discussion of at least the mapping from
>    SIMPLE messages with text/html bodies and XHTML content in XMPP
>    messages.

Re: "last call" on SIMPLE-XMPP interworking I-D

Peter Saint-Andre wrote:
> I think that the gateway is responsible for maintaining the live
> subscription only if the request has been approved by the SIP user, not
> if the XMPP user has only sent a subscribe without receiving approval.

I suspect you don't quite understand the way subscribers learn about 
presence authorization in SIP. Generally, if I subscribe to you and I'm 
not yet explicitly authorized (but also not explicitly barred), the 
subscription needs to hang around in a "pending" state until the 
authorization question is answered (or the subscriber gives up). If the 
subscription isn't maintained, there's no way for the gateway to ever 
know that permission has been granted.

>>    To be clear about the danger here, I'll outline a potential attack.
>>    I learn that example.net is running an XMPP/SIP gateway to serve
>>    their SIP users. I learn the identity of _one_ SIP user in their
>>    domain. Then, I open up a TCP connection to their gateway, and
>>    introduce myself as a jabber server. I pretend that I have four
>>    thousand users who are interested in the presence state of the one
>>    SIP user I know about in their domain. To do so, I send out four
>>    thousand <presence> requests, each from a unique user; I pace these
>>    out with about a one second gap between each. Now I'm done. I spent
>>    a little over an hour sending XMPP subscription requests; in
>>    response, I have increased the load on the victim SIP server by a
>>    little more than one TPS from now until the heat death of the
>>    universe. If I do it again, I double that additional load. And, of
>>    course, if I blasted the requests out as fast as possible for a day
>>    or two, the devastation would be complete.
>>     
>

Re: "last call" on SIMPLE-XMPP interworking I-D

Peter Saint-Andre wrote:
> I think that the gateway is responsible for maintaining the live
> subscription only if the request has been approved by the SIP user, not
> if the XMPP user has only sent a subscribe without receiving approval.

I suspect you don't quite understand the way subscribers learn about
presence authorization in SIP. Generally, if I subscribe to you and I'm
not yet explicitly authorized (but also not explicitly barred), the
subscription needs to hang around in a "pending" state until the
authorization question is answered (or the subscriber gives up). If the
subscription isn't maintained, there's no way for the gateway to ever
know that permission has been granted.

>>    To be clear about the danger here, I'll outline a potential attack.
>>    I learn that example.net is running an XMPP/SIP gateway to serve
>>    their SIP users. I learn the identity of _one_ SIP user in their
>>    domain. Then, I open up a TCP connection to their gateway, and
>>    introduce myself as a jabber server. I pretend that I have four
>>    thousand users who are interested in the presence state of the one
>>    SIP user I know about in their domain. To do so, I send out four
>>    thousand <presence> requests, each from a unique user; I pace these
>>    out with about a one second gap between each. Now I'm done. I spent
>>    a little over an hour sending XMPP subscription requests; in
>>    response, I have increased the load on the victim SIP server by a
>>    little more than one TPS from now until the heat death of the
>>    universe. If I do it again, I double that additional load. And, of
>>    course, if I blasted the requests out as fast as possible for a day
>>    or two, the devastation would be complete.
>>     
>